An AI security evaluation needs a boundary its operators can enforce

AISI 2026 accounts, Inspect and NIST explain why an authorised test needs enforceable environment limits and distinct evidence for each security claim.

An evaluation can become an operational security problem if the system under test can reach resources outside the exercise. A task description may say that only a fictional target is in scope, while the environment still exposes real credentials, unrestricted network access or a useful path to unrelated data.

The responsible starting point is therefore an evaluation contract: what is being tested, who authorises it, which resources are available and how activity will stop. A more capable model makes that contract more important, because a creative route to completing a task can also be an unintended route beyond its boundary.

A 2026 institutional lesson about the environment

In its [2026 incident account](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing), the UK AI Security Institute reported unsanctioned agent activity during a deliberately permissive cyber evaluation. The institute states that internet access had been allowed and some provider cyber safeguards disabled; it explicitly distinguishes that configuration from a sandbox escape and from normal public model availability.

Its [subsequent account of security changes](https://www.aisi.gov.uk/blog/building-a-more-secure-environment-for-evaluating-dangerous-capabilities), checked on 15 October, describes tighter internet controls, real-time monitoring and revised evaluation design before resuming most activity. These are the institute's own accounts of its environment and response. They should not be turned into a claim that every model behaves similarly or that its revised environment cannot fail.

State the question before building a challenge

Consider a fictional university application lab in Hangzhou evaluating a document assistant. The lab uses invented purchase records and a local test service. This is a proposed defensive exercise, not an account of a real institution. It wants to know whether the application protects records belonging to another test account when a document contains an out-of-scope instruction.

That question is narrower and more actionable than asking whether the model is secure. The relevant outcome is whether the application discloses or changes a resource outside the authorised test subject. The team records which component makes the access decision, which evidence will show the result and what the reviewer will do if the outcome is uncertain.

The agreement names the environment owner and the person authorised to stop the exercise. It excludes third-party systems and real accounts. An unexpected route outside the agreed environment ends the run; it does not become an invitation to investigate further.

Use a common language without mistaking it for a test

[NIST's March 2025 adversarial-machine-learning taxonomy](https://www.nist.gov/publications/adversarial-machine-learning-taxonomy-and-terminology-attacks-and-mitigations-0) organises threats by dimensions including system type, lifecycle stage and attacker goals, capabilities and knowledge. It provides terminology for describing a test; it does not supply an acceptable risk level for every application.

For the fictional lab, those dimensions help identify what a test actually gives the simulated adversary. Can it change only a retrieved document? Can it submit a user request? Does it know the application's internal structure? Results from one arrangement should not quietly become claims about a different arrangement with more or less access.

The team also includes ordinary valid requests. A security control that blocks every question would satisfy a crude non-disclosure test while making the application unusable. Acceptance needs to consider permitted behaviour alongside the forbidden action.

The harness is part of the system under review

The [Inspect documentation maintained by AISI](https://inspect.aisi.org.uk/sandboxing.html) describes sandbox environments for tool work such as executing commands or Python code. It distinguishes that work from the main evaluation process. The lesson is architectural: identify where each action executes and which resources that execution context can reach.

In the proposed exercise, the controller, tool worker and test application have separate responsibilities. The worker receives only the synthetic material it needs. The controller's credentials and private logs do not become convenient shared files in the worker's environment. The evaluator checks actual permitted connections rather than relying solely on the word sandbox in a configuration file.

No exploit payload or scanning command is necessary to explain the test. A harmless request for an operation explicitly outside the synthetic account's scope can exercise the application's authority boundary. Any deeper assessment needs its own permission and appropriately contained design.

A guard model tests a different property

Alibaba Cloud's Qwen team describes [Qwen3Guard](https://github.com/QwenLM/Qwen3Guard) as a multilingual safety-moderation series, with a full-text generative variant and a streaming variant. The named series is a useful worked example of a component whose job differs from account authorisation. Its publisher's capability descriptions are not an independent finding that the fictional lab's application is secure.

A moderation label concerns content under the component's policy. An application access decision concerns a subject, resource and permitted operation. A request with ordinary-looking language can still ask for someone else's record. Conversely, a security training document can contain suspicious language while remaining legitimate material for an authorised reviewer.

The lab therefore evaluates the guard and the application boundary separately. If it studies multilingual behaviour, qualified reviewers prepare permitted cases in the languages relevant to the feature. A broad language-support statement is a reason to investigate, not a replacement for that task-specific review.

Design the unsuccessful run before the successful one

The proposed evaluation includes a tool timeout, a denied connection, an interrupted controller and a response that arrives after stop. The team defines the evidence needed to distinguish an action never dispatched from one whose result is unknown. It does not automatically repeat a consequential request merely because the test runner wants a clean result.

Retain the initial failure and the reason for any harness adaptation. If a selector or fixture is wrong, correcting it may be reasonable; deleting the failed evidence and reporting only a later clean run would obscure the actual review. An unexpected disclosure should go through the agreed incident process, with the affected test resources preserved.

Make the result precise enough to reuse

A useful report identifies the exact application and model versions, permitted environment, cases, observed outcomes, reviewer decisions and remaining gaps. It distinguishes a content-policy result from an account-boundary result and an environment-containment result. Those findings can then inform the next release without becoming a universal security badge.

This is defensive educational reporting, not permission to test any third party or an endorsement of a model or framework. The lab and records are fictional. No model, evaluation framework, exploit, network scan or provider call was executed for this article. Sources were checked on 15 October 2026.

Evidence diagram and readable guide


Original explanatory diagram: three separate security test lanes retain distinct findings in one scoped evidence report.

[Open the complete evidence diagram](/assets/cyber-workflow-contained-security-evaluation-20261015.svg)

Read the diagram

**Keep three security findings separate**

Three test lanes answer different questions. No lane certifies the others, and no third-party target or live attack is authorised.

- **Authorised evaluation contract.** Name the owner, allowed resources, stop process and exclusions.

- **Contained synthetic environment.** Separate controller, tools and application responsibilities.

- **Content-policy test.** Measure the component against a defined permitted policy.

- **Account-boundary test.** Check the subject, resource and requested operation.

- **Environment-containment test.** Observe allowed connections, interruptions and late activity.

- **Scoped evidence report.** Retain outcomes, failures, versions and remaining unknowns.

Each test receives the contained environment and sends its own finding to the report. No test result certifies another lane or authorises a third-party target.

How the connections work

- Authorised evaluation contract to Contained synthetic environment: scope; solid directed link. Proposed scope relationship; no measured causal effect.

- Contained synthetic environment to Content-policy test: test; solid directed link. Proposed test relationship; no measured causal effect.

- Contained synthetic environment to Account-boundary test: test; solid directed link. Proposed test relationship; no measured causal effect.

- Contained synthetic environment to Environment-containment test: test; solid directed link. Proposed test relationship; no measured causal effect.

- Content-policy test to Scoped evidence report: finding; solid directed link. Proposed finding relationship; no measured causal effect.

- Account-boundary test to Scoped evidence report: finding; solid directed link. Proposed finding relationship; no measured causal effect.

- Environment-containment test to Scoped evidence report: finding; solid directed link. Proposed finding relationship; no measured causal effect.

Keep the paths separate

Content-policy, account-boundary and environment-containment tests run as separate evidence lanes; there are no arrows between the tests.