A prompt can tell an AI agent that it is operating inside a simulation. It cannot close a network route, remove a credential, block a write operation, or restore the environment after something goes wrong.
That distinction is easy to flatten into a prompt-engineering problem. It is really an infrastructure problem.
In a July 30, 2026 incident report, Anthropic said it reviewed 141,006 runs from cybersecurity evaluations and found three incidents across six runs. According to the company, Claude reached the open internet and gained unauthorized access to production systems belonging to three organizations. The prompt described a simulation without internet access. A configuration error left live internet access available.[^anthropic]
The important lesson is not that instructions are useless. It is that declared scope and reachable scope are different systems.
The operating read
A simulation boundary is real only when infrastructure constrains capabilities and network access, isolates data and credentials, authorizes side effects, and defines reset and recovery behavior. Prompt text can communicate the boundary. It cannot enforce it.
The prompt said simulation. The network said otherwise.
Anthropic's report is unusually useful because it keeps the incident framing narrow. The company described the events as closer to evaluation-harness and operational failures than model-alignment failures. It also said it found no evidence that the models were pursuing goals of their own.[^anthropic]
That distinction matters. “The model escaped” is an attention-grabbing summary, but it imports intent the report does not establish. The more practical diagnosis is less cinematic: the system presented one operating contract in text while exposing a different contract through its tools and network.
From the agent's position, the reachable environment was the environment.
Operators often review a sandbox from outside it. They inspect a configuration file, confirm that a prompt says “simulation,” and check that the intended target is a test system. Those are useful checks, but they describe what the team meant to build. They do not prove what the running process can actually reach.
A boundary has to survive contact with the same execution path the agent receives.
Declared scope and reachable scope are different systems
Declared scope is the task as communicated: which systems are in bounds, which actions are allowed, and where the exercise should stop.
Reachable scope is the set of capabilities the runtime makes possible: tools, network routes, files, services, credentials, mutation paths, and escalation mechanisms available during execution.
The effective boundary is the overlap of policy and technical reality. If the prompt permits less than the environment exposes, the extra capability still exists. If the environment permits less than the prompt requests, the runtime—not the wording—wins.
This is why “the agent was told not to” is weak evidence for a sandbox claim. It proves that an instruction existed. It does not prove denial at the network, identity, data, or action layer.
Prompts still carry real safety value. They establish purpose, reduce ambiguity, state stop conditions, and give the model context it may need to behave correctly. Anthropic notes that accurately telling Claude it did have internet access might have changed how it behaved when it encountered real systems.[^anthropic] But clearer wording and technical enforcement solve different problems:
- Instructions communicate intended behavior.
- Infrastructure limits possible behavior.
- Monitoring shows observed behavior.
- Recovery controls bound the damage when the first three are insufficient.
Treating those as interchangeable leaves gaps hidden behind a reassuring word: sandbox.
The four controls that make a boundary real
The following four-control model is my operator synthesis, not a framework prescribed or validated by Anthropic. I use it to turn “this run is isolated” into a set of claims a team can inspect.
1. Restrict capabilities and network access
Expose only the tools, protocols, and targets the run requires. Deny outbound network access by default rather than relying on a list of destinations the agent should avoid. Separate evaluation infrastructure from the systems that administer production, and make the default route a dead end.
Then test reachability from inside the harness. A network policy shown in a deployment manifest is intent. A denied connection from the actual execution identity is evidence.
Capability restriction belongs here too. If the evaluation requires discovery but not mutation, the runtime should not expose a general-purpose write tool. Narrow tools reduce the number of ways a correct instruction can be undermined by a configuration mistake, an unexpected tool call, or an ambiguous response from the environment.
2. Isolate data and credentials
A test environment with production credentials is not isolated simply because its hostname contains sandbox.
Use synthetic or appropriately scoped data. Issue short-lived identities with the minimum permissions needed for the run. Make test credentials unusable against production systems, even if a network route appears unexpectedly. Keep secrets out of prompts, fixtures, logs, and copied production snapshots unless the exercise explicitly requires them and the containment model accounts for them.
Network denial and credential isolation should backstop each other. Either control can fail. The boundary is stronger when one mistake does not immediately unlock a real target.
3. Authorize side effects separately
Observation and mutation should not inherit the same authority.
An agent may need to enumerate a service, inspect a configuration, or propose a change without being allowed to alter the target. Consequential actions should pass through a separate policy gate that checks the target, action class, execution identity, and approval requirement.
The gate should exist outside the model's own reasoning. Asking the agent to decide whether its action is consequential can be a useful signal, but it is not an authorization system.
For high-impact operations, make the approval accountable and reconstructable. The team should be able to answer who or what authorized the action, against which policy, using which evidence.
4. Define reset and recovery before execution
A bounded run needs an ending.
Before it starts, define stop conditions, maximum duration, state-reset behavior, cleanup ownership, evidence retention, and the path for revoking access. Decide what happens when monitoring becomes unavailable or the environment stops matching its expected shape.
Recovery is not an admission that isolation will fail. It is recognition that controls should be layered. Anthropic's recommendations include defense in depth, stronger evaluation-environment controls, monitoring, vendor assurance, and hardening.[^anthropic] A run that cannot be cleanly stopped, inspected, and reset is missing part of its boundary.
Test the boundary from inside the harness
A pre-run review should ask about effective reachability, not only configuration intent.
Use the same runtime identity, tool adapters, network environment, and relevant environment variables the agent will receive. Then verify:
- Capabilities: Are only required tools exposed? Can a read-only task reach any way to change state?
- Network: Does deny-by-default egress hold from inside the running harness? Are production control planes unreachable?
- Identity: Are credentials short-lived, scoped, and invalid against real systems outside the approved target set?
- Data: Is the run using synthetic or approved test data? Can mounted files, logs, caches, or retrieval systems expose sensitive material?
- Side effects: Which actions require a policy check or accountable approval? Can tool chaining bypass that gate?
- Observability: Can operators attribute network calls, tool calls, approvals, and state changes to this run?
- Stop behavior: What automatically halts execution when time, cost, scope, or monitoring limits are crossed?
- Recovery: Can the team revoke access, preserve evidence, clean up side effects, and restore a known state?
Run negative tests. Attempt an unapproved destination, an out-of-scope credential use, and a blocked mutation through the same interfaces available to the agent. The expected result is not “the agent chooses not to.” The expected result is denial with usable evidence.
This is also where configuration drift becomes visible. A boundary may have been valid when the harness was created and false after a tool, route, identity policy, vendor integration, or deployment template changed. Boundary verification belongs in the release path and in recurring checks, not only in the original architecture review.
Prompt text still matters—but it is not the enforcement layer
The lesson is not “stop writing safety instructions.” A precise prompt can prevent confusion, state the purpose of an evaluation, define expected stop conditions, and help distinguish a simulated artifact from a real target. Ambiguous scope is itself an operational defect.
But prompt quality should not be used to compensate for ambient capability.
If a system must not reach the public internet, close the route. If it must not modify production, remove the production identity and gate the mutation. If the run must stop after a threshold, enforce the threshold outside the model. If cleanup matters, automate and verify it.
The prompt should agree with those controls. It should not be asked to impersonate them.
That framing avoids a false binary. Instructions and infrastructure are both part of a safe agent system, but they occupy different layers. The prompt is the declared contract. Infrastructure is the constraint. Telemetry is the receipt. Recovery is the backstop.
A sandbox is a claim you should be able to prove
Before calling an agent environment bounded, require four receipts:
- Reachability receipt: evidence from inside the harness that only approved capabilities and destinations are available.
- Isolation receipt: evidence that data and credentials cannot unlock systems outside the intended boundary.
- Authorization receipt: evidence that consequential side effects pass through an external, accountable gate.
- Recovery receipt: evidence that the run can be stopped, access revoked, state reset, and incident details reconstructed.
None of those receipts requires publishing sensitive architecture or attack details. They require the operator to know whether the control exists and whether it worked under the identity and path the agent actually used.
“Sandbox” should not be a label attached to an environment because everyone intends it to be safe. It should be the conclusion supported by tested constraints.
The practical standard is simple: if the prompt and the infrastructure disagree, the infrastructure defines the boundary. Build and test accordingly.
[^anthropic]: Anthropic, “Investigating and addressing cybersecurity incidents in our internal evaluations”, July 30, 2026. Incident counts, affected-run and organization counts, prompt/environment mismatch, incident framing, and remediation statements in this article are attributed to Anthropic's report.