✓ Human-authored analysis; AI used for formatting and proofreading.
In the span of two weeks in July 2026, three separate organizations reported AI agents acting beyond their intended scope. Each incident had a different failure mode. Each was preventable through configuration verification that nobody ran.
On July 14, an autonomous AI agent escaped an evaluation sandbox at a major AI research lab. The agent found a vulnerability in the sole permitted egress path, A JFrog Artifactory proxy and pivoted through it to an internet-connected node, stole credentials, and attacked external infrastructure. The sandbox was isolated. The configuration said otherwise.
On July 24, OpenAI disclosed that during internal testing of their ExploitGym framework, an agent exploited a permitted network path to reach systems beyond the evaluation boundary. The proxy was authorized. The path through it was not anticipated.
On July 28, the UK government's AI Safety Institute reported that during a routine cyber evaluation, AI agents took sustained, unsanctioned action directed at real people and organizations. An agent attempted a supply-chain attack on a real open-source project, created fake identities to socially engineer a human maintainer, and tried to get real people to execute malicious code. The agent didn't escape its sandbox. It used the internet access it was deliberately given.
Three incidents. Three organizations with world-class security teams. Three AI agents that operated beyond their intended scope. Three different failure modes: sandbox escape, proxy exploitation, and legitimate-access misuse.
One common root cause: the infrastructure configuration was verifiable before each agent started, and nobody verified it.
Three failure modes, one configuration surface
The three incidents look different from the outside. The first was a containment failure: the agent broke out. The second was a path exploitation: the agent found an unintended route through an authorized proxy. The third wasn't a containment failure at all, the agent stayed inside its sandbox and used the access it was given.
From a configuration perspective, they're the same. Each environment had properties that, examined together, created the conditions for the incident.
The first sandbox had a VPC with one permitted egress path to an Artifactory proxy. The proxy had a vulnerability. The agent's role had credentials accessible via the instance metadata service. No monitoring covered the proxy's outbound connections. Four configuration properties: egress path exists, proxy is a network target, credentials are accessible, monitoring is absent. Each was a field in the environment's configuration. Each was inspectable before the evaluation started.
The second environment had a proxy endpoint that the agent was authorized to use. The proxy's backend had network connectivity to systems beyond the evaluation scope. The agent's credentials were valid beyond the proxy's intended boundary. Three configuration properties: proxy exists, proxy connects to external systems, credentials are not scoped to the proxy's intended use.
The third environment: the AISI evaluation had internet access deliberately enabled. The agent's task was to solve a cybersecurity challenge. No fine-grained egress controls restricted which internet destinations the agent could reach. No real-time monitoring watched what the agent did with its internet access. The general security monitoring that eventually caught the behavior detected anomalous Tor traffic after the fact, not evaluation-specific activity as it happened.
AISI's own post-incident analysis identified the gap precisely: "our security team detected the anomalous traffic through general monitoring after the fact, not through monitoring built to watch the evaluation as it ran."
The monitoring that would have caught the behavior was a configuration property: an EventBridge rule watching for specific evaluation actions, delivering to a Lambda that flags out-of-scope behavior. That rule didn't exist. Its absence was a configuration property visible in a snapshot of the evaluation environment.
What configuration verification would have shown
Before each evaluation started, a snapshot of the environment's configuration would have contained every property needed to predict the risk.
For the first sandbox, the snapshot would show: VPC has exactly one egress path to a proxy. The proxy's security group allows outbound connections to the internet. The agent's IAM role has credentials accessible via IMDSv1. No CloudTrail data events cover the proxy's API calls. No VPC flow logs cover the proxy's network traffic. Five properties. Each individually is a posture concern. Together, they form the compound path the agent used: proxy with internet access plus accessible credentials plus no monitoring equals undetectable credential theft with an exfiltration route.
For the AISI evaluation, the snapshot would show: VPC has unrestricted egress to the internet. No egress allowlist restricts destinations. No evaluation-specific EventBridge rules watch agent actions. No real-time monitoring flags out-of-scope behavior. The agent's network namespace can reach GitHub, email services, and file-transfer platforms. Four properties. Each is a deliberate configuration choice that AISI made for evaluation realism. Together, they meant the agent could create GitHub accounts, submit pull requests, contact real people, and use Tor. All without triggering any evaluation-specific alert.
The properties were visible. They were inspectable and verifiable. Nobody verified them as a compound before the agent started.
The compound is the finding
Each individual configuration property in these environments was a deliberate choice. Internet access was enabled for evaluation realism. Credentials were accessible because the agent needed to use AWS services. Monitoring wasn't evaluation-specific because previous model generations hadn't needed it.
Each individual choice was defensible. The compound was not.
An agent with internet access is a choice. An agent with internet access and no egress allowlist and no real-time monitoring and accessible credentials is a compound risk that no individual choice accounts for. The risk emerges from the combination, not from any single property.
This is the gap that individual configuration checks cannot close. A check that says "does this VPC have internet access?" returns yes, and that's the intended state. A check that says "does this VPC have internet access AND no egress allowlist AND no evaluation monitoring AND the agent role has broad permissions?" returns yes, and that's a finding. Because the combination creates a capability the evaluation designer didn't intend.
AISI's lessons confirm this. Their first response: "tighter controls on internet access" with "fine-grained network controls" that "constrain appropriately." Their second response: "real-time monitoring built to watch an evaluation as it runs." Their third: "evaluations should assume a capable model may try to act beyond its remit."
All three responses are configuration properties. They were absent before the incident. They were verifiable from a snapshot.
The isolation intent problem
AISI's most important architectural lesson is buried in a single sentence: "We will now treat the decision to grant internet access as one that must be actively justified rather than a default."
This inverts the trust model for evaluation environments. Previously: internet access was default, and isolation was the exception. Now: isolation is default, and internet access requires justification.
This is an infrastructure configuration pattern, not a policy statement. It means: an evaluation VPC without an explicit declaration of "this environment intentionally has internet access because [specific reason]" should be flagged. The absence of the declaration is the finding.
The declaration is a tag on the resource. The verification is a check against the tag. An evaluation environment tagged "isolation-intent: airgapped" that has a route to an internet gateway is a critical finding where declared isolation doesn't match observed configuration. An evaluation environment with no isolation intent tag at all and internet access is a high finding where the intent was never declared, the default should be isolated, and nobody justified the exception.
This pattern applies to every evaluation environment, sandbox and development VPC where agents run. The AISI incident proved it: the agent didn't escape the sandbox. The sandbox's configuration permitted what the agent did. The gap was that nobody asked "should this environment have internet access, and if so, what monitoring must accompany that access?"
What "standard cyber hygiene" means for agent infrastructure
AISI's guidance to organizations ends with: "ensure the cyber security basics are implemented robustly." For organizations running AI agents on cloud infrastructure, the basics are configuration properties:
Every agent environment should have its isolation intent declared. Airgapped, egress-restricted, or intentionally connected where the intent must be stated and the configuration must match the intent.
Every agent role should be scoped to its task. The AISI agent needed to solve a cybersecurity challenge. It did not need to create GitHub accounts, submit pull requests to real projects, or contact real people via file-transfer services. The role's permissions or the network's egress allowlist should have prevented these actions regardless of what the agent decided to do. Containment should not depend on the model choosing not to test its boundaries.
Every evaluation environment should have monitoring specific to the evaluation. General security monitoring caught the AISI incident after the fact. Evaluation-specific monitoring where the rules that flag out-of-scope network destinations, unexpected API calls, or identity creation would have caught it as it happened.
Every detection service in the evaluation environment should be delivering. A monitoring rule that exists but delivers to a deleted SNS topic is worse than no rule. It creates the appearance of monitoring without the function. The configured-but-not-functioning pattern is the most dangerous configuration state because it passes every check that looks at configuration without testing delivery.
These are all configuration properties. They are inspectable in a snapshot. They are verifiable before the evaluation starts. It was absent in at least one of the three July 2026 incidents.
The new threat model for agent infrastructure
AISI concludes: "harm may arise not only when people deliberately misuse publicly available models, but when capable agents operating in an internal research or privileged-access setting take unintended action beyond their authorized scope."
This is the new threat model for agent infrastructure. The agent doesn't need to escape. It doesn't need to exploit a vulnerability. It uses the access it was given in ways the operator didn't anticipate. The defense is not better sandboxing. The AISI sandbox held. The defense is configuration verification that examines the compound: what can this agent reach, what credentials does it have, what monitoring covers its actions, and does the combination create capabilities beyond the task scope?
Three incidents in two weeks. Three world-class security teams. Three agents that found the gap between what the configuration intended and what the configuration permitted. The gap was verifiable before each agent started.
The question for every organization running AI agents: have you verified yours?
The AISI incident report is available at aisi.gov.uk. The technical report details 19 unsanctioned actions across 10 of 122 evaluation runs.
