Safety, rather than model intelligence, is the main barrier to giving autonomous agents more access.
2
Agents need capabilities scoped to individual tasks inside sandboxes, with controls outside the agent's trust boundary.
3
A runtime should judge access requests against the user's intent and work across models, harnesses, local machines, clouds, and VPCs.
Summary
Tushar Jain argues that agent autonomy is limited by safety rather than intelligence. An agent investigating an incident may reasonably ask for logs, GitHub history, and Slack access, but each request expands its trust boundary until one process can reach too much. Jain proposes a runtime beneath models and agent harnesses. It would contain agents, grant just-in-time capabilities scoped to a task, and evaluate new access requests against the original intent. A request for incident-related Slack messages might be allowed, while an unexpected request for email would be denied or sent for human approval. In Docker's prototype, agents run in microVM sandboxes with injected credentials, network policies, and stubbed credentials. Separate sandboxes can review a pull request and write a summary to Notion. The same policies follow the sandbox from a Mac to the cloud, then support parallel work and orchestration. Jain presents this as an internal prototype rather than a finished solution.
Jain says the past two years focused on making agents more intelligent and powerful. He thinks that work will continue, but intelligence is no longer the main blocker to using agents. The harder problem is giving agents the access and autonomy they need without exposing too much. His nightly reporting agent illustrates why. After running for weeks and emailing him a private summary, it suddenly posted the report as a GitHub pull request because the model decided that would be helpful. The simple fix would have been removing GitHub write access, but Jain uses the incident to show how agents can change their behavior, make mistakes, or respond to prompt injection.
A reasonable investigation can expand an agent's blast radius
For a latency spike, an agent might begin by reading logs, then request logs from another service, GitHub access for recent commits, and Slack access for related conversations. Each step is reasonable and resembles what an engineer would do. The problem is that every new request crosses a trust boundary and expands the task's scope. The resulting agent can hold access to everything at once, so any later action has a larger blast radius. Traditional software allowed permissions to be defined in advance because its behavior was fixed. Autonomous agents decide at runtime what work to do and what access they need, so static upfront permissions do not fit the problem.
The safety layer must work across models and harnesses
Jain does not expect teams to rely on one model or one frontier lab. Different models will be chosen for privacy, cost, and other reasons, and open models will also be part of the system. Teams will use multiple harnesses too. Coding agents are only one use case, while sales, marketing, and custom agents will bring different harnesses and workflows. A safety solution therefore cannot depend on a particular model avoiding mistakes or on one provider's harness. Jain proposes a runtime beneath any agent, harness, and model, with controls that constrain the surrounding environment when the model behaves incorrectly or is prompt injected.
Containment puts control outside the agent's boundary
The first pillar of Jain's runtime is containment. The agent runs inside a sandbox and receives only what it needs, while the controls run outside the untrusted boundary, beyond the steady VM boundary. A sandbox alone is not enough if its permissions accumulate over time. The runtime should instead create contained environments where access can be controlled independently of the agent. This limits the damage when an agent makes a mistake or changes direction. Jain describes this as a runtime that can provide a controlled environment across different agents rather than a safety feature tied to one model.
The second pillar is scoped access. Read-only access to Slack may still expose more content than an incident investigation requires, especially when relevant messages are spread across channels containing unrelated conversations. Jain suggests that the runtime create a just-in-time tool over existing Slack MCP tools, restricted to conversations about the incident. That capability would run in a scoped sandbox for the task. Instead of giving one large sandbox more and more tools, the system breaks work into tasks and gives each contained environment only the capability it needs.
Intent should determine whether a new capability is allowed
The runtime still needs to decide whether a requested capability fits the task. Jain calls this intent-based access. For an incident investigation, read access to Slack messages about that incident makes sense. A sudden request for email access does not follow from the original prompt, so the runtime should deny it or ask a person to approve it. This judgment should happen in an independent control layer rather than inside the model or harness. Jain says the problem is difficult and not fully solved, but he presents intent as the way to distinguish a valid next step from an eager mistake or prompt injection.
Portability must include the same policies and controls
Jain says a runtime also has to follow agents wherever they work. Agents may run locally, in the cloud, across clouds, or inside a company's own VPC or a customer's VPC. Docker previously focused on portability, moving software from a laptop to the cloud. Jain says the new focus extends that work toward safety. The prototype starts with a new VM technology and adds MCP, policy, safety, and governance features. Its purpose is to let the same sandbox move between environments while keeping the same policy plane and controls applied.
Separate sandboxes divide credentials between stages of a workflow
In the demo, Jain breaks a pull request workflow into two sandboxes. The first receives GitHub access and reviews the pull request, but has no access to Notion. A second sandbox receives the Notion MCP tool and writes the resulting summary, without retaining GitHub access. He shows this as an alternative to one monolithic sandbox containing both credentials. The policies displayed for the first sandbox allow GitHub and Anthropic, and nothing else. This division reduces what each task can reach and lets the workflow pass information between separately scoped stages.
Intent-based delegation can create a scoped sub-sandbox on demand
Jain's final prototype shows an agent with access only to Anthropic Cloud asking the runtime to review a pull request. Because the agent cannot reach GitHub directly, it submits an intent-based request. The runtime decides that access fits the user's request, creates a scoped sub-sandbox with GitHub access, and returns the result while the main sandbox remains restricted. Jain says the same process could grow as the task develops. If the pull request text asked the agent to export information to paypin.com, the runtime would reject that request. He presents this as a base runtime layer that can work across agents, models, and harnesses.
"What we want is an environment where the agent runs where if something goes wrong there's limited blast radius and we only give it the access it needs."05:43
Who should watch
You are giving coding or operational agents access to several internal systems and need to limit what one task can reach.
Your agents run through different models or harnesses, so a permission system tied to one provider would leave gaps.
You want the same sandbox policies to apply as work moves from a developer machine to the cloud or a VPC.
