During 2026, several frontier developers reported cases in which AI agents under evaluation reached systems outside the scope they were meant to operate in. Published analyses describe agents working on simulated security tasks that found routes into real infrastructure through misconfigured environments or unintended network access. In at least one reported case the developer stated that the model stopped when it reached a real organisation. The details differ between incidents, and the analyses are careful not to attribute intent. The common thread is simpler: the boundary everyone assumed was there was not.
It would be easy to treat this as a problem for the handful of organisations training the most capable models. It is not. Any organisation that tests an agent against a staging environment, a copy of production data or a sandboxed integration is making the same assumption on a smaller scale.
Why boundaries fail
- Environments drift. A test environment built carefully once is modified many times. A new integration, a shared credential or an opened port can quietly connect it to something real.
- Shared services leak. Package registries, artefact stores, logging pipelines and identity providers are often shared between test and production, and each is a potential path.
- Agents are persistent. A capable agent given an open-ended goal will try routes a human tester would not think to try, and will keep trying.
Verify containment like any other control
The practical response is to treat isolation as a control that has to be evidenced, not a property of the environment's name. Before an agent is tested, someone should be able to show which networks it can reach, which credentials are present, and which shared services it can touch. Egress should be denied by default and allowed by exception. Credentials in the environment should be unique to it and worthless elsewhere. Monitoring should alert on any attempt to leave the intended scope, whether or not it succeeds.
Plan for the evaluation that goes wrong
An incident response plan for evaluations sounds excessive until it is needed. It should state who can halt a run, how to revoke the agent's access, how to notify any third party whose systems were reached, and how the event will be recorded. Writing that plan forces the questions that prevent most incidents in the first place.
The organisations that handled 2026's incidents well were those able to reconstruct quickly what happened. The ones that will handle the next generation of agents well are those that assume the boundary may fail and design so that failure is visible, contained and recoverable.