104 / 108 · 03 Agentic Testing Architectures · Testing Agentic Systems: MCP, A2A, and Agent Evals← prev⊞ allnext →☰ Read as one page
14.5Surface 4: Sandboxing the Agent Under Test
In Guardrails, you constrained your testing agent. When the SUT is an agent, the same thinking applies with the roles reversed -- and stricter, because you will deliberately feed it hostile inputs:
| Guardrail (testing agent) | Sandbox equivalent (agent under test) |
|---|---|
| Allowed domains | Network egress allowlist: the agent can reach its mock tools and nothing else |
| Action allowlist | Mock MCP servers for every side-effecting tool (email, payments, deploys) |
| Token budget | Per-scenario spend cap -- an agent in a reasoning loop burns real money |
| Max steps / timeout | Same, enforced from outside the agent's own runtime |
| -- | Throwaway state: fresh database, fake credentials, synthetic PII only |
The non-negotiable rule: the agent under test must not be able to tell anyone anything true. Fake credentials, synthetic user data, mock payment rails. Test scenarios include adversarial prompts, and an agent that can exfiltrate real data through a real tool during a prompt-injection test is an incident, not a test.