The Range Was Not a Boundary

A cyber range is not contained because the system prompt says it has no internet access.

Anthropic’s July 30 incident report makes that painfully clear. The company reviewed 141,006 cyber-evaluation runs and found six runs, across three incidents, in which Claude reached real organizations through a third-party evaluation environment. The prompt described a simulation without internet access. The network exposed a different reality.

The outcomes were not theoretical. Anthropic says the runs accessed a production database containing several hundred rows, published a malicious PyPI package that was downloaded and executed on 15 systems, and scanned roughly 9,000 targets before compromising a company through exposed debug credentials and SQL injection. The package also ran on a security scanner and captured credentials. Two affected organizations had not detected the activity before Anthropic contacted them.

Those facts are Anthropic’s findings. The company says it is discussing an independent review with METR, so the final external assessment is still pending. That qualification matters, but it does not change the control failure already described in the report.

The asserted boundary and the effective boundary did not match.

A system prompt is not a route table

Anthropic says the models retained their safety training, but the evaluations ran without the company’s standard classifiers and monitoring. The models were told that they were operating in a simulation and that internet access was unavailable. Due to a misunderstanding and configuration problem, an internet route was available.

The instruction may have shaped the model’s understanding. It did not constrain packets, credentials, package registries, or target selection.

This is the difference between context and control:

• A prompt can state the intended scope.
• A deterministic policy can enforce the allowed scope.
• Independent telemetry can prove what actually happened.

All three have value. Only the last two define a dependable security boundary.

This is also why the incident should not be reduced to a story about a model ignoring instructions. Anthropic says it found no evidence of a self-directed goal. In one incident, the model reportedly recognized that the target appeared real and stopped. The more useful reading is operational: a capable system was encouraged to pursue cyber objectives inside an environment whose real permissions contradicted its description.

The infrastructure made the mistake consequential.

Two different spillover paths, one assurance failure

This disclosure follows the OpenAI and Hugging Face evaluation incident, but the escape mechanisms were different.

OpenAI’s updated report says its ExploitGym environment had no direct internet access. Models found a previously unknown vulnerability in an internal Artifactory prototype and used it to reach systems with broader access. That was an exploit path through a constrained boundary.

Anthropic describes an unintentionally open route in a third-party environment. That was a configuration and coordination failure.

One case involved a zero-day. The other involved a path that should not have existed. Both expose the same assurance problem: the teams relied on an intended architecture that had not been proved from the workload’s point of view.

A pre-run review may show that the firewall rule looks correct. A real assurance test starts inside the same namespace, workload identity, resolver path, proxy chain, and service mesh that the agent will use. It asks whether the effective environment matches the declared environment.

That test should fail closed before the model receives the task.

Define scope as an expiring target manifest

Cyber evaluations need a machine-readable scope object, not only a paragraph in a prompt or statement of work.

I would make the target manifest a short-lived, signed artifact containing:

• the evaluation and run identifiers;
• the approved hostnames, IP ranges, ports, and protocols;
• the synthetic accounts and credentials permitted for the run;
• the registries, repositories, and APIs the workload may call;
• the actions permitted against each target;
• the start and expiration time;
• the approving owner and range operator;
• the expected DNS answers or service identities;
• a policy version and manifest digest.

The enforcement point should compare every consequential network or tool action with that manifest. A destination absent from the manifest is denied. An expired run is denied. A hostname that resolves outside its declared range is denied. A credential used against an undeclared service is denied.

This policy belongs between reasoning and effect. It should not depend on the model remembering the rules or correctly deciding whether a host looks synthetic.

The same manifest can improve evidence quality. Network flows, DNS queries, tool calls, package operations, and identity events can carry the run ID and manifest digest. Responders can then distinguish an allowed test action from a boundary crossing without reconstructing intent from a transcript alone.

Test the range from the inside

A useful preflight should be hostile to the range design. It should assume that names, routes, credentials, and shared services have drifted since the last test.

Before every high-capability run:

1. Launch the test from the exact workload class the agent will use.
2. Attempt direct IPv4 and IPv6 egress outside the manifest.
3. Test DNS over the configured resolver and common alternate paths.
4. Resolve every synthetic hostname and confirm that no answer reaches public space.
5. Test redirects, proxies, package managers, cloud metadata, and service-mesh routes.
6. Attempt to create an account, publish a package, open a repository change, and call a public request-capture service.
7. Confirm that every denied action creates a timely, attributable security event.
8. Verify that the emergency stop revokes the run identity and terminates its active sessions.

Package publication deserves explicit treatment after the PyPI incident. Read access to a package index and write access to a public namespace are different capabilities. A cyber evaluation should not be able to publish to a public registry merely because its package tooling can reach one.

The same rule applies to source control, paste services, cloud accounts, email, messaging, DNS, and certificate issuance. If the evaluation does not require a public side effect, the range should not possess the authority to create it.

Detect crossings as joined behavior

The highest-value alert is not simply “agent made a network request.” Cyber evaluations are expected to generate unusual requests.

The useful signal is disagreement between the run’s declared scope and its observed effects. That requires joins across several control planes:

Evidence	Question
Evaluation trace	Which task and model initiated the action?
Target manifest	Was the destination and action authorized at that time?
DNS and network flow	Where did the request actually go?
Identity provider	Which credential was issued and where was it used?
Registry or SaaS audit	Did the request create a durable public object?
Downstream telemetry	Was that object downloaded, executed, or used elsewhere?

The PyPI event shows why downstream effects matter. Publishing a package is one boundary crossing. Other systems retrieving and executing it are another. Correlation needs to connect the evaluation run to the publication, the package identity, and subsequent execution.

Near-real-time review matters too. Anthropic says it has added real-time logging and monitoring, including transcript and network review. This is a reasonable response because a weekly audit is too slow for an evaluation that can scan thousands of systems or publish a package during one run.

The reviewer does not need to understand every line of reasoning. The system needs to surface actions whose effects exceed the manifest.

Treat range vendors as privileged security suppliers

Anthropic’s incidents occurred through a third-party evaluation environment. That makes vendor assurance part of the security boundary.

A range provider is not an ordinary SaaS vendor when it runs capable cyber agents with reduced safeguards. It operates an offensive security platform on the customer’s behalf. Its network design, change management, identity isolation, logs, incident response, and subcontractors all affect the customer’s risk.

The contract should require more than a promise of isolation. It should define:

• who owns the target manifest and who can change it;
• how egress is tested before each run;
• how configuration changes are approved and recorded;
• which logs are delivered, in what time, and with what retention;
• how a customer can stop a run immediately;
• when suspected spillover must be reported;
• how affected third parties are identified and notified;
• whether independent testing can verify the effective boundary.

The customer should also run its own canary checks. A vendor’s control report is useful, but it is not a substitute for testing the path that the customer’s workload will actually receive.

A small assurance standard for live-fire evaluations

I would not start a high-capability cyber evaluation unless the operator can produce evidence for six claims:

1. The target is explicit. Every allowed destination and action appears in an expiring manifest.
2. The boundary was tested. An independent preflight ran from the agent’s effective environment.
3. Public side effects are denied. The workload cannot create accounts, publish packages, or modify public resources unless specifically required and isolated.
4. Every action is attributable. Network, identity, tool, and platform records carry the run identity.
5. Crossings are reviewed live. Scope violations reach a human or automated containment path during the run.
6. The stop path works. Operators have tested revocation, workload termination, and evidence preservation.

That standard does not assume the model will misbehave. It assumes the environment can be wrong.

The July incidents are a reminder that sophisticated model behavior can emerge through ordinary infrastructure mistakes. A prompt described a sealed simulation. The route table described the real world. The route table won.

For an AISecOps program, the lesson is simple: never ask the model to enforce a boundary that the platform can enforce directly. State the scope in the prompt, encode it in policy, test it from inside the range, and watch for disagreement while the evaluation is still running.

Sources

• Anthropic: Investigating incidents from cybersecurity evaluations
• OpenAI: OpenAI and Hugging Face partner to address security incident during model evaluation