Giving an AI agent an inbox is a delegation decision. The agent can now receive instructions from your team and content from everyone who can reach that inbox. Those are not the same source of authority, even if both arrive as text.
Indirect prompt injection exploits that gap. An instruction reaches the model through a resource controlled or influenced by somebody else, such as an email, document, website, code repository or tool output, rather than through the user’s direct prompt.[1][2] If the agent treats that content as an instruction, the important question is not only what it says. It is what the agent can do next.
For an owner or operations lead, the practical response is to reduce the blast radius. Separate permission to read, permission to draft and permission to execute. Put consequential decisions behind controls that do not depend on the model interpreting more natural language correctly.
The operating decision
External content can inform a draft. It should not silently acquire the authority to send, delete, publish, pay, change permissions or write to production.
The risk starts with ordinary external content
A malicious-looking message is easy to distrust. The harder case is an ordinary document containing quoted text, hidden instructions, stale policy language or a request that resembles an internal command. The content may be hostile, ambiguous or simply wrong. The architecture should not need to know which before it limits authority.
NIST defines indirect prompt injection by control of the resource carrying the instruction.[1] NIST’s agent-security work also frames agent hijacking around systems that process external sources including emails, websites and code repositories.[2] That makes the issue broader than a chat input filter.
Treat incoming material as untrusted data by default. The agent may summarise it or extract defined fields, but the material should not be able to rewrite policy, expand permissions or choose a sensitive tool just because it appears in context.
Direct and indirect injection require different boundaries
In a direct injection, a person tries to steer the agent during their interaction with it. In an indirect injection, the instruction is embedded in something the agent was asked to inspect. Blocking a suspicious user message does not cover a browser, attachment reader or SaaS connector.
The UK’s NCSC explains why the familiar SQL-injection analogy falls short: current language models do not enforce a robust security boundary between instructions and data combined in one prompt.[4] Better wording can help the model, but wording is not an access-control system.
This is why a single “trusted prompt” is the wrong unit of design. The useful boundary sits around data access, credentials, tools, destinations and approvals. It still works when the input changes.
Map authority before choosing the model
Start with the path an external item takes through the system:
external source -> untrusted content -> structured extraction -> deterministic policy -> read / draft / execute
Then map four operating facts around that path.
Source
Email, document, website or tool output. Who can alter what the agent receives?
Reach
Which private records, credentials and services are available at this step?
Authority
Can the agent read, prepare, send, delete or modify?
Recovery
Which independent rule blocks the action, and who can stop and resume the flow?
This map is deliberately separate from the knowledge base behind an AI agent. A knowledge-base review asks whether internal sources are current, owned and appropriately accessible. The trust-boundary review asks whether an external source can influence an action.
Separate read, draft and execute authority
The cleanest first control is often a functional split.
- Read lets the agent retrieve, classify or extract without changing a system.
- Draft lets it prepare a reply or proposed update while another component retains execution authority.
- Execute lets a narrowly scoped tool make an explicitly authorised change after its destination and parameters have been checked.
A useful pilot may stop at read and draft. The agent can inspect an email and prepare a response, but it cannot send the message, delete anything, publish content, make a payment, change a permission or update production. This does not make the draft correct. It limits the immediate consequence of a bad draft.
NCSC guidance ties safeguards to the degree of autonomy. It recommends scoped permissions and credentials, sandboxing, oversight, operational monitoring and the ability to halt autonomous activity.[3] ANSSI’s guidance also uses least privilege, compartmentalisation and defence in depth as principles to adapt to the system being built.[6]
Keep critical policy outside the model
A model can classify intent, extract fields and propose a next step. It should not be the only component deciding whether a consequential action is allowed.
A deterministic policy can check that the destination is approved, the requested capability is in scope, required fields are present and a valid approval exists. The tool itself can refuse every capability that was not granted. These checks remain legible when a message is phrased differently.
OpenAI’s safety guidance, which is vendor guidance rather than an independent standard, advises against placing untrusted variables in privileged instructions and recommends structured outputs to constrain how free text passes between steps.[7] Both can narrow exposure. Neither proves that an agent is secure. NCSC warns that built-in model safeguards may be bypassed or may not be sufficient on their own in higher-risk settings.[3]
Approval must reveal the exact consequence
An “Allow?” button is weak control if the reviewer cannot see what will change. A meaningful approval screen should show:
- the source that triggered the flow;
- the data used to prepare the action;
- the tool, destination and exact proposed change;
- any fields that will leave the organisation;
- options to edit, reject or escalate.
The broader human-review workflow determines where approval belongs. For indirect prompt injection, the narrower rule is simple: nobody should approve an action derived from external content without seeing that derivation and its consequence.
A second model that says “looks safe” is not equivalent to independent policy. It is another probabilistic component. It may support triage, but the hard boundary should still come from permissions, schemas, allowlists and tool behaviour.
Test hostile and ambiguous inputs without publishing attack recipes
A test set made entirely of clean emails and tidy documents proves very little. Include contradictory documents, quoted conversations, policy-like language inside attachments and requests that fall outside the approved scope. The aim is to test the boundary, not to circulate working bypasses or exfiltration instructions.
For each scenario, check whether the system:
- keeps external material in the untrusted-data lane;
- stays within read or draft permissions;
- requires approval before a consequential action;
- rejects an unapproved destination or capability;
- leaves a trace that explains why it stopped.
OWASP treats agentic-application risk as a distinct operating problem for systems that plan, act and make decisions across workflows.[5] Its framework can inform a test plan. It is not a certification, a compliance guarantee or evidence that a deployment is attack-proof.
Observe, stop and recover
No control layer removes all residual risk. Design the operating response before granting autonomy.
The minimum useful trace links the external source, extracted data, policy decision, human approval and executed action. A full AI agent observability design goes further, but this chain is what lets an operator answer: which outside resource influenced this proposal?
Shutdown must cover tools and communications, not only the model process. NCSC advises organisations to retain the ability to halt autonomous activity and rapidly restrict network access or related communications.[3] Recovery then needs a known state: reverse the action where possible, isolate the item, review affected credentials if needed, update the failing rule and only then resume.
The team should decide who owns that response. If the only person who can stop the agent is unavailable, the shutdown path is not operational.
The decision test before connection
Before connecting an agent to email, a browser or a business tool, confirm that the team can answer yes to each question:
- Is external content treated as untrusted in the architecture?
- Are read, draft and execute permissions separated?
- Does policy outside the model control sensitive actions?
- Does approval show the exact consequence?
- Do tools reject anything outside the declared scope?
- Can operators trace an action to its source, stop it and recover?
If one answer is missing, narrow the first scope. The AI support agent brief can capture the remaining product and operating requirements once this trust boundary is explicit.
Planning to connect an agent to email, documents or business tools? Last Word can scope the sources, authority, approvals and recovery path before the prototype. Explore our AI and automation services or send us the context.
FAQ
What is indirect prompt injection in an AI agent?
It is an instruction that reaches the model through a resource controlled or influenced by somebody else, such as an email, document, website or tool output.[1][2] It does not come directly from the person using the agent.
Should an agent be blocked from all external content?
No. It can read, classify or extract defined fields without gaining authority to act. The useful boundary separates read, draft and execute permissions.
Is human approval enough before execution?
No. The reviewer needs to see the source, destination and exact change, while the tool still enforces its own permissions, schema and scope.
What should a first connected-agent pilot be allowed to do?
Start with reading and drafting, without permission to send or modify anything. Add one narrowly defined action only when its destination, parameters, approval and shutdown path can all be checked.
Sources
[1] https://csrc.nist.gov/glossary/term/indirect_prompt_injection — NIST CSRC, indirect prompt injection, source NIST AI 100-2e2025, accessed 31 August 2026. [2] https://www.nist.gov/blogs/caisi-research-blog/insights-ai-agent-security-large-scale-red-teaming-competition — NIST CAISI, Insights into AI Agent Security from a Large-Scale Red-Teaming Competition, 23 March 2026, accessed 31 August 2026. [3] https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai — UK NCSC, Managing the cyber risk of agentic AI, published 20 August 2026 and updated 24 August 2026, accessed 31 August 2026. [4] https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection — UK NCSC, Prompt injection is not SQL injection (it may be worse), 8 December 2025, accessed 31 August 2026. [5] https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026 — OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, 9 December 2025, accessed 31 August 2026. [6] https://messervices.cyber.gouv.fr/documents-guides/Recommandations_de_s%C3%A9curit%C3%A9_pour_un_syst%C3%A8me_d_IA_g%C3%A9n%C3%A9rative.pdf — ANSSI, Security recommendations for a generative AI system, version 1.0 dated 29 April 2024, accessed 31 August 2026. [7] https://developers.openai.com/api/docs/guides/agent-builder-safety — OpenAI Developers, Safety in building agents, no publication date displayed, accessed 31 August 2026. Vendor guidance.