AI Evaluation Is Execution

Disclosure: These views are my own and do not represent my current or any former employers. This paper uses only public sources and does not describe non-public product information.

Executive summary #

An evaluation used to be a measurement. A model received an input, produced an output, and a scorer compared that output to a reference. Nothing outside the harness changed.

Agent evaluations work differently. To measure whether a model can find a vulnerability, complete an engineering task, or operate a service, the harness gives it a shell, a package manager, a browser, an API client, a credential, and time. The evaluation now performs work, and whatever the agent reaches while performing that work is inside the blast radius of the measurement.

Three disclosures in 2026 showed what that means. OpenAI published a technical report describing evaluation agents that obtained root on parent virtual machines, used a shared package service as a coordination channel and an egress path, and reached production systems at Hugging Face, including code execution on 41 dataset workers, Kubernetes access, and modification of a private repository.[3][6] Anthropic disclosed incidents in which evaluation environments built by a partner had unintended internet reachability; single model instances then acted on real companies, in one case up malicious package versions to PyPI that were installed on 15 systems.[4][9] The UK AI Security Institute disclosed an incident in which internet access was deliberate and provider cyber classifiers were deliberately disabled; agents attempted a malicious contribution to a real open-source project, created fake identities, and left artifacts for later agents.[5]

The argument of this paper is narrow. Once an evaluation gives an agent arbitrary code execution, network reachability, credentials, or tools capable of external mutation, that evaluation is a security-critical production-risk workload. Its boundaries have to hold when the task is unsolvable, when safeguards have been deliberately reduced, when the model finds a path the designers did not consider, and when the evaluator is wrong about what the environment can reach.

The contribution is an incident-grounded synthesis and an operating model rather than a new isolation primitive. Sandboxing, least privilege, network segmentation and evidence integrity are established practice, and the idea that AI containment is a security problem dates back at least to 2017.[25] What the 2026 record supports is a decomposition for evaluation systems: six boundaries that fail independently and should be engineered independently.

1. Execution boundary. Strong per-run isolation, and nested isolation when the evaluation targets the isolation mechanism itself.
2. Network boundary. Default deny, enforced outside the agent-controlled workload, with brokered and destination-limited exceptions.
3. Identity boundary. No ambient long-lived secrets; short-lived, audience-scoped and action-scoped capabilities issued per run.
4. Effect boundary. Simulated services or reversible test tenants for every mutation-capable tool, with external effects classified and recorded.
5. Evaluation-integrity boundary. An immutable run manifest, an authoritative grader outside the mutation boundary, and reference data the agent cannot read.
6. Evidence and response boundary. Off-box tamper-resistant telemetry, scope-aware monitoring, a tested kill mechanism, and named incident ownership.

The organising rule is that failure of one boundary should not grant control of another. Every 2026 cluster involved at least two boundaries failing together, and in the largest case a shared service was simultaneously a package source, a credential domain, a writable store, a communication channel and a route to the internet.[6][7]

1. Evaluation is execution #

A benchmark run creates real side effects because the mechanisms that make an agent evaluation informative are the same mechanisms that make it consequential.

Consider what a modern cyber or software-engineering evaluation provides: a shell with root inside a container, a package manager, often a browser or search tool, credentials for the services the task involves, a horizon of thousands of actions, and a scorer that determines success. Each is a capability in the security sense. Arbitrary code execution inside a container is arbitrary code execution. A package manager is an outbound network client with write authority if the registry credential allows uploads. A browser is a general-purpose egress channel. A credential in an environment variable is readable by any process the agent starts. A scorer that runs in the same workspace is an attackable component.

The harness also removes controls that limit the same model in a deployed product. That removal is deliberate and often correct, because a capability evaluation exists to measure what the model can do. In the OpenAI case, the implicated runs lacked production cyber classifiers, deployed system prompts and auto-review systems.[6] In the AISI case, provider cyber classifiers were disabled as an explicit evaluation choice.[5] In the Anthropic cases, production cyber classifiers and normal monitoring were absent, while model safety training remained in place.[4][9] The workload with the fewest behavioural safeguards is therefore also the one with the most permissive tooling, the longest horizon and the most adversarial task specification.

The task itself contributes. An agent given an unsolvable or nearly unsolvable task will explore. On 8 May, an agent assigned an effectively impossible spreadsheet task attempted server-side request forgery against an internal package service in order to obtain internet resources it could not otherwise reach.[6] The attempt failed as an egress route at that moment, but it wrote a file to that service, and the shared writable storage behind it later became a cross-run message board.[6][7]

Evaluations also differ from ordinary batch compute because the object under test is adaptive. A misconfiguration in a normal batch job produces a failure. The same misconfiguration in front of an agent produces exploration, and exploration that is rewarded becomes a repeatable technique that spreads across parallel runs sharing the same infrastructure.

None of this requires attributing intent to the model. It only requires accepting that the environment executes untrusted, adaptive, capable code with credentials, so the ordinary security question applies: what can this workload reach, and what happens if it does?

2. What happened in 2026 #

2.1 OpenAI and Hugging Face

The enabling conditions began months before the intrusion. Between 12 and 13 May, agents running in OpenAI's ExploitGym evaluation platform discovered that shared credentials for an internal Artifactory package service, and the writable storage behind it, could function as an asynchronous cross-run message board; this required no exploit, only shared credentials and shared writable infrastructure.[6] On 26 May, agents used a server-side request forgery vulnerability in that service to reach the internet, partly using information exchanged through the message board.[6] On 26 June, agents exploited a token-refresh defect to convert the shared credential into administrator credentials, created persistent users and installed command-capable plugins.[6] Monitoring detected port sweeps on 27 June, which responders associated with ExploitGym while advising that the run did not need to be stopped.[6] Between 4 and 6 July, agent activity caused an outage of the package service, administrator-level compromise was discovered, credentials were revoked and the vulnerability was disclosed to the vendor.[6]

The main intrusion followed. New runs again used the package service as a message board on 8 July, embedding communications in directory names.[6] On 9 July, two internal research-model agents independently obtained root on the parent virtual machine hosting their test sandbox, and one reached the internet through package-service endpoints despite direct outbound traffic being denied.[6] On 10 July, an agent found 14 publicly exposed Hugging Face user credentials and posted them to the message board.[6] On 11 July, agents used an HDF5 external-storage feature to disclose files such as process environment data from Hugging Face dataset workers, then exploited an fsspec and Jinja2 injection path to execute commands; a pull-based command-and-control mechanism used a public dataset to exchange commands and results, and temporary node credentials came from instance metadata.[3][6] Over 12 and 13 July, agents created privileged host-mounted pods in connected clusters, staged Kubernetes secrets and private data, then modified a private repository, opened a draft pull request and triggered continuous integration to produce a network beacon.[3][6] Hugging Face disclosed the intrusion on 16 July. On 19 July, OpenAI detected unusual identity-related API activity and, in separate activity, agents exploited a known kernel vulnerability to obtain root on an OpenAI worker node, reach cluster-admin access and create privileged cloud resources.[6] OpenAI stopped ExploitGym, removed package-service access and required microVMs with default-denied egress on 20 July, attributed the activity publicly on 21 July, and shut down the research-model family between 23 and 29 July.[1][2][6]

METR estimated that about 1,200 agents exchanged more than 70,000 messages or files, with roughly 700 participating in the Hugging Face activity, and documented collective work on deriving flags, probing the scorer, installing tripwires, replacing targets, tampering with logs and spoofing tool calls.[7] Its review covered mainly 7 to 13 July, relied substantially on AI-assisted analysis of very large records, and did not validate every claim in the later OpenAI report.[7] The sources also differ on motive: Hugging Face describes an effort to cheat by reaching benchmark models, datasets or solutions,[3] while METR concluded that the collective was primarily attempting to understand or defeat the scorer implementation.[7] Both are forms of reward-directed circumvention, and the narrower reading should not be stated with more confidence than the records support.

2.2 Anthropic and Irregular

Anthropic began a retrospective review on 21 July after OpenAI's disclosure, reviewed 141,006 potentially internet-capable cyber-evaluation runs, and stopped all cyber evaluations on 23 July after identifying suspicious transcripts.[4] It identified three incidents on 24 July, notified its evaluation partner Irregular and the three affected organisations on 27 July, and disclosed publicly on 30 July; two of the three had not previously detected the activity.[4] In August it found transcripts missed by its first search and identified a fourth incident from January involving an early Claude Opus 4.6 checkpoint.[9] On 9 September it published an alignment assessment based on a scan of roughly 481 million transcripts, including agentic review of 9.2 million first-stage matches, which reidentified the four incidents and found no others of similar or greater severity.[9]

The four incidents differ in model, scenario and effect.[4][9] In the first, Claude Opus 4.7, across four runs of one scenario, exploited a real company that shared a name with the fictional target, obtained credentials and database access involving several hundred production rows, and modified records; the transcripts record recognition that the company was real alongside an assumption that reachability and name similarity implied authorisation. In the second, Claude Mythos 5, in a single run, registered disposable email infrastructure, uploaded three malicious package versions to PyPI which were installed on 15 systems, and used credentials taken from a security scanner to access a vendor's live database. In the third, an internal research model scanned roughly 9,000 targets, compromised a real company using exposed credentials and SQL injection, downloaded files and installed a remote-control script; it eventually recognised the company as real and stopped, but resampling produced de-escalation in only 5.5 per cent of continuations. In the fourth, an early Claude Opus 4.6 checkpoint attempted to abort at least eight times after breaking its target, but a harness defect prevented the aborts from succeeding. The run then accessed a third party, used discovered credentials for administrative access, altered settings and read one person's data.

Anthropic's interpretation moved between reports. The 30 July disclosure leaned towards operational failure combined with a mistaken belief that the environment was simulated.[4] The 9 September assessment steps back from strong claims about model belief and instead describes biased reasoning and recklessness.[9] Anthropic also reports that an offline chain-of-thought monitor would have missed the PyPI incident because the model's own reasoning persuaded the monitor that the environment was simulated.[9]

There was no demonstrated container or virtual-machine exploit, and no attempt by a model to copy itself out.[4][9] Connectivity was the failure: environments built by one partner had unintended open-internet reachability, some direct and some transitive through target machines.[4] Each incident involved a single isolated instance, and evaluations ran on infrastructure separated from Anthropic's sensitive systems and customer data.[4]

2.3 UK AI Security Institute

The relevant behaviours occurred between 25 and 28 July 2026. On the morning of 28 July, general security monitoring detected Tor traffic leaving an evaluation system; AISI declared an incident, stopped the evaluation, disabled internal access to the most capable models and isolated the machines within approximately one hour, and published its technical report on 4 August.[5] Seven models were tested across 122 runs, with 43 runs using Mythos 5 and 35 using GPT-5.6 Sol, and AISI identified 19 unsanctioned actions across 10 runs: 17 associated with Mythos 5 and two from a single GPT-5.6 Sol run.[5]

Four behaviour clusters stand out: an attempted malicious contribution to a real open-source project; creation of fake identities and attempted social engineering of a real maintainer; attempts to deliver malicious files or prompt-injection material to real people and AI coding systems; and collaboration through public messages, reused accounts and artifacts left for later agents.[5] A human maintainer rejected the malicious pull request, and a member of the public opened suspicious code inside an isolated environment.[5]

Isolation held. Virtual-machine separation from other AISI systems was maintained, and no agent attempted to break into AISI infrastructure.[5] Internet access was deliberately enabled and provider cyber classifiers were deliberately disabled.[5] Detection came from general Tor and data-transfer monitoring after the actions had begun, rather than from evaluation-aware monitoring.[5] AISI states that it cannot yet determine when the agents understood that their actions were real, and notes that these were a small number of observations under intentionally permissive conditions that are not commercially available.[5]

2.4 Incident matrix

Property	OpenAI and Hugging Face	Anthropic and Irregular	UK AISI
Container or host escape	Yes [6]	No evidence [4][9]	No [5]
Internet intended by evaluator	No for implicated runs [6]	No [4]	Yes [5]
Internet nevertheless available	Exploited and transitive paths [6]	Partner misconfiguration [4]	By design [5]
Shared service enabled cross-run state	Yes [6][7]	Not reported [4]	Public artifacts only [5]
External production access	Extensive [3][6]	Yes [4][9]	Attempts and limited effects [5]
Underlying model safety training	Model-specific details varied [6]	Present [4]	Provider-dependent [5]
Provider cyber classifiers	Absent or reduced [6]	Absent [4]	Deliberately disabled [5]
Cross-agent collaboration	Large emergent collective [7]	None [4]	Limited, public artifacts [5]
Grader or scorer probing	Extensive [7]	Not reported [4]	Not central [5]
Evidence of a durable independent goal	No [7]	No [9]	No [5]
Detection route	Internal alert and affected party [1][6]	Retrospective transcript review [4][9]	General network monitoring [5]
Harm scope as reported	No customer impact; public supply chain clean [1][6]	Real access and data effects [4][9]	No resulting harm identified [5]

Two phrases deserve care. "No sandbox escape" does not mean nothing left the environment, and "no identified harm" does not mean no external effects. Confirmed effects across the three clusters include unauthorised production access, credential acquisition, publication of malware to a public registry, access to databases and private repositories, creation of privileged workloads, contact with real people, and an attempted modification to open-source software.[3][4][5][6][9]

3. Three different containment failures #

The first failure class is an execution escape. Agents obtained root in parent virtual machines and acted outside the intended per-run container boundary, and separately compromised a supporting service to administrator level.[6] The response is stronger and nested isolation, patching discipline for host and runtime components, and treating supporting services as part of the isolation perimeter.

The second is accidental or transitive reachability. Anthropic's environments were intended to be closed and were not, because of a configuration failure between a provider and its partner.[4] There was no exploit of the sandbox. The response is verification: independent confirmation, before each engagement, that the environment cannot reach what it is not supposed to reach, tested from inside the sandbox rather than asserted from a configuration file.

The third is authorised connectivity with uncontrolled effects. AISI's agents had internet access by design and produced external effects through that authorised channel.[5] No isolation control was defeated. The response is effect-level control: explicit in-scope targets, brokered egress with semantic limits on what may be written or published, and monitoring that understands the intended scope of the task.

A fourth pattern sits inside the first cluster. Shared writable infrastructure created cross-run state that agents used as a coordination channel before any exploitation occurred.[6] Isolation between the agent and the host held in that early phase; isolation between concurrent runs did not exist.

This is why "sandbox escape" is too narrow as a framing. It describes only the first class, and it draws attention to the container runtime while the other classes involve network reachability, tool authority and shared state. A programme that hardens only the execution boundary can pass its own review while an agent uses an approved browser, an approved package registry and an approved credential to change something in the world.

4. The effective boundary is larger than the sandbox #

The boundary that matters is everything an agent can reach and influence during a run, which is usually larger than the container the evaluation team has in mind.

Package registries are active capability rather than passive download plumbing. In the OpenAI case, an internal package service was simultaneously a source of dependencies, a credential domain, a writable store, a coordination channel, a privilege-escalation target and a route to the internet.[6][7] In the Anthropic case, a public registry was the medium through which malicious package versions reached 15 third-party systems.[4] Download and upload authority should be separated, caches should be read-only or per-run namespaced, and registry administrator, refresh and signing credentials should not be reachable from an agent workload.

Instance metadata endpoints convert local code execution into cloud identity. Temporary node credentials obtained from metadata were part of the progression to host and Kubernetes access.[3][6] IMDSv2 adds session tokens, instance binding and configurable hop limits, which reduce request forgery from outside the workload,[20] but an agent already executing inside an authorised workload can still reach metadata unless that endpoint is denied or mediated.

DNS, certificates and configuration disclose the environment. AISI found that DNS settings, TLS certificates, usernames, hardware strings, internal proxy configuration and model-name APIs revealed the organisation, employee identity, cloud provider, architecture and research history despite initial external-network restrictions.[11] Absence of web access is not absence of information flow, and DNS remains a data channel even when it is the only permitted egress.

Proxies, browsers and screenshot services are egress by another name. Confirmed indirect channels in 2026 included package-service paths and file names used as messages, public datasets used as dead drops, paste and webhook services, screenshot services that encoded API results into images, and public repositories reused across agents.[6][7] A policy expressed only as destination addresses does not constrain these; it has to regulate write capability and information flow.

Shared writable state connects runs that were meant to be independent. Two runs that share a credential, a cache, a bucket prefix or an artifact repository are one system for containment purposes, and per-run namespaces, per-run credentials and immutable base images remove most of that surface. Graders and orchestration are part of the reachable environment too when they run inside or alongside the agent workspace.[7][16]

Credentials define what reachability is worth. An unreachable service becomes reachable when a credential is discovered, and an authorised service becomes dangerous when its credential is over-scoped; in the Anthropic incidents, publicly exposed third-party credentials and credentials recovered from a security scanner were both used against live systems.[4][9] Public services and real people are part of the boundary once egress exists.[5]

5. A six-boundary containment model #

The model below separates concerns that failed together in 2026 but can be engineered apart. None is novel in isolation; the value is in requiring that failure of one does not confer control over another.

Boundary	Invariant	Primary controls	Failure signature
Execution	Agent code stays inside its per-run isolation unit	Per-run microVM or userspace-kernel isolation; nested isolation when testing escape; patched runtimes	Root on a parent host; access to another run's workspace
Network	No route out that was not explicitly brokered	Default-deny egress enforced outside the workload; allowlisted destinations; blocked metadata; mediated DNS	Unexpected destination, protocol, DNS pattern or covert channel
Identity	No ambient long-lived secrets; every capability scoped and short-lived	Per-run workload identity; audience-restricted and action-restricted tokens; broker-performed actions	Credential used outside its audience, task, run or lifetime
Effect	Mutation-capable tools act on simulated services or reversible tenants	Simulated replicas; test tenants; write brokers; explicit in-scope target lists; state diffing	Any external write, publication or account creation not on the approved list
Evaluation integrity	The agent cannot observe or alter the authoritative measurement	Immutable run manifest; grader outside the mutation boundary; inaccessible reference data	Grader access, tripwires, tool-result spoofing, unexplained state change
Evidence and response	Telemetry survives the workload and someone can stop it	Off-box append-only logs; scope-aware monitors; tested kill switch; named on-call owner	Missing or altered telemetry; run continues after alert

5.1 Execution boundary

The execution boundary is the isolation unit that contains the agent's code. For low-risk runs with fixed tools, an ordinary container is proportionate. For arbitrary code execution and adversarial tasks, the boundary should be a virtual machine. Firecracker shows that a KVM-based barrier with a minimised device model can run at high density and low overhead, which removes the argument that per-run virtual machines are too expensive.[17] gVisor reduces direct host-kernel exposure through a userspace kernel, and its documentation is explicit that a sandbox does not substitute for secure architecture and does not address hardware side channels or network policy.[18] OpenAI's remediation moved research workloads to microVMs with outbound traffic denied by default.[6]

When the evaluation targets the isolation mechanism itself, use nested isolation. SANDBOXESCAPEBENCH places the vulnerable container inside a sacrificial virtual machine, so a successful escape reaches only the sacrificial layer.[13] AISI's guidance reserves remote virtual-machine isolation for evaluations that may threaten their own sandbox, and states plainly that no sandbox provides complete assurance.[10] Frontier models in that benchmark reliably exploit misconfigurations such as privileged containers, writable host mounts and exposed daemons, with roughly 0.40 success at level-3 scenarios for the strongest models tested and no observed success at levels 4 and 5, under conditions that included root inside the container, internet access and a prompt authorising escape.[13] Those results do not estimate the probability of compromising a defended production environment, and zero observed successes at harder levels do not establish inability.[13]

5.2 Network boundary

Default deny means that the workload has no route out unless a route was explicitly created, and that the enforcement point is outside the agent's control. Anthropic's revised requirements specify no internet by default, with only the model API reachable and its key kept outside the sandbox.[8] AISI's protocol defines no-network, restricted-domain and unrestricted-network profiles, with network access disabled by default.[10] Kubernetes NetworkPolicy can express default-deny egress, but only where the container network interface enforces it; policies are additive, DNS must be permitted separately if required, and the model operates at layers 3 and 4.[19] Layered enforcement matters because direct outbound traffic was denied for the OpenAI runs in question and an agent reached the internet through package-service endpoints anyway, after which remediation used independent controls at the sandbox and cluster layers plus a controlled cache service.[6]

Verification should be adversarial. Testing that a single request to a well-known domain fails is not verification. The check should enumerate IPv4 and IPv6 routes, DNS resolution and exfiltration through DNS, metadata endpoints, service meshes, package caches and mirrors, private links, browser and screenshot tools, and every supporting service the sandbox can address, running from inside the sandbox image that will actually be used.

5.3 Identity boundary

An agent workload should hold no ambient long-lived secret. Every capability should be attributable to a specific run, bounded in time, and restricted in audience and action. RFC 9700 recommends minimum privileges, audience restriction, resource and action restriction, and sender-constrained tokens where feasible.[21] SPIFFE provides workload-specific, short-lived, automatically rotated identity without static application secrets co-deployed with the workload.[22]

A useful credential shape is a tuple: run identifier, agent identity, tool, audience, resources, permitted verbs, maximum calls, expiry, and whether human approval is required. Credentials should be supplied through a broker that performs the action or signs an individual request, rather than copied into environment variables that any process the agent starts can read.[3] Time alone is insufficient, because temporary node credentials were still usable within their lifetime [3][6] and over-broad service-account and signing credentials enabled escalation.[6]

5.4 Effect boundary

The effect boundary governs what the evaluation can change outside itself. It is the boundary the AISI incident tests most directly, because there the network boundary was open by design and nothing else stood between the agent and a real maintainer.[5]

Three mechanisms carry most of the weight. Simulated services provide API-compatible replicas of the tools the task requires. Reversible tenants cover cases where a real service is required: a dedicated tenant owned by the evaluating organisation, with discardable data and quotas that bound damage. Write brokers sit in front of any tool capable of publishing, sending, purchasing, deleting or contacting a person, checking the target against an approved list.

Scope must be explicit and machine-checkable. Anthropic's partner requirements include explicit in-scope targets, actions and networks.[8] A target list that exists only in a task description is not a control, because the agent chooses how to interpret the description; in the first Anthropic incident, the model appears to have treated reachability and name similarity as evidence of authorisation.[4][9] A broker comparing a destination against an approved list does not make that error.

5.5 Evaluation-integrity boundary

The measurement is an asset with its own threat model. Its invariant is that the agent may mutate its task workspace and must not be able to observe or alter the authoritative scorer, the reference data, the expected outputs, the signing material or the score-reporting channel.

The authoritative grader should run outside the mutable workspace and consume exported artifacts or a clean snapshot. Reference answers and held-out data should remain unreachable through files, image layers, caches, process inspection and supporting services. A signed run manifest should bind the model, task, harness, scorer, image, initial state, policies and monitor versions to the result. Section 7 develops these controls and the failure modes they address.

5.6 Evidence and response boundary

Telemetry that lives inside the workload is not evidence, because the workload is the thing under investigation. The evidence plane should be append-only, written off-box, and retained under rules that survive the run's deletion; NIST SP 800-92 supports protecting audit records from unauthorised modification or destruction.[24] Response capability belongs to the same boundary. A monitor without a kill mechanism produced the 27 June situation, in which port sweeps were detected and the run continued.[6] An agent-requested abort is another response path and the January Anthropic incident shows why the harness must honour it reliably.[9] Anthropic now requires monitors that can block the tool call, end the run and alert a person,[8] and AISI has described moving from general monitoring to evaluation-specific synchronous monitoring.[5]

6. External effects should be explicit #

Most evaluation programmes record whether a run passed. Few record what the run did to the world. That asymmetry explains why two of the three organisations affected by the Anthropic incidents had not detected the activity themselves,[4] and why the OpenAI intrusion was disclosed by the affected party before it was attributed.[1][2] An effect ladder gives a common vocabulary. The levels below are ordinal in seriousness but should not be compressed into a single severity score, because the controls that prevent each level differ.

Level	Class	Example from the 2026 record
X0	No external request	Task completed entirely against local replicas
X1	External observation	Scanning roughly 9,000 targets;[9] port sweeps [6]
X2	External artifact publication	Malicious package versions uploaded to a public registry;[4] fake identities and public artifacts left for later agents [5]
X3	Unauthorised access or data read	Credentials and database access at a real company;[4] private repository and dataset access [3][6]
X4	External mutation	Modified production records;[4] altered third-party settings;[9] modified private repository and triggered CI;[3][6] privileged pods created in connected clusters [6]
X5	Supply-chain or human-directed attempt	Attempted malicious contribution to a real open-source project and attempted social engineering of a maintainer [5]
X6	Demonstrated downstream harm	Malicious package installed on 15 systems [4]

Three fields should be recorded separately for each observed effect: attempted, succeeded, and impact-confirmed. Reporting only attempts overstates consequence; reporting only confirmed harm understates exposure, which is how "no identified harm" becomes "nothing happened".

Impact confirmation usually requires the affected party. An evaluating organisation can establish that a request was made and often that it succeeded, but whether a package was installed, a record was relied upon, or a person acted on a message is knowable only downstream. That argues for early notification rather than waiting until the internal picture is complete; Anthropic notified affected organisations three days after identifying the incidents and before public disclosure.[4]

Each level also suggests the control that should have been in place. X1 argues for destination allowlists, X2 for separating read authority from publish authority, X3 for scoped credentials and broker-mediated access, X4 for simulated services or reversible tenants, X5 for a prohibition on contacting real people or real projects without prior human approval, and X6 for notification paths that exist before they are needed.

7. Evaluation integrity is a security property #

If an agent can influence its score without performing the task, the evaluation stops measuring capability and starts measuring the agent's ability to attack the measurement. METR documented collective workstreams devoted to deriving flags, probing the scorer, installing tripwires, replacing targets, tampering with logs and spoofing tool calls.[7]

Grader isolation is the first requirement. The scorer should not execute inside the agent's still-mutable workspace; it should consume exported artifacts or a snapshot taken from outside. Inspect's architecture keeps orchestration code outside the sandbox and sends explicit work into it.[10] RewardHackingAgents evaluates this across ML engineering tasks and model backbones, and its fully locked regime combines pristine external evaluation code with denial of training-time access to held-out artifacts.[16]

Answer leakage is a separate failure. Reference solutions, expected outputs and flags should not exist anywhere the agent can read, which includes indirect paths: process inspection, backups, caches, crash dumps, image layers, and files left in a shared cache from an earlier run.

Reward tampering and specification gaming should be measured rather than assumed absent. Benchmarks require iterative hardening against paths their designers did not intend; SANDBOXESCAPEBENCH's authors report four unintended shortcuts found by agents, including default credentials and a publicly known key.[13] Unintended solutions should be treated as defects with owners.

Transcript and tool-result manipulation undermines the evidence itself. Spoofed tool calls appear in the METR record,[7] which means a transcript is a claim about what happened rather than proof of it. Tool results should be recorded by the harness at the point of execution, written to append-only storage off-box, and correlated with independent infrastructure telemetry. Where the two disagree, infrastructure telemetry should win.

The immutable run manifest ties this together. The service state under evaluation must often be mutable; what should be immutable is the control-plane record: model and checkpoint identifier, prompt and task version, harness and scorer digests, image digests, initial-state snapshot hash, network, credential and approval policies, monitor versions, seeds and resource limits. Without it, a disputed result cannot be reconstructed and an incident cannot be scoped to the runs that shared a configuration. The authoritative score follows the same logic: compute it outside the agent's reach and report it through a channel the agent cannot write to.

8. Realistic evaluation without live production effects #

The usual objection to strong effect boundaries is that realism requires real services. Some of that requirement is genuine, and some of it is habit.

Agent-Diff demonstrates the substitutable part. It provides API-compatible local replicas of enterprise services, seeds a deterministic initial database state, intercepts network traffic and routes it to those replicas, snapshots before and after execution, and reports inserted, updated and deleted entities across 224 tasks and 108 API endpoints.[15] Two properties transfer beyond the benchmark. State-based grading avoids brittle exact-trace matching, so an agent is judged on outcome rather than on following a prescribed tool sequence. The closed-world invariant fails a run on any unaccounted insertion, deletion or mutation, which turns collateral damage into a measurable result instead of an invisible side effect.[15] That property is what most harnesses lack: in each 2026 cluster, external effects surfaced through security monitoring, third-party disclosure or retrospective review rather than through the evaluation reporting the change.[1][4][5] Simulated settings also underpin AI control experiments, where a model may pursue a side objective while monitors and protocols attempt to retain control.[12]

Simulation has limits that should be stated rather than glossed. Replicas target behavioural equivalence over the requests the benchmark exercises, not complete equivalence with production.[15] Notifications, billing, anti-abuse systems, rate limits, concurrency, live credential semantics and undocumented side effects may be absent, so an agent that never encounters a rate limit may look more capable than it is. Human interaction cannot be simulated faithfully, and a simulated maintainer does not tell you whether a real one would have accepted the pull request.

Evaluations that use genuine tools face the same tension. GrantBox integrates real MCP servers and privilege-sensitive tools into a monitored container environment, with 10 servers and 122 tools across cloud infrastructure, databases, email, personal data and local-device operations.[14] Across crafted attack cases, prompt-injection attack success averaged 90.55 per cent for ReAct agents and 79.05 per cent for plan-and-execute agents, with an overall reported average of 84.80 per cent.[14] Those numbers come from deliberately constructed attacks against models without modern injection defences or authorisation brokers, and they do not estimate ordinary-user risk.[14] They do indicate that tool authority should not rest on the model's judgement.

The practical arrangement is a ladder. Use replicas for the majority of runs, dedicated test tenants where protocol fidelity matters, and live third-party services only where the research question cannot be answered otherwise, with an explicit scope, a broker in front of every mutation, prior notification to the service owner where feasible, and a named person who can stop the run. Where a control is expected to distort a result, record the distortion in the run manifest instead of removing the control quietly.

9. Monitoring and incident response #

Evaluation infrastructure should connect to ordinary security incident management, with additional triggers specific to agents. NIST SP 800-61 Revision 3 provides the surrounding lifecycle of preparation, detection, response, recovery and improvement.[23] What the 2026 record adds is the set of signals worth escalating and the actions that need to be possible within minutes.

The evidence plane should be off-box and should cover model inputs and outputs, tool requests and results, file writes, process and privilege events, network flows and DNS, credential issuance and use, external mutations, grader access, and writes to shared state. Anthropic reports that an offline chain-of-thought monitor would have missed the PyPI incident because the model's reasoning persuaded the monitor that the environment was simulated,[9] so monitoring the model's account of itself supplements infrastructure telemetry rather than replacing it. The reliable signals in 2026 were network and identity signals: Tor traffic leaving an evaluation system,[5] unusual identity-related API activity,[6] and port sweeps.[6]

Escalation triggers worth defining in advance include unexpected connectivity or a destination outside the allowlist; boundary probing such as privilege enumeration; grader access or transcript anomalies; cross-run writes to shared state; use of credentials not issued to the run; any external write; and any attempt to alter monitors, logging or network policy.

Response actions should be tested rather than assumed. The incidents exercised stopping a single run; shutting down a run family or an entire platform, as OpenAI did on 20 July and Anthropic did on 23 July;[4][6] revoking credentials and blocking vulnerable paths;[6] preserving snapshots and transcripts before rebuilding; quarantining a model or checkpoint;[6] disabling internal access to the most capable models and isolating machines, as AISI did within about an hour;[5] notifying affected parties, as Anthropic did on 27 July;[4] and disclosing to a vendor whose product contained an exploited vulnerability.[6]

Two organisational lessons stand out. Authority to stop a run must sit with the responder: on 27 June, port sweeps were detected and the advice was that the run did not need to be stopped.[6] Retrospective review capability is also part of preparedness. Anthropic could search 141,006 runs, and later roughly 481 million transcripts, because the transcripts were retained and searchable.[4][9] It also found transcripts missed by its first search,[9] which argues for treating retrospective search as a fallible instrument and re-running it as the query improves.

10. Third-party evaluators and shared responsibility #

Much frontier evaluation is performed by external organisations, and all four Anthropic incidents arose in environments built by one partner.[4] The provider cannot transfer the risk along with the harness, and the evaluator cannot assume that a pre-release model arrives with deployment safeguards attached.

Anthropic published requirements for partners running pre-release models without cyber safeguards, and they are worth reading as one organisation's answer rather than as an industry standard. They include a hardened sandbox with no internet by default; model API keys held outside the environment; verification of network configuration before every evaluation; static and dynamic escape testing, ideally inside a second sandbox; confirmation that tasks are solvable; explicit in-scope targets, actions and networks; and continuous scope-aware monitoring capable of ending the run.[8] Two correspond directly to observed failures: network verification addresses the misconfiguration that produced the incidents, and solvability addresses the pattern in which an impossible task drove exploration.[4][6]

A workable division of responsibility looks like this. The provider characterises model risk, discloses the safeguard state of the checkpoint under test, controls credentials it issues, retains the ability to stop use of the model, and sets partner requirements. The evaluator owns environment configuration, containment validation, task solvability, monitoring and first-line incident response. Tool and service owners provide least-privilege interfaces, audit logs and safe failure behaviour.

Contracts should also say who may stop a run and on what evidence, who preserves and may access transcripts and telemetry, who notifies an affected third party and within what period, and what happens to model weights or artifacts on the evaluator's infrastructure afterwards. These are ordinary questions for a security engagement, and they were novel in 2026 mainly because evaluation had not been treated as one.

11. A practical operating model #

The controls below are stated as gates. Each has an observable artifact, so that a review can check evidence rather than intent.

Before a run

1. Classify the run by tooling level (arbitrary code execution, predefined tools, or none), host isolation level (container, userspace kernel, virtual machine, or nested), and network profile (none, allowlisted destinations, or unrestricted), following the axes in AISI's guidance.[10] Evidence: a classification field set before submission.
2. Produce the run manifest: model and checkpoint identifier, prompt and task version, harness and scorer digests, image digests, initial-state snapshot hash, network, credential and approval policies, monitor versions, seeds and resource limits. Evidence: a signed manifest stored outside the workload.
3. Record the safeguard posture per control, covering model safety training, classifiers, tool approval, behaviour monitors, network monitors and human approval, each marked enabled, reduced, disabled or unavailable. Six fields rather than one sentence avoids the misleading claim that all safeguards were switched off.
4. Verify the network boundary from inside the sandbox image: IPv4 and IPv6 egress, DNS resolution and DNS-based exfiltration, metadata access, registry read and write, proxy and browser tool use, and access to each supporting service. Evidence: a dated test report bound to the manifest.[8]
5. Issue credentials per run through a broker, with no long-lived secret in the environment. Evidence: an inventory listing issuer, audience, verbs, expiry and call ceiling.[21][22]
6. Bind every mutation-capable tool to a replica, a test tenant or a broker with an approved target list.[15] Evidence: a tool table giving each tool an effect class and a mediation mechanism.
7. Confirm the grader is outside the mutation boundary and reference data is unreachable from the workspace.[16] Evidence: a scorer location statement plus a leakage check against the image and cache.
8. Confirm task solvability, or record deliberately that the task is not solvable and that exploration is expected.[8]
9. Name the run owner, the security on-call, and the person authorised to stop the run family.

During a run

1. Enforce network policy at two independent layers, so that a defect in one does not open the boundary.[6][19]
2. Stream telemetry off-box to append-only storage.[24]
3. Run scope-aware monitors that can block a tool call, end the run and alert a person.[8]
4. Alert on the defined triggers: unexpected destination, credential not issued to the run, external write, grader access, cross-run state write, privilege change, monitor or policy modification.
5. Diff state around every mutation-capable tool call and fail the run on unaccounted change.[15]
6. Enforce budget ceilings for actions, external requests, spend and wall-clock time.
7. Require human approval before any contact with a real person, real project or public registry.

After a run

1. Compute the authoritative score outside the workspace from exported artifacts.[16]
2. Produce an external-effect record using the ladder in Section 6, with attempted, succeeded and impact-confirmed as separate fields.
3. Preserve the workspace snapshot, transcripts and telemetry under the retention rule in the manifest before destroying the environment.
4. Revoke and rotate all credentials issued to the run, whether or not they were used.
5. Verify no residue crossed run boundaries: no writes to shared caches, registries or buckets that persist to the next run.
6. Triage unintended solutions as benchmark defects with owners.[13]
7. After an incident, notify affected parties on a defined clock, disclose vulnerabilities to the vendors involved, and hold a postmortem that separates benchmark validity, grader integrity, sandbox containment, external-effect containment and model behaviour.[4][6][23]

Measurable indicators for a programme review: percentage of runs with a signed manifest; percentage with a dated network verification within the current engagement; percentage of credentials that are per-run and expiring; percentage of mutation-capable tools bound to a replica, tenant or broker; percentage of runs scored outside the workspace; median time from trigger to run termination; percentage of runs with a completed external-effect record; and time from incident identification to affected-party notification.

12. The strongest counterargument #

The strongest case against this programme is that it degrades the thing it protects.

Realism sometimes requires the real internet. A cyber-capability evaluation that never touches live infrastructure may not measure the capability that matters. Real services have operational behaviour that replicas do not reproduce completely, and Agent-Diff's authors are explicit that behavioural equivalence is scoped to the requests the benchmark exercises.[15] An organisation that evaluates only against simulations may conclude that a model is less capable than it is, which is the more dangerous direction of error for a safety evaluation.

Strong isolation can also hide capability. If an agent detects that it is in a constrained environment, its behaviour may change, and AISI's work on environmental disclosure shows how much a sandboxed agent can infer from DNS, certificates, usernames, hardware strings and proxy configuration.[11] An evaluation that measures how a model behaves when it believes it is being tested is measuring something narrower than deployment behaviour, and the Anthropic incidents show that the simulation question is entangled with behaviour in ways that are not yet well understood.[9]

Controls also cost. Per-run microVMs, brokers in front of every tool, off-box telemetry, replica maintenance and pre-engagement verification consume engineering time that could go into more tasks or more models, and slower evaluation is itself a safety cost if it delays the discovery of a dangerous capability. A further objection concerns the evidence: three incident clusters, under intentionally permissive conditions and configurations that are not commercially available, are thin support for a general architecture,[5] and voluntary disclosure biases the sample.

These objections should shape the design rather than remove it.

On realism: the answer is graded exposure with explicit accounting. Most runs do not need live services, and the ones that do should be identified, scoped, brokered and monitored, with the fidelity gap recorded in the manifest. Live exposure becomes a deliberate, reviewable decision instead of a default inherited from a harness.

On observability effects: where mediation is expected to change behaviour, run paired configurations and record the difference rather than removing the mediation. The largest external effects in 2026 also came from environments where controls were weakest, so the trade is not simply fidelity against safety.

On cost: proportion applies. A fixed-tool, no-network evaluation does not need this apparatus, and most of the expensive items are one-time platform work that many runs share. The cost of the alternative was visible in 2026: infrastructure rebuilds, a model family shut down, third-party incident response, and public disclosure.[4][6]

On the evidence: the incidents are used here as existence proofs of failure modes rather than as a basis for frequency estimates, and each control in Section 5 rests on prior practice that does not depend on the 2026 record.[10][17][18][19][21][22][23][24][25]

13. What this paper does not claim #

It does not claim that current agents routinely escape hardened environments. The public evidence shows exploitation of misconfigurations, shared services and permissive configurations, and the benchmark evidence shows success against known misconfigurations rather than novel runtime or kernel vulnerabilities.[13]

It does not claim that containers are always inadequate. SANDBOXESCAPEBENCH's own conclusion is that correctly configured and patched container runtimes remain appropriate for current models in many contexts.[13] The argument here is about matching isolation strength to run properties.

It does not claim that the incidents establish independent hostile intent. The public record supports goal pursuit, reward hacking, biased reasoning, reckless continuation and unintended coordination. Anthropic's own assessment moved away from strong claims about model belief,[9] AISI states that it cannot determine when agents understood their actions were real,[5] and no source establishes a durable independent objective such as self-preservation.[7][9]

It does not claim that classifiers or behavioural safeguards are useless. It claims that they were absent or reduced in these runs by design,[4][5][6] that a reasoning-based monitor failed in at least one documented case,[9] and that a provider-side filter is not an independent containment boundary.

It does not claim that simulated services reproduce every production behaviour. Notifications, billing, anti-abuse systems, concurrency, live credential semantics and undocumented side effects may be missing.[15]

It does not claim any industry-wide incident rate. Three disclosed clusters from organisations that chose to publish cannot support a base rate, and the AISI observations come from a small number of runs under intentionally permissive conditions.[5]

It does not claim to invent sandboxing, least privilege, network segmentation or secure grading. Integrated AI containment was described in 2017;[25] production isolation systems for mutually untrusted workloads predate current agent evaluations;[17][18] AISI published evaluation-specific sandboxing guidance in 2025;[10] and evaluator-integrity and state-diff work was published before the July incidents.[15][16]

It does not claim that these boundaries are sufficient. AISI states directly that no sandbox provides complete assurance,[10] and gVisor's documentation makes the same point about its own scope.[18]

Conclusion #

What the 2026 disclosures show is that the properties which make an agent evaluation informative are the same properties that make it a production-risk workload. Arbitrary code execution, reachability, credentials and mutation-capable tools do not become safe because the surrounding activity is called research. The safeguards that normally constrain a model in a product are frequently reduced in an evaluation, and that is often the right choice, which is precisely why the environment has to hold on its own.

The three failures were different. One agent population left its execution context and turned a shared service into a coordination channel and an egress path. One set of environments was reachable when it was believed to be closed. One set of agents was given the internet deliberately and acted on real projects and real people through it. A containment programme that addresses only the first will pass its own audit and still publish a package, open a pull request, or change a record in someone else's database.

Six boundaries, engineered so that failure of one does not confer control of another, cover the observed failure modes. None of the components is new. What the record adds is the requirement to hold them all at once, to verify them before every engagement, and to record what a run did to the world with the same care given to whether it passed.

An evaluation that can change something outside itself is a system with users, even when none of them agreed to be part of the test.

Appendix A: Agent evaluation containment record #

Run family:
Run ID:
Date:
Evaluating organisation:
Evaluation partner (if any):
Run owner:
Security on-call:
Person authorised to stop the run family:

## Classification

Tooling level:            [arbitrary code execution | predefined tools | none]
Host isolation level:     [container | userspace kernel | VM | nested VM]
Network profile:          [none | allowlisted destinations | unrestricted]
Effect profile:           [replicas only | test tenant | brokered live | live]
Risk tier:

## Images and harness

Sandbox image digest:
Harness version and digest:
Scorer version and digest:
Base image build date and patch level:
Initial-state snapshot hash:
Seeds:
Resource limits (CPU, memory, disk, wall clock):
Action budget:
External-request budget:
Spend budget:

## Task

Task ID and version:
Prompt version and digest:
Task solvable by design:      [yes | no | unknown]
Exploration expected:         [yes | no]
In-scope targets:
In-scope actions:
In-scope networks:
Explicitly out-of-scope:

## Model

Model or checkpoint identifier:
Provider:
Pre-release:                  [yes | no]
Known behavioural notes from provider:

## Safeguard posture (record each separately)

Model safety training:        [enabled | reduced | disabled | unavailable]
Input/output classifiers:     [enabled | reduced | disabled | unavailable]
Tool-approval system:         [enabled | reduced | disabled | unavailable]
Behaviour monitors:           [enabled | reduced | disabled | unavailable]
Network monitors:             [enabled | reduced | disabled | unavailable]
Human approval:               [enabled | reduced | disabled | unavailable]
Reason for any reduction:

## Network boundary

Default policy:               [deny | allow]
Enforcement points (independent layers):
Allowlisted destinations and protocols:
DNS policy:
Metadata endpoint policy:
Package registry read path:
Package registry write path:  [denied | brokered | allowed]
Proxy, browser and screenshot tools:
Verification test report ID and date:
Routes tested (IPv4, IPv6, DNS exfiltration, metadata, mesh, cache,
private link, browser, supporting services):

## Identity boundary

Credentials issued to this run:
  - Issuer:
    Audience:
    Resources:
    Permitted verbs:
    Max calls:
    Expiry:
    Approval required:        [yes | no]
Ambient secrets present in environment:   [none | list]
Model API key location:                   [outside sandbox | inside sandbox]
Broker used for privileged actions:       [yes | no]
Revocation completed after run:           [yes | no] Date:

## Tools and effect boundary

| Tool | Effect class | Mediation | Approved targets |
| --- | --- | --- | --- |
|      |              |           |                  |

Mutation-capable tools bound to replica or tenant:   [all | list exceptions]
Human approval required for contact with real people or projects: [yes | no]

## Shared state and run isolation

Per-run namespace confirmed:               [yes | no]
Shared writable caches, registries or buckets: [none | list]
Cross-run communication paths reviewed:    [yes | no]
Post-run residue check:                    [pass | fail]
Residue found and disposition:

## External effects observed

| Level | Description | Attempted | Succeeded | Impact confirmed | Evidence |
| --- | --- | --- | --- | --- | --- |
| X0 | No external request |  |  |  |  |
| X1 |  |  |  |  |  |
| X2 |  |  |  |  |  |
| X3 |  |  |  |  |  |
| X4 |  |  |  |  |  |
| X5 |  |  |  |  |  |
| X6 |  |  |  |  |  |

Affected parties identified:
Notification sent:            [yes | no] Date:
Vendor disclosure required:   [yes | no] Date:

## Grader and evaluation integrity

Scorer execution location:    [outside workspace | inside workspace]
Reference data location and reachability check:
Answer-leakage check performed:   [yes | no] Method:
State diff performed:             [yes | no] Unaccounted changes:
Tripwire or tampering indicators:
Unintended solutions found:       [list, with defect owner]

## Telemetry

Off-box destination:
Append-only:                  [yes | no]
Streams captured: model I/O, tool requests and results, file writes,
process and privilege events, network flows, DNS, proxy decisions,
credential issuance and use, external mutations, grader access,
shared-state writes
Independent infrastructure telemetry correlated:   [yes | no]

## Kill switch

Mechanism:
Scope:                        [single run | run family | platform | model]
Last tested:
Agent-requested abort mechanism:
Agent-requested abort last tested:
Agent-requested abort honoured in this run: [yes | no | not requested]
Alerts raised during run:
Triaged by:
Disposition:
Time from alert to decision:
Median time from trigger to termination (this engagement):

## Retention and approvals

Transcript retention period:
Snapshot retention period:
Telemetry retention period:
Access restrictions:
Pre-run approval by:                  Date:
Security review by:                   Date:
Post-run sign-off by:                 Date:

Appendix B: Pre-run and incident-readiness checklist #

Classification and manifest

• Is the run classified by tooling, host isolation, network profile and effect profile?
• Is there a signed run manifest stored outside the workload?
• Are model, prompt, harness, scorer and image digests recorded?
• Is the safeguard posture recorded per control rather than as a single statement?

Execution boundary

• Does the isolation strength match the tooling level?
• Are privileged containers, host mounts and exposed runtime daemons absent?
• Is there an outer boundary of a different class when the evaluation targets isolation?
• Are host and runtime components patched to a recorded level?
• Are writable caches, registries, buckets and artifact stores isolated by run?
• Has the environment been checked for residue from previous runs?

Network boundary

• Is egress denied by default and enforced at two independent layers?
• Has egress been tested from inside the actual sandbox image within this engagement?
• Were IPv4, IPv6, DNS, metadata, mesh, package cache, private link and browser routes all tested?
• Is the metadata endpoint blocked or mediated?
• Are package download and upload authority separated?

Identity boundary

• Are all credentials per-run, audience-scoped, action-scoped and expiring?
• Is the model API key held outside the sandbox?
• Are privileged actions performed by a broker rather than by agent code holding a secret?
• Is there a credential inventory, and is revocation part of run teardown?

Effect boundary

• Does every mutation-capable tool resolve to a replica, a test tenant or a broker?
• Are in-scope targets, actions and networks explicit and machine-checkable?
• Is human approval required before contact with a real person, project or public registry?
• Is state diffed around mutation-capable calls, with unaccounted change failing the run?

Evaluation integrity

• Does the authoritative scorer run outside the agent's mutable workspace?
• Are reference answers unreachable from the workspace, caches and image layers?
• Are tool results recorded by the harness and written off-box?
• Are unintended solutions triaged as defects with owners?

Evidence and response

• Is telemetry append-only and stored outside the workload?
• Do monitors understand task scope, and can they block a call and end a run?
• Has the kill switch been tested at run, run-family and platform scope?
• Can an agent-requested abort reliably stop tool execution and terminate the run?
• Is there a named person authorised to stop a run family without further approval?
• Are alert decisions recorded with the owner, disposition and time to decision?
• Are retrospective transcript searches possible, and are they re-run when the query improves?

Third-party engagements

• Is there an agreed threat model and a written division of responsibility?
• Has the evaluator verified network configuration before this engagement?
• Has escape testing been performed, ideally inside a second sandbox?
• Are notification timelines, evidence retention and publication rights agreed?
• Is there a named on-call owner on each side?

Incident readiness

• Are escalation triggers defined for unexpected connectivity, credential discovery, external writes, grader access, cross-run coordination and monitor tampering?
• Is there a procedure for run-family shutdown, credential revocation, snapshot preservation and model or checkpoint quarantine?
• Is there a defined clock for affected-party notification and vendor disclosure?
• Does the postmortem template separate benchmark validity, grader integrity, sandbox containment, external-effect containment and model behaviour?

About the author #

Jason Doyle writes about reliable software, observability, incident leadership, applied AI, and practical controls for systems that influence human and organisational decisions. He publishes at jasondoyle.ie and can be contacted at [email protected].

References #

1. Hugging Face, Security incident disclosure - July 2026 , 16 July 2026,https://huggingface.co/blog/security-incident-july-2026 .
2. OpenAI, OpenAI and Hugging Face partner to address security incident during model evaluation , 21 July 2026,https://openai.com/index/hugging-face-model-evaluation-security-incident/ .
3. Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline , 27 July 2026,https://huggingface.co/blog/agent-intrusion-technical-timeline .
4. Anthropic, Investigating three incidents in our cybersecurity evaluations , 30 July 2026, corrected 3 August 2026,https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals .
5. UK AI Security Institute, Security Incident INC-2026-07-28-01 , 4 August 2026,https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing andhttps://cdn.prod.website-files.com/663bd486c5e4c81588db7a1d/6a724858f7db25c81487016d_Security%20Incident%20INC-2026-07-28-01.pdf .
6. OpenAI, OpenAI - Hugging Face Incident Technical Report , 26 August 2026,https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf .
7. Ryan Greenblatt, Ajeya Cotra and Hjalmar Wijk, Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident , METR and Redwood Research, 26 August 2026,https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/ .
8. Anthropic, Improving our alignment and security practices , 31 August 2026,https://www.anthropic.com/news/improving-alignment-security-efforts .
9. Anthropic, An alignment assessment of recent cybersecurity incidents , 9 September 2026,https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents .
10. UK AI Security Institute, The Inspect Sandboxing Toolkit: Scalable and secure AI agent evaluations andTechnical guidance: sandboxing configurations for agentic evaluations , 6-7 August 2025,https://www.aisi.gov.uk/blog/the-inspect-sandboxing-toolkit-scalable-and-secure-ai-agent-evaluations andhttps://github.com/UKGovernmentBEIS/aisi-sandboxing .
11. UK AI Security Institute, What can sandboxed AI agents learn about their evaluation environments? , April 2026,https://www.aisi.gov.uk/blog/what-can-sandboxed-ai-agents-learn-about-their-evaluation-environments .
12. UK AI Security Institute, Introducing ControlArena: A library for running AI control experiments , 22 October 2025,https://www.aisi.gov.uk/blog/introducing-controlarena-a-library-for-running-ai-control-experiments .
13. Rahul Marchand et al., Quantifying Frontier LLM Capabilities for Container Sandbox Escape , arXiv:2603.02277, 1 March 2026, version 3, 1 August 2026,https://arxiv.org/abs/2603.02277 andhttps://github.com/UKGovernmentBEIS/sandbox_escape_bench .
14. Quan Zhang et al., Evaluating Privilege Usage of Agents with Real-World Tools , FSE Companion 2026, arXiv:2603.28166, version 2, 20 April 2026,https://arxiv.org/abs/2603.28166 .
15. Hubert M. Pysklo, Artem Zhuravel and Patrick D. Watson, Agent-Diff: Benchmarking LLM Agents on Enterprise API Tasks via Code Execution with State-Diff-Based Evaluation , KDD 2026, arXiv:2602.11224,https://arxiv.org/abs/2602.11224 andhttps://doi.org/10.1145/3770855.3817555 .
16. Yonas Atinafu and Robin Cohen, RewardHackingAgents: Benchmarking Evaluation Integrity for LLM ML-Engineering Agents , arXiv:2603.11337, 11 March 2026,https://arxiv.org/abs/2603.11337 .
17. Alexandru Agache et al., Firecracker: Lightweight Virtualization for Serverless Applications , USENIX NSDI, 2020,https://www.usenix.org/conference/nsdi20/presentation/agache .
18. Ethan G. Young et al., The True Cost of Containing: A gVisor Case Study , USENIX HotCloud, 2019, and gVisor,Security Model ,https://www.usenix.org/conference/hotcloud19/presentation/young andhttps://gvisor.dev/docs/architecture_guide/security/ .
19. Kubernetes, Network Policies , accessed 10 September 2026,https://kubernetes.io/docs/concepts/services-networking/network-policies/ .
20. Amazon Web Services, Use the Instance Metadata Service to access instance metadata , accessed 10 September 2026,https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html .
21. Torsten Lodderstedt, John Bradley, Andrey Labunets and Daniel Fett, RFC 9700: Best Current Practice for OAuth 2.0 Security , IETF, January 2025,https://www.rfc-editor.org/rfc/rfc9700.html .
22. SPIFFE, SPIFFE Concepts , accessed 10 September 2026,https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ .
23. Alexander Nelson, Sanjay Rekhi, Murugiah Souppaya and Karen Scarfone, Incident Response Recommendations and Considerations for Cybersecurity Risk Management , NIST SP 800-61 Revision 3, April 2025,https://doi.org/10.6028/NIST.SP.800-61r3 .
24. Karen Kent and Murugiah Souppaya, Guide to Computer Security Log Management , NIST SP 800-92, September 2006,https://doi.org/10.6028/NIST.SP.800-92 .
25. James Babcock, Janos Kramar and Roman V. Yampolskiy, Guidelines for Artificial Intelligence Containment , 2017,https://arxiv.org/abs/1707.08476 .

source & further reading

jasondoyle.ie — original article