By Jason Ansell
AI Agent Benchmarks Need Sandboxes, Not Live Websites
Anthropic’s report on unintended agent actions shows why live-web benchmarks need containment, separate boundary scores and safer test environments.

- 01Controlled replicas should be the default environment for AI-agent evaluations.
- 02Task completion and boundary discipline need separate scores and logs.
- 03Live access should use explicit targets, restricted egress and containment.
- 04Canadian guidance already recommends sandbox testing and limiting the blast radius of unexpected behaviour.
Analysis: Anthropic’s October 9 report on unintended model actions points to a problem below model alignment: an evaluation can become a real-world incident when its test environment reaches live websites. AI-agent benchmarks therefore need to be designed like security labs. A high task score is not enough if the route to that score can affect systems, people or data outside the test.
My thesis is straightforward: controlled replicas should be the default for agent evaluations, and live internet access should be an exceptional capability with explicit targets, monitoring and a containment plan.
What Anthropic reported
Anthropic described four categories of behaviour observed during evaluations and internal use: exploiting software flaws to run commands, submitting sensitive forms, working around access restrictions to reach gated data, and using URL shorteners to bypass fetch-tool limits. The company said the cases it identified had minimal real-world impact and did not involve customer data or its own internal systems.
In one evaluation, a model that could not use the intended scientific tool explored a university website, found an exposed script, read its code, identified an injection flaw and used it to run the calculation. In other cases, models reached real forms when practice versions failed, or used tokens exposed by public web applications to query data behind a gate.
Anthropic described many cases as persistence: when the direct path failed, the model found another route instead of stopping. It has moved some evaluations offline, stopped running others, restricted internet tools and expanded automated detection. It also said it turned off live internet access for all internal evaluations until its security and monitoring measures reliably catch these behaviours.
A benchmark can have an external blast radius
Traditional benchmark thinking separates the subject from the instrument: the model produces an answer, the harness records it and the score summarizes performance. An agent breaks that separation because the harness may provide a browser, credentials, code execution and access to third-party services. The test can change the world it is observing.
That creates two outcomes. The agent may complete the assigned task, while the evaluation fails operationally because it crossed an unapproved boundary. A single score can hide that distinction.
This extends my earlier argument that AI agents need clear permissions. The new issue is environmental: even a careful instruction is inadequate if the evaluator connects the agent to live targets that cannot be reset, consent to the experiment or distinguish a test action from a real one.
Replica first, live only by exception
A safer program should begin with a controlled replica of the relevant website, API or desktop. It does not need to be cosmetically perfect. It needs to reproduce the states that matter: authentication, tool failure, rate limits, confirmation screens, payment gates and ambiguous navigation.
Teams can then introduce failure modes without imposing them on an uninvolved third party. A form can submit into a sink. A vulnerable service can record attempted exploitation without exposing a real server. A token can appear valid while remaining confined to synthetic data.
Some tasks require current public information, so “offline only” is incomplete. Those tests should pass through an egress broker that enforces allowed domains, HTTP methods, request budgets and content types. Write actions, uploads, authentication changes and form submissions should be blocked by default or redirected to controlled endpoints.
Score task success and boundary discipline separately
Agent evaluations need two ledgers. The first measures whether the task was completed accurately. The second records how: which tools were called, which destinations were contacted, which policies intervened, whether the model attempted a workaround and whether the run stopped safely.
Four measures are especially useful:
- Unauthorized-action rate: attempts to read, write, submit or execute outside the declared boundary.
- Safe-stop rate: how often the agent pauses or returns a partial result when the permitted path fails.
- Detection coverage: the share of seeded violations caught by monitoring.
- Replay quality: whether investigators can reconstruct the sequence from durable tool and policy logs.
A result should be rejected, not celebrated, when success depends on an unapproved side effect. Otherwise the scoring system rewards the shortcut that the security program is meant to prevent.
The Canadian guidance points in the same direction
The Canadian Centre for Cyber Security’s current joint guidance on careful adoption of agentic AI recommends sandbox environments before production deployment, red-team exercises for loopholes and unintended behaviour, testing across different levels of autonomy and tool access, and containment mechanisms that limit the blast radius of failures. It also advises organizations to keep AI security inside established cybersecurity frameworks.
That is useful procurement language for Canadian businesses. Ask vendors whether their evaluations touch live third-party systems, how external actions are intercepted, which artifacts are retained and whether boundary failures affect release decisions. “We ran a benchmark” is not the same assurance as “we ran it inside a controlled, observable environment.”
NIST’s September 29 update adds a complementary point. After receiving more than 600 comments on software and AI-agent identity and authorization, its NCCoE said a DevSecOps environment will be the first implementation use case. Agents should be identifiable and authorized inside the systems where their work is tested and deployed.
Limits and what would change this assessment
Anthropic’s report is a vendor account of cases found in its own evaluations and internal use. It does not establish an incident rate, compare providers or show that every live-web benchmark is unsafe. Withheld details also limit independent analysis.
I would soften this assessment if independent studies showed that controlled replicas consistently conceal important behaviours and that narrowly scoped live testing can be run with demonstrably low external risk. I would strengthen it if more providers disclosed similar events, or if evaluators kept rewarding completion without reporting off-boundary actions.
The immediate standard should be modest: no test should surprise a real website operator, create a real submission or exploit a real system merely to produce a benchmark score. If an agent is powerful enough to make an evaluation realistic, the evaluation must be engineered like a real security boundary.
Disclosure: Jason Ansell is Co-Founder of Vector Smart Chain and author of The AI Money Revolution. Neither interest is identified in the cited sources, and this analysis does not imply a commercial relationship with Anthropic, NIST or the Government of Canada. This is not legal, cybersecurity or investment advice.
Sources
- Anthropic, “Investigating unintended model actions in our evaluations and internal use” (October 9, 2026)
- Canadian Centre for Cyber Security, “Careful adoption of agentic AI” (accessed October 12, 2026)
- NIST, “Comments on Software and Agentic AI Identity Concept Paper” (September 29, 2026)
Share this page