What breaks when indirect prompt injection defenses rely on text inspection?

Why Text Inspection Fails Against Indirect Prompt Injection

Text inspection works only while the defender can reliably separate benign-looking content from hostile content before the model uses it. indirect prompt injection breaks that assumption. The attacker is not trying to trigger a fixed phrase list, they are trying to change the model’s behaviour through content that looks ordinary until it is interpreted in context, which makes text-only classification brittle by design.

Once the control is positioned as a detector, it becomes part of the contest. The attacker can vary phrasing, embed instructions in surrounding prose, split intent across multiple fragments, or probe the boundary until the detector misclassifies the payload. That is why the failure is not just “bad filtering”, it is a structural mismatch between adaptive adversarial input and static content inspection.

A useful comparison is the general agentic threat surface: NHIMG’s Agentic AI Security Guide treats prompt injection, tool misuse, memory poisoning and identity abuse as a layered problem, not a text-parsing problem. The relevant defensive boundary is whether the model can act on untrusted content, not whether the content can be labelled malicious after the fact.

What Actually Becomes the Attack Surface

With indirect prompt injection, the attack surface expands beyond the injected sentence itself. Delimiters, “ignore previous instructions” filters, prompt rewriting, sanitisation rules, and detector prompts all become targets because the adversary is now attacking the control path as much as the model path. The model can still be steered even when the overt text looks harmless, especially if the content enters through retrieval, email, documents, web pages, tickets, or other trusted channels.

This is why text inspection often gives a false sense of containment. It may reduce noisy attacks, but it does not create a durable trust boundary. A strong control has to assume that hostile instructions can be hidden in content, transformed by paraphrase, or surfaced only after multiple retrieval and summarisation steps.

Practically, the reader should think in terms of authority boundaries and action boundaries. If untrusted text can influence tool calls, memory writes, data disclosure, or state changes, then the problem is no longer “detect the bad text”, it is “prevent untrusted text from obtaining authority”. That is the same underlying lesson shown in Browser and Computer-Use Agent Security Guide, where session scope and site isolation matter more than content scanning alone.

What Durable Defenses Replace Text-Only Detection

Durable protection shifts from language inspection to control-plane design. The model should treat retrieved or externally supplied text as data, not instructions, unless a separate policy explicitly grants it authority. Tool use should be gated, high-impact actions should require confirmation or narrow policy, and retrieved content should not inherit trust just because it came from a legitimate source.

That also means the best defence is usually layered. Content screening can still be useful for triage, but it should sit behind stronger controls such as scoped permissions, explicit tool allowlists, output validation, and separation between untrusted context and privileged operations. If the system must summarise or act on external content, the safer question is not “did we detect prompt injection?” but “what can this content cause the model to do, and with whose authority?”

For concrete attack-path thinking, the ForcedLeak (Salesforce Agentforce) 2025 case shows how poisoned input becomes dangerous once the agent can act across trusted workflows, while EchoLeak (Microsoft 365 Copilot) 2025 shows how zero-click content can trigger data exposure without a user making an obvious mistake.

Risk and Threat Considerations

Text-inspection controls are attractive because they are easy to deploy, but they are brittle against adaptive attackers. Once the attacker can iterate on wording, placement, or retrieval source, the detector becomes a moving target, and the system may silently cross from “flagged content” to “trusted content” without any meaningful change in risk.

Failure mechanism: The defensive layer tries to classify hostile intent after the content has already entered the model’s context, so the attacker can evade by paraphrase, fragmentation, encoding tricks, or by attacking the rewritten prompt and delimiter logic itself.

Impact: The model can be induced to reveal data, misuse tools, or follow attacker goals while operators believe text scanning has contained the threat. That creates a false assurance problem, and in agentic systems it can turn a content issue into unauthorised action or data exfiltration.

Practitioner Guidance

What to prioritise: Treat text inspection as a supporting signal, not the security boundary. The first design question should be which actions, tools, memories, and data sources are reachable from untrusted text.

What to verify: Confirm that externally sourced content cannot directly trigger high-impact actions without an explicit policy check or human approval path. If the answer is “it can”, the system is still relying on content classification as its main defence.

Common mistake: Rewriting prompts or adding more detectors without reducing the authority granted to retrieved text. That improves noise handling, but it does not materially change the attacker’s leverage.

Practitioner takeaway: The control fails when you ask a detector to solve an authority problem; the fix is to narrow what untrusted text is allowed to influence, then make every remaining action observable and bounded.

Related resources from NHI Mgmt Group

• What breaks when prompt injection defenses rely only on pattern matching?
• What is the difference between prompt injection risk and identity abuse in agents?
• What breaks when indirect prompt injection is not controlled in AI systems?
• What breaks when prompt injection guardrails only look for obvious malicious text?