Workspace membership
Signed-in users operate with their workspace role and device-group permissions. Invite members into the workspace that owns the devices.
Know who can do what.
Device access should be an explicit choice. Set permissions for people, controllers, and AI agents, then review how that access is used.
More ways to work. The same control.
Choose who can reach your devices and what they can do. Set boundaries for team members, external controllers, and AI agents.
- Choose device groups and allowed actions.
- Remote sessions use temporary credentials.
- Review operation records in your workspace.
Access is checked at more than one point.
An account, a controller Key, and a remote session serve different purposes. None of them replaces the device access rules.
External controller access
External controllers and MCP agents use a Key with allowed device groups and action scopes. Revoke a Key when it is no longer needed.
Temporary remote sessions
Remote connections use temporary credentials tied to a device and permitted action. A long-lived controller Key is not a reusable desktop-session credential.
Operation records
Review the actor, operation type, target, time, and result in the workspace. These records help you follow up on how device access was used.
Understand the data boundary.
An operation record is different from a chat message or a remote screen. The privacy policy describes these data types in detail.
Audit records
Security audit records retain operation metadata. They are not intended to store desktop images, file contents, typed text, or full command contents.
AI conversations
Built-in chat stores conversation messages and task traces in the workspace. Do not treat chat messages as the same thing as privacy-limited audit records.
Infrastructure trust
The platform console does not provide a global device-control view. Infrastructure and database operators remain a separate trust boundary described in the privacy policy.