Permissions for shared computers and servers

Permission names should match real actions

A role label is not enough. Owners should see whether a member can view the screen, control input, read or write files, run commands, manage processes, operate databases or change device settings. The effective permission set should be visible before an invitation is accepted. For device permissions, a dependable implementation begins with a written baseline: the current behavior, the intended result, the account or device involved and the person responsible for review. Test with a realistic low-risk example, record the result and keep a clear way to stop or reverse the workflow. This turns permission names should match real actions from a feature description into an operating practice that another person can understand and repeat.

• Capability-level permissions
• Visible effective access
• Owner-controlled changes

Default to the smallest useful role

A collaborator who needs to inspect logs may not need mouse control or file deletion. Start invitations with limited access and expand intentionally. Temporary work should use an expiry or a scheduled review instead of relying on someone to remember the share months later. When applying default to the smallest useful role, include the less convenient cases in the design. Check what the user sees when data is missing, access has expired, a provider responds slowly or only part of an operation succeeds. Status messages should identify the affected item and the next useful step without exposing credentials or internal protocol noise. Revisit the setup after real use and remove assumptions that the evidence does not support.

• Least privilege
• Purpose-specific access
• Regular review

Revocation covers active sessions

Removing a shared user should block new requests and terminate current remote sessions as quickly as practical. Device tokens also need rotation after suspected compromise. The activity history should record invitations, acceptance, permission changes and revocation. For device permissions, a dependable implementation begins with a written baseline: the current behavior, the intended result, the account or device involved and the person responsible for review. Test with a realistic low-risk example, record the result and keep a clear way to stop or reverse the workflow. This turns revocation covers active sessions from a feature description into an operating practice that another person can understand and repeat.

• Session termination
• Token rotation
• Auditable membership

AI follows the same boundary

An assistant must not gain broader device access than the user and workspace permit. Reading status is different from changing a file or restarting a service. Important actions should identify the target device and expected effect, then return a clear success or failure result. When applying ai follows the same boundary, include the less convenient cases in the design. Check what the user sees when data is missing, access has expired, a provider responds slowly or only part of an operation succeeds. Status messages should identify the affected item and the next useful step without exposing credentials or internal protocol noise. Revisit the setup after real use and remove assumptions that the evidence does not support.

• No permission escalation
• Read and write separation
• Clear action results

Questions about device permissions