Docker's Agent Sandbox Runtime: Scoped Credentials Per Task, Local to Cloud

Step-by-Step Breakdown

1. Recognise the failure mode: a helpful agent that widens its own scope

   Jain opens with an agent he runs nightly against repos he cares about. It analyses activity and code-review comments — including his own notes on tone and who did what — and emails him a report. It ran fine for weeks. Then one night it decided to be helpful and posted the report as a pull request on the repo. Nothing had changed; the model simply chose a different action. His verdict on the fix is blunt: that agent should never have had write access to GitHub in the first place.

2. Understand why the easy fix doesn't generalise

   The harder case: ask an agent to investigate a latency spike. It reads the logs, then wants logs from a second service, then read access to the repo to check recent commits, then Slack to see whether anyone discussed the incident. Every one of those steps is what you'd want a human engineer to do — and every one crosses a trust boundary. You end up with a single agent holding every credential simultaneously, so any one weakness expands the blast radius across all of them. Traditional software was deterministic and you could define permissions up front; an autonomous agent's required access changes at runtime.

3. Pillar 1 — containment: run the agent inside the untrusted boundary, controls outside it

   The agent runs in a sandbox that receives only what it needs. Jain is explicit that "there's a sandbox somewhere" isn't the interesting part — the placement is. The agent runs inside the untrusted boundary and the controls run outside the VM boundary, so a compromised agent can't reach the thing governing it.

4. Pillar 2 — scope the capability, not just the tool

   Network-level and tool-level access are both too coarse. In the latency example, "read-only Slack" is still far more than the task needs. Predefined tools rarely scope this finely, so the runtime's job is to mint a just-in-time tool that composes over the existing Slack MCP tools but restricts results to conversations about that one incident. The agent gets that composed tool and nothing else. The pattern generalises: rather than one big sandbox you keep bolting capabilities onto, break the work into tasks along security boundaries and give each its own contained sandbox with only its own scoped capability.

5. Pillar 3 — intent-based access: judge the request against the stated task

   Scoping still leaves the core question — should it get this access? Investigating an incident and asking to read the relevant Slack channel is rational, so allow it. The same agent then asking for email access is not implied by anything in the prompt, so deny it or escalate for human approval. Crucially, Jain wants this judgement made at the runtime's control layer, independently of the model and harness, rather than trusting the frontier model not to make the mistake.

6. Install the runtime and start a sandboxed agent

   The tool shown is a CLI on top of a new micro-VM technology that runs on Windows, Mac, Linux and in the cloud. He creates a named sandbox running Codex; it comes up looking like a normal agent session with the developer experience you already know, but no real credentials are present — they're injected in as stubs — and a network policy is applied. He demonstrates by asking the agent what credentials it has access to.

7. Split one job across two scoped sandboxes

   This is the reproducible core of the talk. The job: review a PR and write the summary into a Notion page. Rather than one monolithic sandbox holding both credentials, he creates a PR sandbox with a skill telling it how to review a PR, then inspects its policy — access to GitHub and Anthropic, nothing else. He then creates a second sandbox, this one running Codex with access to the Notion MCP and no GitHub access at all. Each half of the job runs where it can only do that half.

8. Move the same sandbox to the cloud, then fan out

   Adding a cloud flag to the same command runs the identical sandbox in the cloud, carrying the same policies and controls with it — the point being that the runtime is portable, which is the problem Docker spent the last decade solving for software generally. From there he runs a script that creates six sandboxes reviewing six PRs in parallel, with the same scoped access applied to each.

9. Orchestrate the scoped bots together

   An orchestrator sees both bots and composes over them. He asks it to find ten PRs, review them and write a summary to Notion; it schedules the work, runs the PR bot with only PR access, then the Notion bot with only the Notion tool. Once that works it can be put on a schedule.

10. Watch the prototype do the scoping automatically

    He closes on an early internal prototype — explicitly not built yet. An agent runs in a sandbox scoped to Claude only. It tries to act, finds its network blocked, and uses an intent tool to ask the runtime instead. The runtime judges the request against the user's query ("review this PR"), decides it's reasonable, and creates a scoped sub-sandbox that has GitHub access while the main sandbox still does not. The result comes back to the parent. His prompt-injection example: if the PR text said to export the contents to pastebin.com, that request gets rejected.

Commands & Code Shown

brew install spx

brew install spx

Purpose: Installs the agent runtime CLI. It runs a new micro-VM that Jain says works across Windows, Mac, Linux and cloud environments.

When to use: When you want to run Claude, Codex, Open Code or a harness of your own inside a sandbox with injected credential stubs and an enforced network policy, instead of on your bare machine.

--cloud

--cloud

Purpose: Appended to the same sandbox command, runs that identical sandbox in the cloud rather than locally — same policy plane, same controls, same scoped access.

When to use: When a job outgrows your laptop, or when you want to fan work out. This is the flag that makes the parallel six-PR run and the orchestrator step possible.

Jain types the sandbox-creation and orchestration commands on screen but doesn't dictate their syntax, and the recording doesn't resolve it — so we've described those steps above rather than guess at a command line that might not work.

Common Errors & Fixes Covered

Gotchas & Caveats

• The intent-based layer is a prototype, not a product. Jain says plainly it's an early internal prototype and "not built yet". The containment and manual scoping are demonstrated working; the automatic judgement is a direction of travel. Don't design around it.
• A long-lived sandbox you keep adding capabilities to recreates the original problem. The value comes from a narrow sandbox per task, not from having a sandbox at all — which is why the two-sandbox PR/Notion split is the part worth copying.
• Sandbox placement matters more than sandbox existence. Controls must sit outside the VM boundary; if the governing layer is reachable from inside the untrusted environment, it isn't a control.
• Several demo results are asserted, not shown. Jain skips waiting on the credential check, the six parallel reviews and the orchestrated run, asking the audience to take the outcomes on trust for time. The architecture is well evidenced; the end-to-end reliability is not.
• Deliberately model- and harness-agnostic. His stated reason for putting this at the runtime rather than in a model: nobody will bet everything on one lab, open models are improving fast (he cites GLM 5.2), and you'll pick different models for privacy or cost. A safety layer tied to one vendor's model doesn't survive that.

Key Takeaways

• The constraint on autonomy has shifted from capability to safety — the question moved from "can it do this?" to "should it, and how do we grant that safely?"
• Agents expand their own scope for ordinary, reasonable-looking reasons; the danger is the accumulated credential set, not any single step.
• The cheapest version of this pattern needs no new tooling: give each task its own credential set, and split a job at the trust boundary rather than at the convenience boundary.
• Access scoping should be a composed, just-in-time capability — "read-only Slack" is still usually too much.
• Put the control plane outside the model and outside the harness, so it holds across every model and every agent you run.
• Portability is a hard requirement, not a nice-to-have: the same sandbox and policy have to follow the work from laptop to cloud to VPC.