Defences that survive contact
Defences that survive contact are prompt-injection mitigations that still work when an agent reads hostile text, because they reduce authority, constrain actions, or verify effects outside the model. They treat prompts as fallible instructions, not as a security boundary, and put ordinary access control around model-driven behaviour.
The need arises because agents repeatedly mix trusted and untrusted material: developer instructions, user requests, retrieved pages, emails, tool results, and prior model output. If all of that becomes one stream of text, hostile content can be phrased as an instruction and the model may follow it. This is not mainly a wording problem. It is the familiar problem of letting untrusted input influence a component that has privileges.
Surviving defences move authority out of the prompt path. Tools get narrow permissions, explicit schemas, allowlists, and server-side checks. Risky actions require user confirmation or a separate policy decision. Outputs are validated before they become API calls, database writes, purchases, or messages. Secrets are kept out of model-visible context where possible. Sandboxes limit damage, and logs make it possible to inspect why an agent acted.
The trade-off is that stronger controls make agents less magically flexible. A tool schema may reject a clever but valid-looking request. Confirmation steps add friction. Sandboxes and permission boundaries require product and infrastructure work. Classification and retrieval filters can miss attacks or block useful content. The honest ranking depends on the asset at risk, but prompt hardening belongs below capability control because it asks the model to police itself.
Engineers meet this in MCP servers, retrieval-augmented generation, browser agents, email assistants, support copilots, and any workflow where model output can trigger tools. A useful review question is not, “does the system prompt forbid this?” It is, “if a web page tells the agent to leak credentials or change production state, what non-model boundary stops it?” If the answer is only more instruction text, the defence is brittle.
Common questions
- Why is prompt-level pleading not a real defence?
- Because it is made of the same material as the attack: text for the model to interpret. Phrases such as “ignore malicious instructions” can help with simple cases, but they do not create an access-control boundary. When trusted instructions and hostile content share one context, the model is being asked to resolve a security decision probabilistically.
- What is the strongest mitigation against indirect prompt injection?
- The strongest mitigation is removing or narrowing the agent’s authority. If the model cannot access a secret, call an unapproved tool, write to production, or perform a payment without an external check, injected text has much less power. Guardrails and filters are useful layers, but they should sit behind permissioning, validation, and confirmation.
- Are model-side guardrails useless?
- No. They can reduce obvious abuse, classify suspicious content, and improve behaviour in low-risk paths. The misunderstanding is treating them as sufficient. Guardrails are advisory controls around a probabilistic component. For actions with real side effects, use deterministic checks as well: schemas, allowlists, policy enforcement, sandboxes, and human confirmation where appropriate.
- How should I rank proposed defences?
- Ask what each defence changes. Best are controls that remove authority or constrain possible actions. Next are checks that validate, confirm, sandbox, or audit effects. Detection and filtering are useful but incomplete. Weakest are prompts that merely tell the model not to be tricked, because they leave the dangerous capability available.