How do you prevent prompt injection in AI agents?
Prompt injection protection for AI agents requires more than detecting malicious strings. Agents need source-to-sink controls that prevent untrusted context from authorizing tool calls, memory writes, data exports, browser actions, approvals, or other side effects. The safest approach is to label context by provenance, treat external content as evidence rather than instruction, inspect actions before execution, and log every policy decision for replay.
- Direct injection comes from the user; indirect injection comes from documents, web pages, tool output, and MCP responses.
- Prompt filters catch obvious strings but miss benign-looking context that carries authority.
- Source-to-sink controls stop untrusted context from driving privileged actions.
- Keep an exploit replay as a regression test after every change.
Direct vs indirect prompt injection
Direct injection is a hostile user prompt. Indirect injection hides instructions in content the agent reads — a retrieved document, a web page, a ticket, an email, or a tool result. Indirect injection is the harder problem because the malicious text never comes from the user.
Why prompt filters fail on agents
A filter asks whether text looks malicious. Once an agent can act, a perfectly normal-looking runbook or tool result can still steer a tool call or export. The control that matters is whether that source is allowed to influence that sink — see context firewall vs prompt filter.
The controls that actually help
Label context by provenance and trust; treat retrieved and tool-derived content as evidence, not instruction; inspect tool calls before execution; gate memory writes; apply egress DLP; and require authenticated approval for high-risk actions. Related: RAG poisoning and agentic AI red teaming.