Prompt Injection Defense for RAG and Tool-Using AI Agents

Prompt injection is often described as a clever sentence that tricks a model. That framing is too small for modern AI systems. When an assistant retrieves documents, browses webpages, reads email, or controls a computer, untrusted content can influence a system that has real capabilities. The risk is not that the model misunderstood a prompt in isolation. The risk is that application data was allowed to compete with policy and then direct a sensitive tool. No single prompt can solve this. A durable defense combines data and instruction separation, least-privilege tools, authorization outside the model, output validation, sandboxing, monitoring, and human approval for high-impact actions. As agent platforms make longer-running workflows easier to build, teams that ignore injection will eventually debug a data exfiltration or unauthorized action under pressure. ## Model the attack path Write down the flow from user input to final side effect. Identify where untrusted text enters: user messages, retrieved documents, search snippets, webpages, emails, file metadata, OCR, tool output, and previous agent memory. Then list what the system can do after reading that content. An instruction inside a public webpage is a low-impact nuisance for a summarizer but a serious risk if the same agent can send email or access internal URLs. Separate direct prompt attacks from indirect injection. Direct injection comes from the user asking the agent to ignore policy. Indirect injection arrives through content the system chose to retrieve. Test both. Also test encoded instructions, long distracting text, fake system messages, and content that asks the agent to reveal hidden context. ## Keep policy outside retrieved content Make the hierarchy clear in the application. System policy and tool permissions should be established by trusted code and identity context. Retrieved content should be labeled as reference data. The agent may summarize it, quote it, or identify it as suspicious; it must not let it expand permissions or redefine the task. Do not concatenate arbitrary documents into one undifferentiated string. Preserve source IDs, trust labels, tenant boundaries, and content type. Limit retrieval to approved sources for the workflow. Filter by user authorization before the model sees a document, not after it drafts an answer. ## Make tools narrow and independently authorized A tool should perform one controlled operation. Prefer `create_draft` over `execute_any_command`, `get_order_status` over `run_sql`, and `search_approved_docs` over `browse_the_network`. Validate arguments and authorization in backend code. Derive identity and tenant context from the session. Treat model-generated recipients, file paths, URLs, and amounts as untrusted input. For write actions, require a policy check and approval. Show the proposed action and evidence to a human when the impact is meaningful. Use idempotency keys, rate limits, transaction bounds, and reversible operations. A prompt-injected agent should be able to fail safely, not demonstrate how much it can do. ## Use staged processing for sensitive tasks A useful pattern is to separate ingestion, extraction, planning, policy review, and execution. The ingestion step can identify suspicious content. The extraction step can return structured facts without permission to act. The planner can propose a tool call. The policy layer can reject disallowed operations. The executor can act only when identity, scope, and approval are valid. This is not perfect isolation, but it reduces the chance that one context controls the entire chain. Keep sensitive secrets out of model context whenever possible. The model should receive a capability handle or a redacted result, not a raw credential or a complete customer database. ## Detect and respond Log suspicious instructions, tool denials, unusual retrieval paths, large exports, and attempts to access unexpected domains. Do not log secrets or unrestricted personal content. Alert on behavior, not only keywords: a sudden request to enumerate records, repeated policy failures, or a model trying to use a tool outside the workflow is meaningful. Add injection cases to the evaluation suite and turn real incidents into redacted regression tests. Train reviewers to recognize a safe stop. A system that pauses and explains that a source contained an unrelated instruction is working as designed. A system that silently follows it is not. Prompt injection will keep evolving because it exploits the boundary between language and action. The answer is engineering discipline around that boundary. Treat external text as hostile data, keep permissions independent, validate every action, and make high-impact work reviewable. The sooner these controls become normal, the less likely an AI growth project becomes a security emergency.