Agent safety comes from limiting the tools and context that flow into a harness, rather than from the harness itself.
2
Separate sandboxes can keep untrusted input away from dangerous tools by assigning each stage of a workflow only the capabilities it needs.
3
An MCP gateway gives every sandbox one control point for tools, resources, prompts, and authorization, while keeping credentials out of the sandbox.
Summary
Jim Clark argues that agents can run for longer without supervision when their sandboxes contain only the context and tools needed for the current task. A harness is a loop that receives context and emits tool calls, while MCPs give it access to outside resources and actions. Safety therefore depends on controlling what enters the harness. Clark illustrates this with a newsroom split into researcher, fact-checker, and publisher sandboxes, and with a coding agent that receives Git signing keys only during the short period when it commits. He recommends one MCP gateway endpoint per sandbox, so the gateway controls available tools, resources, and prompts while different harnesses remain interchangeable. His strongest rule is that credentials should never be stored in the sandbox. Cross App Access can let agents use existing company identity and authorization systems. Orchestrators can build sandboxes from task intent, network rules, work trees, and progressively disclosed MCP capabilities.
Safety comes from controlling the context and tools entering the harness
Clark says the current problem is that agents run for longer periods with less supervision. A harness is a loop that takes context and asks the model to perform actions, but MCPs let it pull in outside context and tools. That makes the sandbox boundary important. If a sandbox has the resources and tools required for a task, and only those resources and tools, the possible blast radius is smaller. Clark says teams should focus on harnessing the tools and context flowing into the harness rather than treating the harness itself as the main safety boundary.
Smaller sandboxes let agents run longer with less supervision
Clark describes a sandbox as the place where an agent does its work. Early coding agents might have treated the whole laptop as the sandbox, including all of its tools and data. He argues that the boundary should become smaller and should match the task. The goal is not to sandbox the harness, which he describes as relatively simple. The goal is to limit the tools and context available to it. A smaller sandbox makes it easier to let an agent run for longer because fewer unrelated capabilities are exposed if the agent behaves incorrectly.
A newsroom workflow should split research, checking, and publishing
Clark uses a newsroom to show how one workflow can be divided into separate sandboxes. The researcher can access the web and perform broad research, but cannot write to the corporate site. It stores its output in a temporary, private location. The fact-checker runs in another sandbox with no network access, while reading the research and using a fact database. The publisher receives filtered research and has access to a publishing MCP, but does not need network access. Each stage can have useful capabilities without combining untrusted input with dangerous tools.
Credentials should be supplied only when the task intent requires them
Clark's coding agent may run for about an hour and make commits during that work. The agent needs Git signing keys only during the short period when it is creating a commit. It does not need those keys while it is doing the rest of the work. He therefore models the sandbox around the current intent: if the agent is not making a commit, the signing keys should not be present. He says the same approach can apply to other tasks, with capabilities granted according to what the agent is doing at that point.
One MCP gateway gives each sandbox a single control point
Docker's sandbox design places a gateway endpoint inside the sandbox and routes all MCP traffic through it. The endpoint handles requests for resources and tool calls from the agent harness. The gateway can then control which tools, resources, and prompts are available in a particular sandbox. Clark says this also keeps harnesses MCP-agnostic. A team can use Codex, Claude Code, or another harness without configuring every MCP integration separately in each harness. The sandbox determines which harness, MCPs, and network rules are used together.
Cross App Access can connect agents to existing company authorization
Clark describes Cross App Access, or XAA, as a way for an agent to use identity and authorization systems a company already has. Companies may already use SSO with services such as Notion, Atlassian, GitHub, and Slack, but that access is not automatically available to an agent. The sandbox and gateway can define the agent identity and exchange identity claims with the existing identity provider. An authorization grant can then give the agent access through the same authorization servers. Clark says this avoids creating a separate identity system for every agent integration.
Progressive disclosure keeps unused tools out of the sandbox
Clark applies progressive disclosure to MCP tools and resources. An entire workflow might use many MCPs, but an individual sandbox does not need all of them at once. The gateway can disclose capabilities as the task requires them, which also keeps the agent's context smaller. The sandbox should express the intent of the current task, rather than the full set of capabilities used by the workflow. This lets an agent solve the task while keeping unrelated tools and resources outside its immediate reach.
An orchestrator can construct a sandbox from the task
Clark describes an orchestrator as responsible for deciding what a task needs before placing it in a sandbox. It selects a harness, determines which MCPs are allowed, sets network rules, and chooses resources and work trees. A task might need access to api.github.com, broad web access, or no network access at all. The orchestrator builds those limits around the task's intent. Clark says the individual agent loop becomes safer because it has less access than the entire workflow would have if all capabilities were available at once.
"We break it up into logical sandboxes, so at each individual point, we don't have a dangerous combination of both being able to read in crazy unfiltered context and do things with our tools."08:25
Who should watch
You are letting coding or research agents run for long periods and need to decide what they can access while you are away.
Your workflow uses several agent roles and you want to stop research output from reaching publishing or write tools without an intermediate boundary.
You are building an MCP platform and need one place to manage tools, resources, prompts, identity, and authorization across different harnesses.
