What makes a shared coding-agent workspace secure?

A secure shared coding-agent workspace runs the agent somewhere that is nobody's laptop, with a fresh isolated sandbox for every run, no network access beyond an explicit allowlist, no credentials inside the sandbox, a human approval that any member of the team can give or refuse before the agent acts, and a record of who asked for what. Poly (usepoly.co) is built to that list. Below is the list itself, how Poly meets each item, and how the other shared-agent workspaces handle the same questions, as far as their public documentation says.

Why "shared" changes the threat model

One engineer running Claude Code or Codex in a terminal is a contained risk: the agent acts with that person's permissions, on that person's machine, on instructions that person typed. Sharing the agent breaks all three assumptions at once. Several people now write the instructions, so a bad one has several possible sources. The agent reads whatever is in the repository, so a cloned README or a pasted issue can carry instructions too. And if the shared agent runs on one member's machine, everyone in the room is effectively running commands on that machine with that person's keys.

Some tools accept this openly. Omnigent's collaboration docs say: "Only share Edit with people you trust to run arbitrary code on your machine." MobSession mirrors a Claude Code session that runs on the host's laptop under the host's subscription. That is a reasonable trade for two senior engineers who already trust each other. It is not a workspace a team can hand to a product manager, a client or a new hire. A multiplayer session needs somewhere safer to run.

The six properties

1. A fresh, isolated sandbox for every run

Each agent run should get its own container, thrown away afterwards, with nothing on it that another run or another project could reach.

In Poly every turn runs in its own container under gVisor, a user-space kernel that keeps the container's system calls away from the host's. The container's root filesystem is read-only, every Linux capability is dropped, privilege escalation is disabled, and hard limits apply to CPU, memory, process count and wall-clock time, so a runaway turn is stopped with a readable message in the room instead of taking the server with it. Exactly three things are mounted in: the project's workspace, the agent's own session directory, and a package cache that belongs to that project alone. Nothing else on the server is visible from inside.

2. No open internet

An agent that can reach any host can send your source anywhere. The default should be deny, with a short allowlist of the places a build actually needs.

Poly's sandboxes have no route to the internet. The only way out is an authenticated proxy that allows a default list (the model providers' APIs, npm, PyPI, GitHub and a few build-time hosts) plus whatever the room has added. When the agent tries a host that is not on the list, the connection is held for up to two minutes while a card appears in the room naming the domain; any member can allow it, which applies immediately, or deny it. If nobody answers, the request fails and that domain is refused for the next five minutes so a retry loop cannot stall the turn. There is deliberately no auto-approve: agents run while nobody is watching, and an injected instruction could exfiltrate a project simply by waiting for a timer. Every blocked attempt is logged against the project.

3. No secrets inside the sandbox

If the sandbox holds an API key, every member and every instruction in the repository can read it. The right number of provider keys inside a shared sandbox is zero.

Poly's platform keys never enter a sandbox. A turn authenticates to an internal gateway with a single-purpose token minted for that turn, tied to that runner, and expiring with it; the gateway swaps in the real key at the moment it dials the provider, meters the spend, and enforces a per-turn cap and a daily circuit breaker. Members never hold API keys at all. Repository tokens for GitHub sync are injected per command and never written to git configuration. And every piece of text that reaches the room, including the agent's streaming output, passes through a redaction step that scrubs anything shaped like a provider key or a GitHub token, so a key that somehow lands in a prompt or a file does not land in the timeline.

4. A human says yes before the agent acts, from any seat

Approval is only useful if the person watching can give it. In a shared session that means every member, not just whoever typed the prompt.

Each Poly room chooses how much the agent does on its own: show a plan first, ask before big steps, ask about everything, or just build. In "ask about everything", every file edit and every shell command becomes a card on every member's screen, written in plain language ("wants to add a tool (stripe)", "wants to change src/checkout.ts"), and the first person to decide, decides. An approval nobody answers within thirty minutes is treated as denied. When the agent asks a question, members' picks are visible live before anyone submits. The room's owner can lock the working mode so nobody loosens it mid-project.

5. Attribution for everything, and a way back

A shared agent needs an audit trail a person can read: who asked, what changed, what it cost, and how to undo it.

In Poly every prompt carries its author. Every turn ends as its own git commit, attributed to the person who asked for it, with a receipt in the timeline naming the model, how long it ran and how many credits it used, charged to that person. Any member can revert any turn from its receipt. The room's decision log records every approval, denial and answered question with a name beside it.

6. Somewhere to talk that the agent cannot read

Prompt injection between teammates is inherent to a shared agent: anything typed into the session is an instruction. The defence is a channel that is not the session.

Poly's group chat, threads and polls sit beside the timeline and are never part of any prompt. The team argues about the plan there, and only what someone deliberately submits becomes an instruction. It is a small design choice with a large effect, and it is rare: most shared-agent products put people and the agent in one thread on purpose.

Where the alternatives stand

Read from public documentation in September 2026 and described as fairly as we can. Verify anything that matters to you.

• Coder sells self-hosted, governed cloud development environments for developers and agents, with the network, identity and image controls an enterprise platform team expects. It is infrastructure you operate rather than a room a small team opens in a browser, and its collaboration model is per-developer workspaces rather than one shared session.
• AQ runs real agent CLIs on a dedicated VM, in your own cloud on its Team plan, and teammates join the same live terminal and preview. Credentials stay per user. Its approval mechanism is a control-request handoff for someone else's terminal; we found no per-action approval gate in its docs.
• Superconductor runs each agent in a cloud sandbox with configurable network access, role-based access and live previews. Its published position is that sandbox isolation plus review at the pull request replaces per-action approvals. Model tokens are yours to bring.
• 143, open source from Assembled, runs Codex, Claude Code and OpenCode in gVisor sandboxes and has agent reviewers approve pull requests by policy. It is asynchronous infrastructure you can self-host; "approval" there means agents approving PRs, not people approving agent actions.
• Linzumi runs the agent on your own machine and gates network egress, credential reads and repository writes on operator approval, with port forwards that end when the thread does.
• Claude Tag, Anthropic's shared Claude in a Slack channel, runs each thread in an ephemeral sandbox and is sold on Team and Enterprise plans.

What Poly does not claim

Poly is an open beta from a small team, and saying so is part of the security posture. Hosts on the allowlist are reachable by design, so a hostile instruction could still send a project's own files to, say, a GitHub repository; the mitigations are the per-room allowlist, the room seeing every new domain, and the spend caps. Members of a room can influence each other's turns, because that is what sharing an agent means; the approval and revert mechanics exist for exactly that. There is no compliance certification to point at yet. The rules above are enforced in code rather than by policy, and the design documents behind them are what we would show you if you asked.

Try it

A room takes a minute to open and needs no API keys. Start free, invite one person, and watch the first approval card land on both screens.