# Defending an agent against prompt injection _Updated 2026-08-21._ If your agent reads anything written by someone who is not your user — an inbound email, a web page, a support ticket, a PDF, a repository issue — you have a prompt injection problem. There is no known complete defence, and treating detection as if it were one is the most common architectural mistake in production agents. What works is layering: reduce the attack surface, detect what is detectable, and make a successful attack worthless. ## Why detection alone is not a defence Injection detectors are classifiers, and classifiers have false negative rates. Published figures make the gap concrete: in a 2026 evaluation of agent data injection attacks, Llama Prompt Guard 2 detected 326 of 935 instruction-injection attempts — about 35% — and half of the attacks still succeeded with it in place. That is not an argument against using a detector. It is an argument against making the detector the only thing between an attacker and your data. Build on the assumption that some fraction of injections will get through, and decide now what happens when they do. In the registry: [Lakera Guard](https://newagent.build/c/lakera), [Rebuff](https://newagent.build/c/rebuff), [Llama Guard](https://newagent.build/c/llama-guard), [Invariant](https://newagent.build/c/invariant) ## Remove the payout: default-deny egress An injection is only valuable if the agent can act on it. The most common goal is exfiltration — getting your data to somewhere the attacker controls. Default-deny egress removes that: the agent can only reach destinations on an explicit allowlist, and everything else is refused. This does not prevent injection. It means a successful injection has nowhere to send anything, which in practice is most of the damage. The stronger implementations also keep credentials out of the workload entirely: the sandbox holds opaque proxy tokens, and real secrets are swapped in at the boundary, so an attacker who compromises the agent walks away with tokens that are useless anywhere else. Two details separate a real egress boundary from a checkbox. It must deny by allowlist rather than blocklist, because the destinations an attacker picks are precisely the ones nobody thought to forbid. And it must refuse a host whose resolved address falls in a denied range even when the hostname is allowed — otherwise an allowlisted name pointing at the cloud metadata endpoint reopens the whole thing. In the registry: [iron-proxy](https://newagent.build/c/iron-proxy), [Cloudflare AI Gateway](https://newagent.build/c/cf-ai-gateway) ## Contain what the agent executes If the agent writes code that then runs, the blast radius of an injection is whatever that code can do. A container is not a sandbox — shared-kernel isolation was designed to separate cooperating workloads, not to contain hostile ones. Use a kernel boundary. A user-space kernel intercepts syscalls before they reach the host and starts fast, at 10–30% overhead on I/O-heavy work. A microVM gives each sandbox its own kernel and boots in roughly 125ms with under 5 MiB of overhead, which makes per-task disposable sandboxes affordable. In the registry: [gVisor](https://newagent.build/c/gvisor), [Firecracker](https://newagent.build/c/firecracker), [Kata Containers](https://newagent.build/c/kata), [E2B](https://newagent.build/c/e2b) ## Give the agent less to steal Most damage needs privilege. An agent acting with a service account that can read every customer's data will, under injection, read every customer's data. An agent acting with a per-user token scoped to the requesting user cannot. Redact before the model sees it, not after. If personal data never enters the context window, no injection can extract it from there. In the registry: [Arcade](https://newagent.build/c/arcade), [Auth0 for AI Agents](https://newagent.build/c/auth0-ai), [Descope Agentic Identity](https://newagent.build/c/descope-agentic), [Oso](https://newagent.build/c/oso), [Microsoft Presidio](https://newagent.build/c/presidio) ## Test it like an attacker, in CI Injection defence regresses silently — a prompt change, a new tool, a model upgrade. Run a red-team suite on every change rather than auditing once at launch. Public benchmarks give you a starting corpus, and a local eval harness turns it into a test you can fail a build on. In the registry: [promptfoo](https://newagent.build/c/promptfoo) ## Common questions ### Can prompt injection be fully prevented? No. There is no known complete defence, because the model cannot reliably distinguish instructions written by your user from instructions embedded in content it was asked to read. The practical goal is to make a successful injection worthless rather than impossible: sandbox execution, deny egress by default, and scope credentials to the requesting user. ### Does egress control stop prompt injection? No, and it is worth being precise about this. Egress control does not prevent the injection from succeeding. It removes the attacker's payout — an agent that cannot reach arbitrary destinations cannot exfiltrate data, no matter what instructions it was tricked into following. ### Is a Docker container enough to sandbox an AI agent? No. Containers share the host kernel and were designed to isolate cooperating workloads, not hostile ones. If an agent executes code it wrote, use a user-space kernel such as gVisor or a microVM such as Firecracker or Kata Containers. ## Machine interfaces - `GET https://newagent.build/api/registry` — every component as JSON - `GET https://newagent.build/api/vendors` — vendors, with the repo and releases feed to watch - `GET https://newagent.build/api/advise?q=` — recommended stack for a description - `GET https://newagent.build/api/stack?=&format=sh|json|md|yml|agents|env` — a stack as files - `GET https://newagent.build/llms.txt` — the whole registry in one fetch Any page here also returns markdown if you send `Accept: text/markdown`.