Indirect prompt injection is what happens when an AI system reads hostile instructions hidden in ordinary-looking content—an email, document, ticket, webpage or image—and treats those instructions as part of its job. The operational answer is not a better warning in the system prompt. If the agent can call tools, the control objective is to stop untrusted content from turning into an unauthorised action. That requires bounded permissions, deterministic policy checks, meaningful approvals, logging and a tested stop path.
This matters as organisations connect AI to inboxes, document stores, service desks, CRMs and finance systems. A chatbot that is manipulated may produce a bad answer. A manipulated agent with write access may send a message, change a record, retrieve sensitive data or trigger a downstream workflow.
Australia's ACSC and five partner cyber agencies now make the escalation clear: external data sources such as web search can introduce indirect prompt injection, while connected tools and broader infrastructure access increase what an attacker may be able to achieve.
Source: Careful adoption of agentic AI services, co-authored by ASD's ACSC, CISA, NSA and the Canadian, New Zealand and United Kingdom cyber security agencies.
What is indirect prompt injection?
Direct prompt injection comes from the person interacting with the AI. Indirect prompt injection arrives through material the AI is asked to process. A malicious instruction might be embedded in a supplier email, a support ticket, a PDF, a retrieved knowledge-base page or text that is visually hidden on a website.
The model does not reliably enforce the boundary a business assumes exists between its instructions and external data. OWASP therefore treats prompt injection as the leading risk in its 2025 list for large language model applications. It notes that retrieval-augmented generation and fine-tuning do not fully remove the vulnerability, and that impact depends heavily on the business context and the agency given to the system.
Source: OWASP LLM01:2025 Prompt Injection.
Consider an email-triage agent. Its legitimate task is to read incoming mail, classify it and prepare a response. An attacker places an instruction in an email telling the agent to ignore its normal job, retrieve a confidential attachment and send it elsewhere. The email is data to the business, but it is also text inside the model's context. If the same agent can read sensitive files and send messages without an independent control, the attack path is already present.
The ACSC guidance uses a comparable scenario: a malicious prompt in a phishing email convinces an email-monitoring agent to download malware. The point is not that every agent will follow such an instruction. The point is that the workflow must remain safe when the model is confused.
Why a prompt filter is not a sufficient control
Prompt screening can reduce obvious attacks, but it should not carry the full security burden. Attack instructions can be obfuscated, split across inputs, translated, encoded or placed in images. Legitimate content can also resemble an attack. A filter must operate in a changing, probabilistic environment rather than enforce a clean code-and-data boundary.
The UK National Cyber Security Centre argues that prompt injection should not be treated like SQL injection. Parameterised queries can create a robust separation between SQL instructions and data. Current language models do not offer the same dependable distinction inside a prompt. The NCSC recommends designing around an "inherently confusable" component and using deterministic safeguards to constrain what the wider system can do.
Source: UK NCSC, Prompt injection is not SQL injection (it may be worse), 8 December 2025.
This changes the buyer question. Do not ask only, "Can the platform detect prompt injection?" Ask, "What can happen if detection fails?" The answer should be visible in permissions, tool policy, approval rules, egress controls and incident procedures—not left to a model instruction.
NIST's adversarial machine-learning taxonomy reinforces the need to manage attacks and their consequences across the AI lifecycle, while recognising open challenges rather than presenting one defensive technique as complete.
Source: NIST, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, 4 January 2024.
What controls should surround an agent that reads untrusted content?
The strongest design assumes the model may be influenced and limits the resulting blast radius. For each workflow, put six controls around the action path.
| Control | Practical requirement | Evidence to retain |
|---|---|---|
| Trust boundary | Label external emails, files, webpages and retrieved records as untrusted inputs | Input source, classification and retrieval path |
| Least privilege | Give the agent only the data and tools required for its defined job | Agent identity, allowed tools and scoped permissions |
| Deterministic policy | Check every consequential tool call outside the model | Policy verdict, parameters, time and agent identity |
| Human approval | Require a reviewer for sensitive, irreversible or external actions | Proposed action, reviewer, decision and executed result |
| Egress control | Restrict where data, files and messages can be sent | Destination allowlist and blocked attempts |
| Monitoring and recovery | Record tool use, detect abnormal behaviour and provide a kill switch | Trace, alerts, incident owner and revocation record |
OWASP recommends the same broad defence-in-depth direction: constrain model behaviour, validate outputs, filter inputs and outputs, enforce least privilege, require human approval for high-risk actions, identify external content and conduct adversarial testing. Importantly, these measures reduce likelihood and impact; they do not justify unlimited access.
Source: OWASP LLM01:2025 Prompt Injection—Prevention and Mitigation Strategies.
The ACSC guidance goes further for agentic systems. It recommends never granting broad or unrestricted access, using distinct agent identities, checking authorisation at runtime, applying short-lived credentials for privileged actions, maintaining human interruption and approval controls, and keeping human-readable logs of tool results.
Source: Careful adoption of agentic AI services.
How should a team test the workflow before launch?
Testing should follow the information routes the live agent will actually use. A generic chatbot red-team is not enough if the production workflow reads supplier PDFs and then updates a procurement system.
Start with a compact scenario set:
- Put an obvious hostile instruction in each external input channel.
- Repeat with hidden, encoded, multilingual and image-based instructions where the system supports those formats.
- Ask the model to call an allowed tool with disallowed parameters or destination values.
- Test whether a low-risk read step can quietly lead to a higher-risk write step.
- Confirm approvals show the exact proposed action and enough source context for a reviewer to make a real decision.
- Revoke the agent's credentials and exercise the kill switch.
- Reconstruct the event from logs without relying on the agent's own summary.
Record the result as an operational test: scenario, expected control, observed behaviour, severity, owner and remediation date. Re-run the set whenever the model, prompt, connected tools, permissions or source data changes.
Research from Google DeepMind and ETH Zurich supports this architecture-first view. Its CaMeL design separates control flow from untrusted data and uses capability controls to constrain what actions can be taken. It is a research architecture, not a drop-in guarantee, but the operational principle is useful: do not make model compliance the only barrier between hostile content and a privileged action.
Source: Debenedetti et al., Defeating Prompt Injections by Design, 2025.
When is the workflow ready for broader access?
An agent is not ready because it passed a demo. Broader access should be earned through evidence from a bounded workflow.
Expansion is reasonable when the organisation can show that:
- the agent has a named business owner and a narrow purpose;
- untrusted inputs and consequential actions are explicitly mapped;
- permissions are scoped to the current task rather than inherited broadly;
- sensitive actions are blocked or routed to meaningful approval;
- policy checks and logs sit outside the model;
- exceptions have an owner and response time;
- the team has tested injection scenarios, credential revocation and rollback; and
- performance is measured against accepted business outcomes, not activity alone.
If those conditions are missing, keep the workflow read-only or in draft-and-review mode. That still allows useful implementation while the operating controls mature.
Turn the threat model into an operating model
Prompt injection is not only a security-team topic. Operations owns the workflow, IT owns much of the access path, security helps define controls, and a business reviewer may own the final decision. Production-safe automation depends on those roles working as one operating model.
Rettare's Agent Ops approach makes that model concrete: named ownership, bounded tools, approval gates, logs, fallbacks and controlled rollout around a real workflow. A practical first step is to choose one process that reads external content, map every possible action, and test what happens when the content cannot be trusted.
References
- ASD's Australian Cyber Security Centre and international partners, Careful adoption of agentic AI services
- OWASP GenAI Security Project, LLM01:2025 Prompt Injection
- UK National Cyber Security Centre, Prompt injection is not SQL injection (it may be worse), 8 December 2025
- National Institute of Standards and Technology, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, 4 January 2024
- Debenedetti et al., Defeating Prompt Injections by Design, 2025