Prompt injection is an attack in which text that a language model reads is treated as instruction rather than data. Direct injection comes from the user. Indirect injection — the harder problem — arrives inside content the agent was asked to process: a web page, a document, an email, a code comment, a support ticket, or the output of another agent.
There is no single control that stops it. Defence works the way defence works elsewhere in security: several independent layers, each assuming the previous one failed. This guide sets out those layers in the order they take effect, and it belongs to our coverage of secure AI infrastructure.
Why filtering alone cannot solve it
The instinct is to detect malicious instructions and strip them. This fails for a structural reason: natural language has unlimited paraphrase. An instruction can be split across paragraphs, encoded, translated, embedded in an image, hidden in white text, expressed as a hypothetical, or delivered as a plausible-sounding correction to the agent''s own task. A classifier trained on yesterday''s phrasings will miss tomorrow''s.
Detection is still worth running — it raises attacker cost and produces useful telemetry — but it must never be the control that stands between an injected instruction and a consequential action. The controls that hold are the ones that limit what an action can do, regardless of why the model decided to take it.
Layer one: provenance and trust labelling
Every piece of text entering the model should carry a label describing where it came from and how much authority it has. System policy is highest. Authenticated user input is next. Retrieved documents, fetched pages, tool output, and messages from other agents are untrusted content, permanently.
Labelling is only useful if the runtime enforces it. That means untrusted content is delivered in a clearly delimited channel, never concatenated into the instruction section of a prompt, and the agent''s policy states that content in that channel can be summarised, quoted, and reasoned about but can never change the task, the tool permissions, or the destination of an action. Provenance should also survive processing, so that a claim made three steps later can still be traced to the page it came from.
Layer two: tool gating and least privilege
This is the layer that does the real work. An injected instruction is harmless if the action it requests is unavailable.
Give each task only the tools it needs, for the duration it needs them. Split read and write into separate capabilities with separate grants. Constrain parameters rather than trusting them: a mail tool that can only send to previously verified addresses, a payment tool with an amount ceiling, a file tool restricted to one directory, a database tool limited to named queries rather than arbitrary SQL. Require a typed, validated argument schema so that free text cannot become a command.
Then gate the consequential actions behind a human decision. Money movement, external communication, permission changes, deletions, and production deployments are candidates. The approval must show the user what will happen in concrete terms — recipient, amount, destination — because an approval prompt that only says "the agent wants to continue" trains people to click yes.
Layer three: execution and network boundaries
Injection frequently aims at code execution or data exfiltration, so the boundaries that contain those actions are part of injection defence.
Run agent-generated code in an ephemeral isolated sandbox, and make outbound network access default-deny through a logging proxy. This closes the most common exfiltration path, where an agent is instructed to encode data into a URL and fetch it. It also closes the subtler variant, where the agent is told to render an image or a link whose address contains the stolen data. Our companion guide on AI agent isolation covers these boundaries in detail.
Layer four: output validation and rendering discipline
What the agent produces is an attack surface too.
Validate structured output against a schema before acting on it, and reject rather than repair anything that does not conform. Treat model output as untrusted when it reaches another system: escape it before it enters HTML, never pass it into a shell, and never let it construct a query string that is executed directly. Strip or refuse active content — scripts, iframes, auto-loading remote images, and links to unapproved hosts — in anything rendered back to a user. Where an agent''s output becomes another agent''s input, apply the same provenance labelling you applied to external content, because a compromised worker is now an untrusted source.
Layer five: monitoring, evidence, and response
Assume some attempts succeed, and design so that you can tell.
Log the full chain: the inputs and their provenance, the tool calls with their arguments, the approvals granted, the network requests attempted and refused, and the final output. Alert on the patterns that distinguish injection from normal use — a sudden attempt to reach an unlisted domain, a tool call whose parameters contradict the user''s stated task, repeated refusals followed by a rephrased success, or a spike in output length after retrieving a single page.
Then rehearse the response. Revoke the session''s credentials, destroy the sandbox, quarantine the source content, and reconstruct what was reachable during the window. If you cannot answer "what did this agent touch" from your logs within minutes, the monitoring layer is incomplete.
A practical evaluation checklist
Use this to assess your own system or a vendor''s. Is untrusted content structurally separated from instructions, and can you see where the separation is enforced? Are tools scoped per task, with read and write split? Which actions require human approval, and does the approval show specifics? Is egress default-deny and logged? Is agent output validated against a schema and escaped before rendering? Can you produce a complete trace of a single agent run, including refused requests? And has anyone tested the system with indirect injection in a retrieved document, not just with typed user prompts?
Systems that answer all seven confidently are rare. Systems that answer none are common, and are usually protected by nothing more than the model''s good manners.
Why this is becoming its own product category
Each layer above is now a market: gateways that mediate model and tool access, sandboxes that contain execution, credential brokers that keep secrets outside the agent, and observability platforms that retain the evidence. Buyers search for these functions in plain language, which is why descriptive infrastructure names carry commercial weight.
That is the thesis behind assets such as ProxyGuardAI.com and SwarmSecurityAI.com in our portfolio. If you are assessing the wider control stack rather than a single layer, start from the secure AI infrastructure hub.