Agent sandboxing

An agent with tools, memory and autonomy is a new kind of production risk. Sandboxing is how you find out what it actually does before your customers do.

What this is

A chat model that only answers questions can embarrass you. An agent is different: it holds credentials, calls tools, reads and writes data, and chains its own decisions. When it misbehaves — through prompt injection, a poisoned document, or plain misjudgement — it acts, and the consequences are real.

Sandboxing puts a controlled environment around the agent before production does it for you. We mirror the agent's real permissions and tools in an isolated setting, then run it deliberately against the situations you hope never happen, and record exactly what it did.

Nobody can promise you a fully safe agent, and anyone who does is selling something they cannot control. What can be done, rigorously, is to test against the failure cases that matter, constrain what the agent can reach, and test again every time it changes. That is what we do.

What an engagement covers

  • Deployment review

    What your agents can currently touch: permissions, credentials, tools, data flows, and the paths between them. Written down before anything changes, so every later finding has a baseline.

  • Sandbox design

    An isolated environment built around your agent's real configuration — its tools mocked or fenced, its data synthetic or scrubbed — so behaviour under pressure can be observed without production consequences.

  • Adversarial test pass

    The agent is run deliberately against the failure cases that matter: prompt injection, instruction smuggling in retrieved content, tool misuse, data exfiltration attempts, scope creep across chained steps.

  • Guardrail definition

    What the agent must never be able to do, expressed as enforceable constraints — permission boundaries, tool allowlists, spend and rate limits, human sign-off points — not as hopes in a system prompt.

  • Written evidence

    A report of what was tested, what the agent did, what was changed and why. Written so an engineer can act on it and an auditor can read it.

  • Re-testing on change

    A new model, a new tool, a new prompt — any of these changes the agent. We re-run the test pass against the same documented cases, to catch drift before production discovers it.

How engagements are scoped

Every engagement begins with a short consultation, then the review. The review stands alone: findings, a documented baseline, and prioritised recommendations you could act on with or without us.

If a programme follows, it is scoped in writing from those findings. There is no fixed package, because no two agent deployments carry the same risks.

Start with the review

The review is a deliverable, not a sales deck, and it follows a short consultation to establish fit. Send your company name, what your agents do, and what worries you most.

Request a compliance review