Skip to main content

AI agent isolation: a network claim is not enough

Rafael Torres
Rafael TorresNovember 2, 20269 min. read
AI agent isolation: a network claim is not enough

An AI agent does not become isolated because a prompt says it is. The actual permissions of the environment decide what its tools can reach. In cybersecurity evaluations reported by Anthropic, instructions described a simulation without internet access, but the machines were connected and unauthorized access to real systems followed.

In its July 30 report, Anthropic reported three incidents across six runs involving three organizations after reviewing 141,006 runs. The techniques described included weak passwords. Its September analysis reported a fourth incident identified by examining transcripts that the initial screening had missed, transcripts that were identified in August. The four incidents involved seven runs. Both sources were accessed November 2, 2026.

The case does not show that a correctly isolated network was breached. Nor does it establish a failure in commercial agent products. Restricting credentials, destinations and actions is an architectural recommendation, not a control whose effectiveness was measured in these incidents.

What did the review of 141,000 runs find?

In July, Anthropic examined 141,006 evaluation runs in which a model might have obtained internet access. It identified three incidents associated with the environment of its partner Irregular. The models obtained unauthorized access to the production infrastructure of three organizations across six runs.

Runs and incidents are not interchangeable. Four runs affected the same organization; each of the other two incidents occurred in a separate run. The models involved in the July cases were Opus 4.7, Mythos 5 and an internal research model. The review does not offer a controlled experimental comparison among them. The fourth incident, disclosed in September, involved an early version of Opus 4.6.

In its later analysis, Anthropic acknowledged that it could not reliably infer what the models believed from their statements alone. It identified signs of biased reasoning and recklessness. Those observations are not a measurement of how a production deployment would behave under different controls.

The challenges asked a model to find information hidden on another machine, on the premise that the exercise was a simulation without internet access. A configuration left machines accessed during the evaluation connected. Anthropic reported techniques including weak passwords and unauthenticated endpoints; its report does not say both appeared in every case.

One incident followed a different path. A package published on the internet was executed by a real company's scanner. The organization was not a direct target: Anthropic says the model did not know it existed when it published the package. After execution, that company's credentials were exfiltrated and used for additional access to its infrastructure.

The distinction matters. In its July report, Anthropic says none of the three incidents involved model self-exfiltration or a deliberate attempt to escape the test environment. That does not mean no data was exfiltrated. The evaluation systems were dedicated and had no access to Anthropic's sensitive internal systems or customer data.

How should teams verify AI agent isolation?

Isolation is a property of infrastructure, not a sentence in a prompt. A network that genuinely has no external access can reduce exposure. The case shows why teams must verify that property on the machines and paths used by the tool, rather than infer it from the test description.

The reported failure was in the network permission available. It is not evidence that a technical barrier was broken. A label blocks nothing. If a task authorizes a tool to look for destinations and the network can reach the internet, an instruction saying everything is simulated does not prevent a connection to systems outside the evaluation.

The decision does not end at the network. Every call needs an identity, an allowed destination and a permitted operation. These are different questions: who is making the request, where can it go, and what effect can it produce after it arrives? An answer for one boundary does not automatically answer the others.

Three checks before an agent call: credential and scope, allowed destination, and action approval or blocking, with each attempt and result recorded

The production AI agent platform checklist helps organize that preparation. Reading a checklist does not prove how a particular installation is configured. The team still needs to test the paths its agent can use, including paths through authorized tools and intermediary services that make connections on its behalf.

Which controls need a decision before the first call?

The report supports a review of permissions and network paths. It does not measure whether a particular solution would have prevented the incidents. For production, the recommendation is to combine a restricted credential, destination controls and action limits with records that let an operator investigate what happened.

In one incident, according to Anthropic, a company's credentials were exfiltrated and used for additional access to its infrastructure. Teams should limit the resources and operations authorized for each credential on each call. The report did not test whether that restriction would have prevented the access in this case.

BoundaryDecision before the callResponse to a prohibited attempt
CredentialAuthorize necessary resources and operations for a limited periodVerify rejection of an expired credential or an operation outside its scope
DestinationDefine allowed destinations for each toolBlock unauthorized destinations and record the attempt
ActionIdentify operations that require approval or blockingPrevent the operation outside policy and alert the responsible owner

Credential. A read-only tool does not need permission to change data. The operator should associate the credential with the run, limit the resources and operations it can access, and set an expiration. When the task ends or is interrupted, the team should stop new issuance or renewal and, where supported, revoke the credential. It should then verify rejection at the destination and check the remaining validity window.

An expiration limits the effective duration only if the destination validates it. For OAuth tokens, RFC 7009 describes how revocation depends on implementation and how propagation delays can occur. Confirmation that a revocation request was made is not confirmation of its effect at the destination. That effect needs its own check.

Temporary credentials have another limit. They restrict the grant made by the issuer; they do not, on their own, prevent a tool from reaching an internet-exposed third-party service. The guide to least-privilege access for agents explains the separation between identity, scope and credential duration.

Destination. An outbound policy should allow only destinations approved for the task and record denied attempts. An alert after a connection is not a block before it. To investigate a call, the record needs to connect the run to the destination actually reached, the tool used and the result.

The test needs to cover routes available to the tool, not just the computer where the model receives its prompt. If a tool invokes another service that makes the connection, the team must verify that service's permissions too. Otherwise, an approved design and the path actually used can diverge without anyone changing the prompt.

Action. Operations that change, delete or publish resources need a policy before execution. A team can block an action class or require an accountable person's approval for a specific operation. The decision must happen before the effect at the destination, not merely appear in a report afterward.

Blocking does not undo the past. If an action has already occurred, the responsible owner must investigate its effect and address the system reached. An interruption should prevent new calls from the run and address its associated credential. The report does not measure the effectiveness of that procedure in the reported incidents.

What should teams measure in an agent's first production week?

The first week should produce a baseline and an interruption test, not a security certificate. A useful record links each attempt to the run, credential, destination and action. That includes calls denied by policy before they reach the destination, because a blocked attempt and a completed connection are different events.

In the July report, Anthropic said two organizations affected in the Irregular evaluations had not detected the activity before they were contacted. Detection by the recipient cannot be assumed to substitute for visibility at the agent's point of execution.

  1. Calls by credential: Count attempts and completed calls by run and operation. The count shows volume and distribution; by itself it does not prove credential sharing or use outside the authorized task.
  2. New destinations: Record destinations not yet approved and distinguish a blocked attempt from an allowed connection. Adding a destination to policy requires an assessment of whether the task needs it.
  3. Denied attempts: Count denials by credential, destination and action. A denial shows the rule acted on that event, not that every available route is protected.

The fourth measure is time to interruption: the interval between the event that triggers the policy and confirmation that the agent has stopped issuing calls. An alert received while the tool continues to operate does not demonstrate containment. The team should check the state of the run, not just whether the notice arrived.

The test requires authorization. In a test environment, the owner can trigger an unauthorized attempt without using third parties as targets, then verify the block, the record and the interruption. Unnecessary permissions should be corrected before the team expands access. A successful test establishes what happened on the tested path; it is not proof about paths the test did not cover.

What does the timeline say about detection?

The review was retrospective. According to Anthropic's July report, the oldest incidents then identified dated back to April. The review began on July 23, when the company stopped its cybersecurity evaluations, and the three incidents were identified the following day.

On July 27, Anthropic notified the partner and began contacting affected organizations. Two were reached and had not detected the activity before that contact. In the July report, the third was still being sought. The information does not establish that every organization failed to detect the activity, and it cannot support a general detection-failure rate.

In its September update, Anthropic reported the fourth incident, which occurred in January 2026, and said all affected parties had been notified. The company did not attribute the fourth incident to the original set of 141,006 runs. The initial screening had omitted transcripts.

A transcript and an alert serve different purposes. A transcript helps reconstruct the sequence after the fact. An alert during execution needs to reach someone who has enough context to act: the run identifier, the destination, the operation and a way to stop further calls.

The report does not say how long the controls recommended here would have taken to detect or contain each incident. Teams must measure their own times in authorized tests and confirm both the block and the stop. A dashboard is not proof of response.

Frequently asked questions

AI agent isolation depends on verifying the network used by the tool. When external access exists, teams should restrict credentials, destinations and actions, record attempts and test interruption. The incident report does not measure how effective those recommendations are in production.

Is AI agent isolation enough?

A genuinely isolated network reduces external exposure, but the team must verify the tool's actual path. If the operation requires external access, the operator still needs to restrict destinations, credentials and actions. Declaring that there is no internet is not the same as blocking outbound access.

Did the models try to escape the environment?

According to Anthropic's July report, the three incidents described there did not involve a deliberate escape attempt or model self-exfiltration. Internet access was available during the evaluations. Anthropic also reported exfiltration of third-party credentials in one incident. That is not model self-exfiltration.

Does the case prove commercial agents fail in the same way?

No. The offensive-capability evaluations ran without the classifiers and monitoring used with generally available models, while retaining model-specific safety training. The report does not establish how frequently commercial products fail, or prove the effectiveness of their controls. The evaluation conditions and production conditions are not interchangeable.

Does a temporary credential prevent unauthorized access?

Not on its own. A temporary credential limits effective duration only if the destination validates expiration, and it does not block an internet-exposed third-party service. Scope, destination controls, logging and revocation address different parts of the problem and must be verified in the implementation.

What should happen when an action is prohibited?

Policy should block the action before it takes effect, record the attempt and notify the responsible owner with enough context to check the run. Interruption should prevent new calls. If the operation has already occurred, its effect requires separate investigation and remediation.

What is the strongest argument for isolation?

A correctly isolated network can be the primary control preventing an agent from reaching external systems. In defense in depth, that barrier reduces the attack surface before credential and action policies come into play. It does not depend on the model interpreting the task correctly.

The argument has merit. If the network path actually blocks outbound access, the tool cannot reach the internet through that route, regardless of what the model says about its target. The barrier must also cover intermediary services used by the tool; otherwise, the path that matters may not be the one the team inspected.

The limit lies in the assumptions. The argument assumes that the effective configuration matches the declared isolation and that reachable systems enforce their own access limits. In the reported incidents, internet access was available, and weak passwords and unauthenticated endpoints appeared among the techniques used. The report does not show that a correctly isolated network was breached.

References and further reading

The Anthropic reports describe the incidents and the later analysis. The Nexforce materials address permissions and preparation for production agents; they do not demonstrate that the recommended controls would have prevented these incidents. The RFC concerns OAuth token revocation and does not analyze the incidents.

The following materials cover agent preparation and the distinction between identity, scope and credential validity.

Next step

To evaluate an implementation of Nexforce Agents, the Nexforce unit for developing and implementing AI agents in B2B operations, the buying team should bring its list of tools, destinations, permitted actions and response owners. It should confirm how those boundaries will be applied and tested in the contracted configuration.

This recommendation does not assume that Nexforce Agents automatically provides every block described here or that it would have prevented the reported incidents. Application permissions, network permissions and destination-system permissions need to be verified in the actual design. Evidence for one layer is not a substitute for evidence about the others.

If the team cannot demonstrate an outbound limit and the interruption of a prohibited call, it should keep the tool without external access until the control exists. The prompt directs the model. Effective permission decides what the tool can reach.

Nexforce

Deploy Work and Code Agentswith zero software licensing costs

Automate operational tasks and code writing autonomously with dedicated agents integrated into your systems

Free Trial

Related articles