#Using Agents and Computers securely

An Agent's work does not run in a cloud sandbox. It runs on a Computer: the local service starts a Runtime such as Claude Code or Codex on that machine and runs real git, build, and test commands as the local service's user. So anyone who can send work to your Agent is indirectly using everything that user can reach on that Computer: code, SSH keys, Git credentials, signed-in sessions, working directories, and internal services.

This guide answers a common question: "Can other people use my Agent or my Computer? How should I set this up?"

The short answer: keep the Computer you use every day — and the Agents bound to it — private. When something really must be shared, bind the shared Agent to a dedicated virtual machine, container, or shared host, and make that public instead.

#Why visibility is a security question

There are two visibility layers, and they combine to decide who can reach your execution environment:

• Agent visibility (Public / Private, see Agent visibility): who in the Space can see the Agent, assign Tasks to it, and chat with it;
• Computer visibility (Personal / Organization / Space, see Visibility and ownership): who in the organization can pick this Computer as an execution environment.

Three common risky combinations:

1. A public Agent bound to a personal Computer. Once an Agent is Public, every member of the Space can assign work to it — and that work runs on your Computer, with your credentials and your file system. That effectively hands your daily machine to the whole Space.
2. A daily-work Computer set to Organization or Space visibility. Colleagues can pick your Computer as their execution environment; if a local personal Computer allows All Organizations, that reach automatically extends to every Organization you join later.
3. Personal credentials left on a shared environment. If a shared Computer still holds a personal SSH key, a signed-in browser session, or an .env file, every member who uses that Computer can read them through an Agent.

Setting a Computer to Organization or Space visibility does not isolate credentials or directories. It only widens who may use the machine. Isolation comes from a dedicated execution environment (principle 3 below).

#Three principles

#Principle 1: keep your personal work Computer Personal

• Keep the Computer's visibility Personal: only the owner can select it;
• For a local personal Computer, set allowed Organizations to Selected Organizations instead of leaving All Organizations on;
• Keep Agents bound to this Computer Private, or invite only the members who genuinely need them and grant them User permission;
• Avoid temporarily raising visibility so a colleague can "try something" and forgetting to lower it again.

#Principle 2: before making an Agent Public, look at what it is bound to

A Public Agent can be seen and assigned work by everyone in the Space. Before publishing it, check:

• Is it bound to your daily machine or a Runtime on it? If so, rebind it to a shared execution environment (principle 3) first — or keep it Private;
• Review the Agent's Advanced settings: who can clone it, who can create variants, whether cloning may carry environment variables over (default no), and whether variants may inherit them (default yes). Tighten these when the environment variables hold tokens or API keys;
• To share across several Spaces, prefer Agent variants that each bind to a shared environment, rather than publishing the Agent that lives on your private machine.

#Principle 3: run shared work in a dedicated environment — a VM, a container, or a shared host

When a team needs to use an Agent together, give it a dedicated execution environment instead of sharing your daily machine:

When you prepare a shared environment:

1. Dedicated OS account: create a separate account for the local service. Do not reuse anyone's personal account, so the service does not inherit personal SSH keys, browser sessions, or shell configuration;
2. Least credentials: provision only what the environment truly needs (dedicated deploy keys, short-lived tokens). Never copy personal credentials; rotate what can be rotated;
3. Directory isolation: have Agents use temporary directories, or a configured directory with worktree-isolated parallel runs, so tasks never write into the same workspace;
4. Load and concurrency: set concurrency to match the host's role and enable System load protection so shared tasks cannot starve the machine;
5. Token hygiene: an install token expires and works once. Never bake it into an image, Task description, comment, or long-lived script;
6. Secrets in the right place: passwords, tokens, API keys, and private keys belong only in the fields that ask for them (for example an Agent's environment variables or secret configuration) — never in Task descriptions, comments, executable paths, or extra arguments.

#When you need to take access back

• The Computer owner can use Unbind runtime for one Agent, or Unbind all, from the Agents area on the Computer detail page. This reclaims the Computer without deleting the Agent; active runs are cancelled;
• Set the Computer's visibility back to Personal and the Agent's visibility back to Private;
• If you suspect a credential leak, rotate the token or key on the affected platform first, then review its usage history.

#Quick self-check

• Your daily Computer is Personal, with allowed Organizations set to selected ones only;
• Agents bound to your private Computer are Private, or shared with explicitly invited members;
• Every Public Agent is bound to a VM, container, or shared host — never to anyone's daily machine;
• Shared environments run under a dedicated account with least credentials, without personal SSH keys or browser sessions;
• Agent environment variables hold no daily-work credentials, and the clone/inherit environment-variable switches are tightened;
• No install token appears in images, scripts, Task descriptions, or comments.

#FAQ

#A colleague wants to use my Agent. What should I do?

Put a shared copy of the Agent on a shared environment and make that one Public; keep the Agent on your private environment Private. For one-off collaboration, inviting the colleague as a member of the private Agent is more contained than publishing it.

#I already set my daily Computer to Organization visibility. How do I fix it?

Set visibility back to Personal; check which Agents are bound to this Computer on its detail page and Unbind runtime where needed; review credential usage and rotate tokens and SSH keys if necessary.

#If my Computer is Organization-visible, can others reach my files?

Yes. Visibility decides who may select the Computer for execution; once selected, an Agent works as the local service's user and can reach everything that user can — including files and credentials. Sharing is therefore safe only when that user environment is a clean, dedicated one, not your personal account.

#Related docs

• Agents: responsibilities, visibility, and member permissions
• Computers: connecting, visibility, allowed Organizations, and system load protection
• Repositories: how repository credentials are configured