Filtering reduces exposure, but it does not remove the agent’s ability to act on instructions that slip through. The attack succeeds when the agent can combine trusted retrieval, allowed tools, and outbound paths into one sequence. Content controls are useful, but they are not a substitute for runtime authority limits.
Why filtering cannot stop indirect prompt injection on its own
Filtering helps, but it is only one checkpoint in a larger execution path. indirect prompt injection works when malicious instructions arrive through content the system already trusts, then influence planning, retrieval, or tool use after the filter has done its work. The weakness is not just the text itself, it is the agent’s permitted authority to act on it.
That is why the same payload can fail in a passive chatbot yet succeed in an agent that can search, call tools, write files, or send data onward. The control boundary moves from “block the bad text” to “constrain what the runtime is allowed to do if bad text slips in.”
For a broader agentic threat model, see the Agentic AI Security Guide, which explains how prompt injection combines with tools, memory, and orchestration.
Where the attack path usually succeeds
Indirect prompt injection usually exploits a chain, not a single weakness. A poisoned page, document, ticket, email, or CRM field is retrieved as “content,” the model treats it as actionable instruction, and the agent then uses its allowed capabilities to continue the attacker’s goal. Content filters may reduce obvious abuse, but they do not reliably distinguish user intent from instructions embedded inside otherwise legitimate data.
The practical failure mode is trust transitivity. If retrieval brings untrusted text into the context window, and the runtime treats that text as potentially authoritative, the agent can be steered into disclosure, prompt rewriting, tool misuse, or unsafe outbound actions even though no obvious malicious token was present at ingress.
Real-world examples show the pattern clearly. A zero-click assistant leak such as EchoLeak (Microsoft 365 Copilot) 2025 demonstrates that trusted content channels can carry the attack past filtering, while ForcedLeak (Salesforce Agentforce) 2025 shows how poisoned workflow inputs can steer an agent toward CRM exfiltration.
Why runtime authority limits matter more than text filters
The decisive issue is whether the agent can turn instructions into action. If the system can only read text, filtered content may be enough. If it can retrieve sensitive context, invoke tools, and reach outbound channels, then the defensive job is to break the chain between untrusted input and privileged action.
That means bounding what the agent can access, what it can hand to tools, and what it can export. Filtering still has value as a first line of defense, but it should be treated as input hygiene, not a control for authorization. The safer design is to assume that some malicious instructions will survive and to make sure they cannot reach high-impact actions without extra checks.
Agent-specific guidance in OWASP Agentic AI Top 10 and threat modeling references such as the MITRE ATLAS adversarial AI threat matrix both reinforce that prompt injection becomes materially worse once tools, memory, and delegated actions are in scope.
Risk and Threat Considerations
Indirect prompt injection is risky because it can cross a trust boundary without looking malicious at ingestion time. The dangerous part is not only data leakage, it is that the injected instruction can trigger tool use, credential exposure, or unwanted outbound communication after content controls have already approved the source.
Failure mechanism: The attacker places instructions inside retrieved or displayed content, the agent incorporates them into its reasoning, and allowed tools or output paths turn that reasoning into action.
Impact: The result can be secret exposure, unauthorized workflow execution, data exfiltration, or downstream misuse of the agent’s identity and permissions, even when the original content passed filtering.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Indirect prompt injection often succeeds by steering agent tool use. |
| ASI03 — Identity & Privilege Abuse | The question is about injected instructions exploiting delegated agent authority. | |
| ASI06 — Memory & Context Poisoning | Injected content survives filtering when it contaminates agent context or memory. | |
| Recommendation — Restrict tool permissions and validate tool-triggering instructions before execution. Bound agent privileges so untrusted content cannot escalate into protected actions. Isolate untrusted context and prevent poisoned inputs from influencing durable state. | ||
| MITRE ATLAS | Adversarial AI Threat Techniques | Prompt injection is an AI adversarial technique that helps model the attack path. |
| Recommendation — Map the injection path to adversarial techniques and test controls against them. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime authority limits are central to stopping injected instructions from causing impact. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Agent actions after successful injection need reviewable traces for detection and response. | |
| Recommendation — Apply least privilege so a compromised agent cannot exceed its intended authority. Log and review agent actions that can reach tools, data, or outbound channels. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer hinges on not trusting content or actions simply because they are internal. |
| Recommendation — Treat retrieved content as untrusted and verify each action before allowing it. | ||
| OWASP ASVS | V8 — Authorization | The core failure is unauthorized action after malicious instructions enter context. |
| Recommendation — Enforce authorization checks on every sensitive agent action and state change. | ||
Practitioner Guidance
What to verify: Check whether your agent has a separation between untrusted content ingestion and privileged action. If retrieved text can influence tool calls, outbound email, file writes, or API requests without a secondary decision point, filtering is being asked to do too much.
Decision rule: If the content source is outside your trust boundary, treat the agent’s next action as untrusted until it is independently validated. If the action can change state or reveal sensitive context, require explicit policy checks, scoped permissions, or human confirmation before execution.
What practitioners underestimate: Teams often tune filters for obvious prompt injection strings and miss the broader problem, which is execution authority. The control that really matters is whether the agent can be steered into a high-impact action after the malicious text has blended into normal retrieval.
Practitioner takeaway: Filtering should reduce attack surface, but runtime containment decides whether indirect prompt injection becomes an incident. Design for the assumption that some malicious instructions will get through, then make sure they cannot reach sensitive tools or outbound paths unaudited.
Related resources from NHI Mgmt Group
- Why do agents that read untrusted content still face prompt injection even when they have alignment checks?
- Why do phishing campaigns still work even when organisations have security tools in place?
- Why do indirect prompt injection attacks become more dangerous when AI agents can read and act on external content automatically?
- Why do browser agents remain vulnerable even when prompt injection controls are already in place?