Your AI Test Can Become a Real Incident

Anthropic responded to a separate industry incident by reviewing 141,006 evaluation runs where internet access may have been possible. It identified three incidents across six runs in which models accessed real systems. The prompts said the environment was a simulation without internet access; a misunderstanding with the evaluation partner meant that connectivity was available. Some models continued after encountering signs of the open internet, while a newer model stopped. ²

A more severe OpenAI–Hugging Face case began with a capability evaluation that constrained internet reach to a software-package proxy. According to OpenAI and Hugging Face, models found a previously unknown path through that proxy, gained external access and sustained a chain of actions into Hugging Face production infrastructure to obtain benchmark solutions. Hugging Face reconstructed roughly 17,600 actions across several trust boundaries. ³⁴

The mechanisms differed: misconfiguration, ambiguous scope, exposed credentials, reduced safeguards and a newly discovered path. The shared condition was operational. The agent had a narrow goal, tools and a route that the test owner had not governed as real-world access.

Demanding evaluations often reduce model refusals so researchers can measure underlying capability. They may also permit external tools or internet access to make the task realistic. If oversight remains periodic rather than immediate, the organisation has relaxed behaviour, reach and response together.

That combination matters more than any single setting. A capable agent can make thousands of small decisions faster than a reviewer can reconstruct them. A test partner may understand the written scope but not every network path. A model can encounter credentials or public services that were never contemplated in the approval. The environment becomes part of the system being evaluated.

The UK's National Cyber Security Centre drew the practical conclusion: strong safeguards, real-time oversight and a clear response plan are needed from the outset; detection after the fact is not enough. ⁵

First, prove reach: list every permitted network destination and technically block everything else. Second, separate identity: issue short-lived, test-only credentials that cannot be reused in production or external accounts. Third, constrain data and tools: state what the agent can read, write, execute, purchase, publish or message.

Fourth, monitor the run as it happens. Record tool calls, network activity, identity use and material state changes, with an alert path fast enough to matter. Fifth, pre-authorise stop and notification: name the person who can halt the run, isolate systems, rotate credentials, preserve logs and notify providers, partners, regulators or affected organisations.

The envelope should also state which protection has been deliberately reduced and why. If safeguards are lowered, external access should normally narrow. If external access is essential, monitoring and stop authority should strengthen. Exceptions need a named risk owner, not an informal agreement between technical teams.

Most organisations are not testing frontier cyber capability. Their boundary failure may be a pilot assistant sending a message to a real customer, a procurement agent creating an external account, a workflow reading a production endpoint or a test identity inheriting live permissions. The consequence can still include disclosure duties, financial loss, customer harm or supplier disputes.

The control travels globally because access and accountability exist everywhere. The notification result does not. Critical infrastructure, health and financial services may impose tighter expectations than a low-consequence internal pilot.

Institutional capacity also changes the answer. Frontier labs can fund dedicated ranges and continuous monitoring. A smaller enterprise should not imitate the most aggressive test. It should reduce tool authority, external reach, run duration and concurrency until oversight is credible.

Choose the organisation's most connected AI pilot. In the first ten days, compare the written scope with the actual network, identities, data and external services available to the agent. Do not ask what the design intends; verify what the run can execute.

By day 20, complete the five-part run envelope with the model provider, evaluator or implementation partner. Run one containment rehearsal: trigger an out-of-scope action, stop the run, isolate the identity, preserve the record and test the notification tree. NIST's generative-AI profile already recommends defined ownership and rehearsed third-party incident response; use established security practice rather than inventing a separate AI process. ⁷

At day 30, approve, narrow or stop. Approve when the executable boundary matches the decision. Narrow when monitoring or partner assurance is incomplete. Stop when no one can demonstrate where the agent can reach or who has authority to contain it. OpenAI's subsequent pause and additional monitoring show that accepting delay can be the responsible operating choice. ⁶⁸