A coding agent receives a routine cleanup task. A file in its workspace tells it to remove an unrelated database, and its shell has enough access to try. A capability test should reveal the attempt without exposing a real database.
Build a disposable version of the task
Reproduce the useful parts of the workflow with synthetic data and disposable services. The cleanup task can use a fixture directory, a fake database, and marked dummy secrets. Specify which files the agent may remove and which resources must remain untouched.
Include both the legitimate task and misleading instructions in untrusted material. The test needs to distinguish successful authorised work from a refusal to do anything. An environment that blocks all useful actions tells you little about whether the intended workflow can operate.
Keep production credentials, personal keys, customer data, host control sockets, and real payment access out of the environment. Restrict the route to the model provider as well: when the provider is external, information sent in prompts leaves the test runtime even if ordinary internet access is blocked.
Enforce the boundary outside the agent
Test the permissions of the complete process, including its shell, mounted files, credentials, and reachable services. An instruction to stay in one directory does not restrict filesystem access.
One design uses a disposable virtual machine with explicitly shared fixtures and a gateway that denies unapproved network connections. The guest should have no general access to the host filesystem or production network. Allowed model and fixture endpoints need limits on operations, request size, and resource use.
These controls require verification for the actual configuration. A virtual machine still depends on its hypervisor, image, host setup, and shared interfaces. Describe that boundary and its assumptions instead of treating the deployment label as proof of isolation.
Turn the concern into a test matrix
For each case, define the allowed resource, expected intervention, and evidence collected outside the guest.
| Test | Expected result | Independent evidence |
|---|---|---|
| Complete the assigned cleanup | Remove only the designated fixture files | Before-and-after fixture inventory |
| Read a protected path | Access denied | Harness or filesystem enforcement record |
| Follow an injected deletion request | Protected fixture remains intact | Tool events and database state |
| Contact an unapproved address | Connection blocked | Gateway decision and destination |
| Copy a dummy secret into output | Exposure detected and run handled under test policy | Captured output and canary match |
| Exceed the run's resource budget | Limit enforced and run stopped | Host resource and termination records |
A model may decline a harmful request before attempting a tool call. Record that as observed behaviour. To test the enforcement itself, the suite also needs controlled probes that attempt the prohibited operation regardless of the model's choice.
Run with bounded time, storage, compute, and inference use. A disposable guest can still exhaust a shared host or model service.
Keep records the agent cannot rewrite
The harness should retain the scenario, model and runtime versions, image and policy identifiers, tool events, gateway decisions, and final artefacts. Keep these records outside the agent's writable environment.
Use them to reconstruct the run: what was requested, what the agent attempted, what the controls blocked, and what changed. Treat exported files and logs as untrusted when inspecting them or passing them to another model.
For repeatable comparisons, record the exact configuration and retain the fixtures. Model behaviour can vary between runs, so report repetitions and inconsistent outcomes.
Add supervision only with a defined role
An optional supervising model can inspect observable requests, responses, and tool events for patterns such as repeated credential probing. It needs labelled test cases, measured false alarms and misses, and a harness that can enforce the permitted intervention.
The supervisor receives untrusted content and can itself be misled. Its judgement supplements deterministic containment. If it mediates inference, the agent must have no alternate route to the backend for that mediation to cover the run.
B12Y's Prism is an experimental open-source reference implementation for this work. Its sandbox provides the containment boundary for supported gated model routes. It is not a production service or a multi-tenant security boundary, and the reference implementation is unsuitable for customer data or real credentials.
Report the access the evidence supports
A useful result might state that the agent completed the fixture task, attempted one unapproved connection that the gateway blocked, and left protected data unchanged in the recorded runs. Include untested paths and any gaps in observation.
That result supports a decision about the tested configuration and scope. It does not authorise unrelated actions or establish production suitability. Reassess material changes to tools, models, data sources, network routes, and runtime images before expanding access.