Indirect Prompt Injection Defense for AI Agents: A Practical Trust-Boundary Playbook

How to keep web pages, documents, emails, retrieval results, and MCP metadata from quietly becoming instructions for an agent with real-world access.

AI agents become useful when they can read beyond the chat window. A support agent may inspect a ticket, a research agent may browse a site, and an operations agent may query a database through MCP. The same capability creates a security boundary that is easy to miss: external content can contain text that looks like an instruction.

An attacker does not always need to send a malicious message directly to the model. They may place instructions in a document, a web page, an email, an image, a repository file, or an MCP tool description. If the agent interprets that content as authority, the content can influence the next tool call. OWASP classifies this risk as prompt injection and distinguishes direct injection from indirect injection through external sources [1].

This guide is for developers, small teams, founders, and security-minded operators building RAG or tool-using agents. It focuses on architecture and operating controls rather than on a promise that prompt injection can be eliminated.

What indirect prompt injection means

A prompt injection occurs when input changes an LLM’s behavior or output in an unintended way. In a direct injection, the attacker places the instruction in the user’s message. In an indirect injection, the model receives the instruction through content it was asked to process, such as a page, file, email, or retrieval result [1].

The important distinction is not whether the text is visible to a human. The model may process hidden, obfuscated, or metadata-based content that a user does not notice. Multimodal systems also expand the input surface because instructions can be embedded in images or documents, not only in ordinary text [2].

Why tool access changes the risk

A text-only assistant may produce a wrong answer. An agent with authority can turn a wrong interpretation into a side effect. It might create a record, send an email, modify a file, call an external API, or delegate work to another agent. The impact therefore depends on both the injection and the agent’s agency.

Microsoft describes tool poisoning in MCP as malicious instructions placed in tool metadata that influence how a model selects and uses tools. A further risk exists when a hosted tool definition changes after a user approved it, sometimes described as a “rug pull” [4]. The practical lesson is simple: tool approval should cover the tool’s current identity, capabilities, parameters, and version, not merely a friendly tool name.

Prompt injection is a model-input problem, but the safest controls sit outside the model. The application should decide whether an action is allowed. The model may propose an action; it should not be the final authority for a privileged side effect.

The trust-boundary design

Use four explicit zones in the request path. The names are less important than the separation.

1. Trusted instructions. Keep system policy, user intent, identity, and allowed capabilities in a controlled application layer. Do not concatenate them casually with retrieved text.
2. Untrusted content. Mark web pages, files, emails, search results, retrieval chunks, tool descriptions, and tool outputs as data to inspect. Delimit and label them consistently.
3. Decision layer. Validate the model’s structured proposal against the original request, the user’s permissions, resource scope, argument schema, rate limits, and risk policy.
4. Execution layer. Execute only after the decision layer permits the action. The tool wrapper should authenticate, authorize, validate, and log independently of the model.

A practical defense workflow for a small team

1. Inventory every path into the context

Write down every source the agent can read. Include obvious sources such as user messages and retrieved documents, but also include tool descriptions, API responses, browser DOM content, file metadata, OCR text, memory, and other agents’ messages. Classify each source as trusted, user-controlled, third-party, or unknown.

This inventory often reveals a hidden assumption: a team may protect the initial prompt while allowing a tool response to flow into the next model turn without labeling or filtering. The model does not automatically know which text is authoritative.

2. Separate data from instructions

Use a structured message or object with named fields. Keep the original user goal separate from retrieved content. Add a clear policy that content in the data field is for analysis and cannot change permissions, identities, or tool policy.

request = {
  trusted: {
    user_intent: "Summarize the customer ticket",
    allowed_actions: ["read_ticket", "draft_reply"],
    session_identity: "support-agent-readonly"
  },
  untrusted: {
    source_type: "customer_ticket",
    source_id: ticket_id,
    content: ticket_text
  }
}

proposal = model.analyze(request)
policy.evaluate(proposal, request.trusted)

This pattern improves clarity, but it does not make the model infallible. Treat the structure as one layer in a defense-in-depth design.

3. Reduce authority before improving intelligence

Start with read-only access. Separate reading a record from changing it. Separate drafting a message from sending it. Use narrow identities, resource-scoped permissions, short-lived credentials, and explicit limits. PromptSphere’s least-privilege tool permissions checklist provides a complementary permission model.

Least privilege does not stop an injection from influencing the model. It limits the damage when the model is influenced.

4. Gate proposed actions outside the model

Every tool call should pass through a broker or policy wrapper. Check the authenticated principal, tool identifier, argument schema, resource scope, original user intent, policy version, and risk tier. Re-check the arguments after approval and immediately before execution.

5. Treat MCP definitions and outputs as change-controlled inputs

For MCP servers, record the server identity, tool name, description, input schema, declared side effects, version or digest, and approval status. Alert when a definition changes. Review the current definition rather than trusting an earlier approval forever.

Follow the official MCP security best practices for authorization-related controls such as exact redirect URI validation, state validation, per-client consent, and avoiding unsafe token passthrough. These controls address protocol and authorization boundaries; they complement, rather than replace, prompt-injection defenses.

6. Add input, output, and action monitoring

Pattern matching can catch obvious phrases such as requests to reveal a system prompt, but it will miss novel wording and may flag legitimate content. Use deterministic checks for formats, lengths, encodings, destinations, and argument ranges. Consider a separate classifier for suspicious content when the risk justifies the cost. OWASP recommends combining filtering, structured separation, output validation, least privilege, human approval, and adversarial testing [2].

For agent actions, the strongest monitoring question is not only “Does this text look malicious?” It is “Does this proposed action match the user’s original goal and current permissions?” A benign-looking instruction can still be dangerous if it redirects an action to a new recipient or resource.

7. Preserve evidence without collecting unnecessary secrets

Log the request identifier, authenticated identity, source classification, tool and version, argument hash or redacted arguments, policy version, decision, approval, execution result, and timestamps. Protect the logs because they may contain sensitive content. PromptSphere’s AI agent tool-call auditing guide covers the evidence chain in more detail.

Testing: prove that the boundary holds

Do not test only whether the model refuses the phrase “ignore previous instructions.” Test whether an untrusted source can cause an unauthorized side effect. Build a small regression set with normal, ambiguous, adversarial, and malformed inputs.

• Place an instruction in a retrieved document that requests a secret.
• Place a different instruction in a web page that changes the requested recipient.
• Modify an MCP tool description and verify that the change triggers review.
• Return a forged tool observation and verify that the agent does not treat it as policy.
• Change a tool argument after approval and verify that the approval is invalidated.
• Simulate a timeout and retry, then confirm that idempotency prevents duplicate side effects.
• Disable the policy service and confirm that high-risk actions fail closed.
• Check that logs contain the decision path while redacting secrets.

Use a sandbox or test tenant for these cases. Keep the test prompts and expected decisions under version control. When the agent, model, tool schema, retrieval pipeline, or policy changes, rerun the suite.

What does not work by itself

A longer system prompt

Clear instructions help the model understand the intended role. They do not create a hard boundary around untrusted content, and they cannot independently enforce authorization.

Regex filtering alone

Rules can catch known patterns and dangerous destinations. They are brittle against paraphrases, encoding, multilingual content, and context-dependent attacks. They are useful as a cheap layer, not as the complete security design.

RAG or fine-tuning as a complete fix

Retrieval can improve relevance, and fine-tuning can shape behavior. OWASP notes that neither should be treated as a complete mitigation for prompt injection [1]. A poisoned source can still influence a system that lacks source trust, action validation, and least privilege.

Human approval for everything

Approval queues can reduce risk for high-impact actions, but people may approve too quickly if the interface hides the source and arguments. Show the exact action, resource, recipient, relevant untrusted content, and reason for the decision. Use automation for low-risk reads and careful approval for consequential writes.

A compact operating checklist

• Every external source is classified as untrusted unless explicitly verified.
• Trusted user intent is stored separately from retrieved or fetched content.
• Tool calls are structured, schema-validated, and checked outside the model.
• Permissions are scoped to the minimum identity, resource, and operation required.
• High-impact actions require a meaningful approval or an equivalent deterministic policy.
• MCP server and tool-definition changes are visible and reviewable.
• Outputs are checked before they become inputs to another privileged step.
• Audit records connect identity, intent, source, proposal, decision, approval, and outcome.
• Adversarial regression tests run after changes to models, prompts, tools, retrieval, or policy.
• There is a containment and recovery plan. See PromptSphere’s AI agent rollback plan for a release-level recovery workflow.

Conclusion

Indirect prompt injection is best understood as a trust-boundary failure. External content can be useful without being authoritative. The secure design keeps that distinction visible: label untrusted inputs, isolate instructions, reduce permissions, validate action proposals outside the model, require approval where the side effect warrants it, and preserve evidence.

Start with one workflow rather than attempting to secure every agent at once. Inventory its inputs, make its tools read-only where possible, add a policy gate, create five adversarial tests, and inspect the logs. Then expand the same controls to other agents and MCP connections. This approach will not make prompt injection disappear, but it can make the resulting system more bounded, reviewable, and recoverable.

FAQ

Can prompt injection be prevented completely?

No complete prevention guarantee should be made. OWASP describes prompt injection as a risk arising from how generative models process inputs and recommends layered mitigation rather than a single fool-proof control [1]. The engineering goal is to reduce likelihood and limit impact.

Is indirect injection the same as MCP tool poisoning?

Tool poisoning is a specific MCP-related form of indirect injection in which malicious instructions appear in tool metadata or related tool content. Indirect injection is broader and also includes web pages, files, email, RAG content, images, and tool outputs.

Should every retrieved chunk be blocked if it contains instructions?

Not necessarily. A document may legitimately describe instructions, such as a software manual. The application should distinguish “instructions described as content” from “instructions that can change the agent’s authority.” Keep the chunk untrusted, ask the model to quote or summarize it, and prevent it from changing policy or triggering privileged actions.

Where should a human approval step sit?

Place it after the agent proposes a structured action and before the side effect executes. The reviewer should see the identity, tool, arguments, destination, risk reason, and relevant source context. Revalidate the action after approval so an argument change cannot silently reuse an old approval.

Sources

1. OWASP Gen AI Security Project: LLM01:2025 Prompt Injection .
2. OWASP Cheat Sheet: LLM Prompt Injection Prevention .
3. Model Context Protocol: Security Best Practices .
4. Microsoft Developer Blog: Protecting against indirect prompt injection attacks in MCP .
5. NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile .

Editorial note: This article provides general engineering guidance. Security controls should be adapted and tested for the actual models, identity system, data sensitivity, tools, and legal or regulatory context of each deployment.