Four vendors released agent containment inside one week this month. A fifth got there first in late September.
Microsoft took Microsoft Execution Containers to general availability on October 7. AWS open sourced Strands Box the same day. StreamNative open sourced Orca Agent Engine, its runtime, on October 6. Factory put Environments into general availability on October 12. Docker announced the Sandbox Kit specification in late September and said it was bringing it to the CNCF.
Different companies, different products, and they do not enforce policy in the same place. Factory keeps the decision inside the harness. AWS, Microsoft and Docker put policy outside the agent workload. Orca keeps guardrails outside the agent’s editable configuration. The shape still repeats. A hard boundary decides what an agent can reach. A policy layer decides what the agent may do with what it reached. Behind that layer, some of them keep the credential where the agent cannot read it.
I already argued that the gate matters more than the brain. This post goes one level down, to where the boundary sits and where the credential lives.
The two layers
Containment is the first layer, and it belongs to the operating system. Microsoft maps one policy onto AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux. Strands Box starts with macOS Seatbelt. Docker puts every sandbox in a microVM with its own kernel.
Policy is the second layer. It sits where an agent’s operations cross the containment edge. AWS names four interception points: network egress, a shell interpreter, a Python interpreter, and a broker for MCP tool calls. The interpreters and the broker do not run inside the sandbox. They run in Box’s own process, and the agent reaches them as ordinary bash, python3, and MCP commands over a local socket.
The boundary has to belong to someone else
“An agent cannot be its own security authority.” That is Microsoft’s sentence, and I think it is the thesis of the quarter. Microsoft writes that policy remains outside the agent workload’s control, so the agent or the code it generates cannot grant itself more access.
AWS makes the same argument against the permission systems that ship inside harnesses. Those prompts and allowlists run in the agent’s own process, and they judge the tool call rather than its effect. A harness sees “run this shell command.” It does not see the files the command will touch or the hosts it will reach.
In-process rules read well, because the model can see them and reason about them. The problem is where they sit. They live in the same process as the agent they constrain, so they share its trust boundary. The model reads them, and code in that process can rewrite them. AWS’s answer is to move the decision outside the process.
Moving it out is a trade-off, not a free win. AWS calls running the interpreters outside the sandbox deliberate: they are the code that enforces policy, so the box’s trusted computing base is wider. A bug in an interpreter would be a bug in the trusted runtime, not only in the sandbox.
Operations, not syscalls
AWS intercepts at the level of operations, so the policy sees the file and the operation instead of an opaque syscall. A file read through a shell command or a Python script reports as an fs:read event. An HTTP request from curl or from Python reports as http:request. When the agent runs rm -rf build/, the shell resolves the command and raises an fs:delete decision for every file it would remove, so a forbid rule stops it before a byte is deleted.
The rules are Cedar syntax, and they are history aware. AWS’s example caps Slack posts at three per ten minutes, counting the ones that returned HTTP 200 and ignoring the refusals. The policy does not trust the agent to remember the limit. It reads the record. When a rule denies, the gateway returns HTTP 403 naming the rule, so an agent that can read its own error can wait instead of retrying.
The key never enters the sandbox
AWS states the mechanism plainly. On a configured API-key route, the agent receives a placeholder token, and the egress gateway replaces it with the real secret before forwarding a permitted request. The real secret never enters the agent’s environment.
Orca does the same thing with a vault. Provider credentials stay in the vault and are resolved at the gateway rather than passed into the sandbox. Docker’s CISO showed the move in his keynote, with a proxy that uses a credential without exposing the raw API key inside the sandbox.
AWS and Orca document the same move. Docker demonstrated it. The process that uses the key is not the process that holds it. An agent that never holds the real secret cannot leak it into a log, a commit, or a prompt. It still gets the request it wanted.
The binding to check is between a credential and its destination. AWS pairs each secret with a destination list in box.toml, and the gateway swaps a placeholder only for a host the policy already permits. If that binding is loose, a placeholder is a key with a longer name. It is the first thing I would test.
Where each one cuts
The five differ in where enforcement sits, and in how much they say about credentials.
| Product | Containment | Interception and credentials |
|---|---|---|
| Microsoft MXC | Process container on Windows, macOS and Linux, a Windows-only session container with its own account and desktop, a Windows-only WSL container, and an experimental microVM | One JSON policy mapped onto the selected backend and kept outside the workload; credential management comes from partners such as NVIDIA’s OpenShell |
| AWS Strands Box | macOS Seatbelt | Network egress, a shell interpreter, a Python interpreter and an MCP broker, all outside the sandbox; the gateway swaps a placeholder token for the real key |
| Docker Sandboxes | A microVM per sandbox | An OCI image declares the access the Kit wants; a conforming runtime enforces it outside the agent, and a proxy uses the credential without exposing it |
| Orca Agent Engine | The harness server runs built-in tools in a sandbox | Guardrails outside the agent’s editable configuration; allow, ask or deny with the strictest scope winning; credentials resolved from a vault at the gateway |
| Factory Environments | Prebuilt sandbox images, rebuilt and validated every few hours | Admins set hosts, shell commands, connectors and skills; the harness stops a blocked command before it runs. No credential broker is described |
Containment shipped before attribution
MXC gives an agent its own identity only inside the Windows session container, where it runs under a distinct account in a separate session. The part that ties an action to an agent instead of a person is still coming. Microsoft says Entra will distinguish agent activity from user activity in Agent 365, and that Intune policy will manage MXC containers. Both are described as coming soon.
Docker’s CTO was asked about it directly. He described per-team policies that give a finance user and a developer different access to the same agent, then said that agent identity remains an open industry challenge.
Orca names the requirement more directly than the others. Its post says an agent needs an identity, an isolation boundary, and a budget, and it records each session in an event log. Its announcement describes events and approvals, but does not show a task-scoped delegation record.
So the field shipped containment before attribution. I can contain an agent well and still fail the question an auditor asks. On whose authority did it act? A sandbox id and a rule id describe the box. They do not describe a principal who delegated authority, a scope, or an expiry.
A machine account per agent is the current workaround, and it beats running as the user. It ties authority to the agent instead of the task. If one agent serves two people, its account alone cannot tell me which delegation a request used. What I would want instead is a scope that belongs to the task and names the principal it came from.
If I were building the missing layer, I would attach a delegation record to every action the policy engine judges. Which principal the agent acted for, what scope was granted, and when it expires. The engine already sees the action. It is the one place that can also see the authority.
Most of that drawing is shipping product. The boundary is an operating-system feature, the interception points are a proxy and a pair of interpreters, and the gateway hands the agent a placeholder instead of the key. The delegation record is the part I would still build. Microsoft says its identity layer arrives soon, and Docker calls the problem open. I believe the first. I would design around the second.