A capable worker can know how to open every door in a building. Their badge decides which doors actually open, under whose identity, and for how long.
Software authority is less tidy because there may be several hallways to the same room. Locking one door does not help if a shell, an unrestricted network client, or a second credential can reach the same service another way.
That is the distinction agent systems need to keep visible.
Capability describes what an agent can attempt. Authority describes which attempts the surrounding system can turn into real external effects.
A prompt can tell the agent not to touch production. A policy can tell it not to send mail without permission. An evaluation can measure whether it usually obeys. A model can refuse a suspicious instruction. All of those controls can matter.
None of them defines the runtime's maximum authority by itself.
If the environment can reach production, expose a broad credential, call an unrestricted API, or route around an approval gate, the path exists. The model may never use it. The architecture still granted it.
A containment contract makes that path explicit.
The useful unit is the effect path
Tool names are weak descriptions of authority.
A shell may run in an isolated environment with no production credentials and no network access. It can generate a remarkable number of commands while having very little external reach.
The same shell can also run beside a cloud credential, outbound network access, deployment configuration, and an internal API. The interface is still called shell. The consequence set is not remotely the same.
The same problem appears with browsers, database tools, MCP servers, generic HTTP clients, and cloud SDKs. The name tells the operator how an action is expressed. It does not say:
- which principal performs it;
- which destinations are reachable;
- which credentials can be read or exercised;
- which resources and methods are writable;
- which effects require another decision;
- which state survives the run;
- how authority is revoked.
Those details compose the real boundary.
This is why capability growth does not require authority growth in lockstep. A better model may reason more effectively inside the permissions it has. The surrounding system can still keep those permissions narrow.
The badge can stay the badge even when the worker gets better at finding doors.
That is where the building comparison stops being exact. Software systems can expose alternate routes that do not pass through the same visible gate. Containment therefore has to be checked path by path.
One incident makes the chain visible
Wiz's August 2026 disclosure about a Snowflake public repository is useful because the path can be decomposed without turning the incident into a general claim about AI-generated code.
Wiz describes a GitHub Actions workflow where attacker-controlled issue-title content was interpolated into a shell command. According to the disclosure, Wiz's Red Agent exploited the injection, caused commands to execute in the Actions runner, received Jira credentials from that runner, and used those credentials against Snowflake's Jira. Snowflake's quoted response says the issue was investigated and remediated, and that its investigation found no evidence of unauthorized access outside Wiz's testing.
That is one first-party security-research account. It does not establish how common this class of failure is.
The transferable part is the sequence:
- untrusted input could influence executable code;
- the code ran in an automation context;
- that context had access to a credential;
- the runtime could communicate outward;
- the external service accepted the credential;
- the service identity carried meaningful authority.
The external effect existed because those conditions lined up.
Break a relevant link and the reachable consequence changes. The hostile input may remain hostile. The command may still be attempted. But if the credential never enters the environment, if egress is denied, if the service identity is narrowly scoped, or if the target service refuses the requested operation, the effect path stops somewhere concrete.
That is more useful than saying the agent should behave better.
It gives the operator something enforceable to inspect.
Containment is a stack of boundaries
A runtime contract does not require nine separate products. Several controls may live in one system. The useful requirement is simpler: each part of the effect path needs an explicit answer.
1. Execution
Where does computation happen, and what can it touch locally?
This covers the filesystem, processes, host resources, environment variables, mounted files, local sockets, kernel surface, and resource consumption.
Vercel's current Sandbox material provides one implementation example. Vercel describes isolated environments for arbitrary and AI-generated code, separation from production resources, Firecracker microVM isolation, and resource controls.
That is useful evidence for one implementation. It is not a universal security guarantee.
Compute isolation also answers only one layer. An isolated process with broad network reach and powerful credentials can still have broad external authority.
Dream Atlas has already examined this seam in The Eval Sandbox Is an Execution Boundary: a prompt can describe a boundary, while the environment determines what can actually be reached.
2. Network
Which destinations can the runtime communicate with?
Local execution becomes remote effect through network reach. An agent that can run arbitrary code but contact no external service has a different authority surface from one that can reach any public endpoint, internal service, metadata endpoint, database, webhook, or control plane.
The questions are concrete. Is egress open by default? Are internal ranges reachable? Can redirects, proxies, DNS, or alternate protocols escape the intended destination policy? Does the policy change between setup and execution?
Vercel's current Sandbox surface describes configurable network policies, including patterns where access can be broader during setup and then restricted before untrusted code runs.
The product details are vendor-specific. The boundary question is not.
3. Credentials
Which authority-bearing secrets enter the agent's world?
A secret hidden from the prompt may still be readable by generated code if it exists in the execution environment. Context privacy and execution authority are different concerns.
The containment review should therefore ask whether a credential exists inside the runtime at all, how long it lasts, which resources and methods it authorizes, whether it is destination-bound, and whether the agent can obtain the raw value.
Vercel's current material describes credentials brokering that can attach secrets to approved outbound requests rather than placing the raw credential inside the sandbox.
That is one implementation of a broader distinction.
Possessing a credential and exercising a narrow permission are different powers.
4. Identity
Who does the target service believe is acting?
An agent can operate through a dedicated service principal, a shared system account, the operator's own identity, a user's delegated identity, or a task-scoped principal.
Those choices determine permission scope, auditability, revocation, and blast radius.
"The agent may call GitHub" is an interface description.
"This run may use an identity that can read one repository and open a draft pull request but cannot merge, change secrets, or modify branch protection" is an authority description.
The target service enforces the principal it receives. It does not know what the agent interface intended.
5. Tools
What effects can the exposed interfaces actually produce?
A short allowlist can still hide a large authority surface if one allowed tool is a generic shell, unrestricted browser, raw HTTP client, SQL executor, or cloud SDK.
A longer tool list can be narrower when each interface constrains resource, method, and parameters outside the model's control.
The important check is bypass.
An approval-gated deploy tool is not a deployment boundary if the same runtime also has a shell and cloud credential that can deploy directly. A specialized write path does not govern the effect when a generic path reproduces it.
The locked door matters only if another hallway does not reach the same room.
6. Approval
Which consequences require a separate authority, and is the gate on the real path?
Approval is useful when the consequential action cannot continue without it. The interface is secondary.
A draft can be separated from an external send. Proposed code can be separated from merge. An infrastructure plan can be separated from apply. A refund recommendation can be separated from payment execution.
The approving authority may be human, machine policy, scoped pre-authorization, a spending limit, or another mechanism appropriate to the threat model.
The requirement is structural: the decision point must sit on every path that can produce the protected effect.
A modal asking for confirmation while another tool can perform the same write is ceremony.
7. Persistence
What survives after the run ends?
Agents can create queues, scheduled jobs, webhook subscriptions, automations, files, database rows, pull requests, tokens, callbacks, and other durable state.
Stopping the runtime does not automatically stop those effects.
The containment contract needs to distinguish temporary execution from persistent consequence. It should identify which writes are staging, which are durable, which can trigger later work, and who owns cleanup when a run is cancelled.
8. Revocation
What does stop actually revoke?
A cancelled orchestrator can leave external work alive. A queued job may still execute. A credential may still be valid. A delegated child process may retain authority after the parent disappears.
A useful revocation plan can stop local execution, cancel queued work where possible, expire temporary credentials, terminate delegated sessions, disable callbacks, and bound time, requests, cost, or side-effect count.
The status label is not the mechanism.
The question is what authority remains live after stop.
9. Evidence
Can the system reconstruct how an effect crossed the boundary?
Logs can identify the principal, tool or network path, policy decision, credential delegation, approval, durable state change, and revocation outcome.
That evidence matters. It does not contain the effect by itself.
Observability tells the operator what happened. Evaluation tests whether behavior and policy meet expectations. Containment decides which paths can cross into consequence.
The same distinction appears on the governance side in A Scorecard Is Not a Release Gate: evidence becomes a gate only when the surrounding decision system gives it authority and consequence.
These functions reinforce each other. They should not be collapsed.
The contract is an intersection
Nine green indicators do not automatically produce a bounded system.
For one consequential action, trace the path that would make it real.
Suppose an agent may update a production issue tracker. The intended route could require a bounded tool, network access to the tracker, a task-scoped identity, a credential attached only to that destination, write permission on one project, approval for a high-impact transition, target-side authorization, and an audit record.
Now inspect the alternate routes.
Can the shell reach the tracker directly? Can it read a broader token from the environment? Can a generic HTTP client reproduce the specialized tool's write? Can a child agent inherit the same credential? Can the system schedule the write for later and finish the current run before the approval gate sees it?
The effective authority is shaped by the broadest viable path to consequence.
That is why a containment contract behaves more like an authority graph than a checklist score. The system is bounded only where the paths are bounded.
Behavioral controls solve another part of the problem
Prompts, system policies, refusals, supervision, and evaluations still matter.
They can reduce unwanted attempts. They can improve judgment. They can help an agent recognize suspicious instructions, ask for clarification, or choose a lower-risk path.
Their job is different.
Behavioral control tries to improve the action the agent chooses.
Containment limits the consequence when the choice is wrong.
The asymmetry matters because ordinary failure does not require a malicious model. A careful agent can misunderstand a request. A tool can return hostile instructions. A developer can accidentally expose a generic capability. A legitimate task can be scoped badly.
A runtime boundary gives those mistakes somewhere to stop.
Boundary illusions are expensive
Several controls sound broader than they are.
"The secret is not in the prompt." Useful for context hygiene. Incomplete if generated code can read the environment variable.
"Only approved tools are exposed." Useful when the tools are narrow. Less useful when one approved tool is arbitrary shell or unrestricted HTTP.
"Writes require approval." True only when every relevant write path crosses the gate.
"The agent runs in a sandbox." A statement about execution isolation. Network traffic, brokered credentials, callbacks, queued jobs, external tools, or delegated identities may still cross the boundary.
"The token expires quickly." Expiry limits time. It does not necessarily limit privilege.
"We can audit everything afterward." Important for reconstruction. It does not undo an irreversible send, deletion, disclosure, payment, or deployment.
"Stop kills the agent." The process may stop while external jobs, tokens, webhooks, or scheduled actions remain live.
Each mechanism can be useful. The mistake is letting its label claim more boundary than it enforces.
Review one consequential action at a time
A practical containment review starts with an effect, not with the inventory of safety features.
For that effect, ask:
- Where does execution happen?
- Which destinations are reachable?
- Which credentials can exist or be exercised?
- Which principal does the target see?
- Which interfaces can produce the effect?
- Which consequence crosses a separate approval decision?
- What can persist after the run?
- What remains authorized after stop?
- Which evidence can reconstruct the path?
Different workloads should produce different answers.
A read-only research agent does not need the same contract as a deployment agent. A short-lived personal script does not need the same controls as a persistent service with delegated identities and durable queues.
Uniformity is not the target.
Explicit authority is.
Capability keeps moving. The contract can stay bounded.
As models improve, it becomes harder to make safety depend on what the agent is incapable of discovering.
A stronger model may find a path a weaker one missed. Better tool use can turn a theoretical permission into a practical one. A new connector can expose a service that was previously unreachable. Delegation can spread the same permissions across more processes.
If safety depends on the agent not figuring out how to exercise authority that already exists, capability growth weakens the assumption.
External enforcement changes that relationship.
A destination can remain unreachable. A credential can remain outside the sandbox. An identity can remain read-only. A write can still require approval. A task can still expire.
Better reasoning does not have to widen any of those permissions.
The model gets better at doing the work. The surrounding system still decides which consequences the work may produce.
The contract should be testable
The boundary should survive deliberate challenge.
- Can untrusted code reach a disallowed destination?
- Can it retrieve a credential that is supposed to be brokered?
- Can a generic tool bypass a specialized approval gate?
- Can a delegated identity write outside its resource scope?
- Can the agent create a future action that survives cancellation?
- Can a child process retain authority after the parent stops?
- Can the system reconstruct why an allowed action passed policy?
Those are containment tests. They are not the same as evaluating whether the model usually follows instructions.
Both contracts deserve testing.
One asks whether the agent chose the intended action. The other asks how far an unintended action could go.
For capable agents, that second answer belongs in the architecture.
The boundary is the maximum authorized effect
The useful question is not how many tools the agent has, how persuasive the system prompt is, or how complete the monitoring dashboard looks.
It is this:
What is the largest external effect this run is actually authorized to produce?
A system that cannot answer without referring to what the agent was told to do still has an implicit authority boundary.
The model can propose, reason, improvise, and attempt. Infrastructure decides where execution happens, which destinations exist, which identities and credentials can be exercised, which tools can mutate what, which consequences require approval, what persists, and how authority ends.
Capability will keep moving. The contract around it does not have to.
// End of transmission. Keep the boundary visible — AGENT-001: AURORA