A user asks a routine question about a supplier agreement. Your application retrieves the agreement, attaches several relevant passages and sends them to a model. Buried in one passage is an instruction telling the model to ignore its operating rules, reveal confidential context or take an unauthorised action. That is the operational problem indirect injection defence must address.
The instruction did not come from the user interface, but it still reached the model's context window. Retrieval-augmented generation, web research, uploaded files, email summaries and tool results all create this route into an AI workflow. The more useful external context becomes, the more carefully its authority must be controlled.
How indirect injection reaches production systems
Indirect prompt injection happens when a model consumes content that appears to be data but also contains adversarial instructions. A malicious line in a knowledge-base article, a compromised web page or text returned by an external tool can attempt to alter the model's behaviour. Unlike a direct jailbreak, the user may have no intention of attacking the system at all.
This distinction matters for incident response. Blocking a suspicious user prompt does not protect a workflow that fetches untrusted material after the user has made a legitimate request. Security controls need to assess the complete request that is about to reach the provider, including the context assembled by your application.
Context is influence, not authority
LLMs are designed to interpret language. They do not inherently distinguish a trusted policy instruction from an untrusted paragraph with perfect consistency. Prompt hierarchy helps, but it is not a permission system and should not be treated as one.
The safer design is to keep authority outside the model context wherever possible. Application code should decide which data can be retrieved, which tools are available, what actions require approval and which identities may initiate a workflow. The model can propose an answer or a next step, but it should not acquire new privileges because a document told it to do so.
This is particularly relevant in workflows that combine retrieval and action. A support copilot may safely read an external article, while refunding an order or changing an account requires constrained application logic. A research agent may summarise a web page, while sending an email or exporting data should remain subject to separate controls.
The risk is not limited to malicious files
A document need not be deliberately hostile to create a problem. Old internal instructions, copied examples, templates containing phrases such as ignore previous guidance, or data from a third-party system can all conflict with the task. Attackers simply make that ambiguity purposeful and harder to spot.
For regulated teams, the impact extends beyond an incorrect answer. An indirect injection can contribute to confidential-data exposure, inappropriate tool use, policy breaches and weak evidence during an investigation. The question is therefore not whether every hostile phrase can be predicted. It is whether each request passes through controls that can enforce policy, limit exposure and leave an operational record.
Indirect injection defence needs a request-level control point
Application-side validation remains useful, especially where you know the business workflow. But it becomes difficult to maintain when several teams use different providers, models and AI features. Each integration can create a slightly different policy gap.
A governed gateway creates one control point between applications and model providers. At routeur.ai, every request follows a fixed sequence: prompt shield, then DLP, then routing, then output moderation. That order is deliberate. A request is screened for prompt-injection and jailbreak patterns before sensitive-data controls are applied, and before routing selects the appropriate provider and model. Generated output is moderated before it is returned.
No control can promise that an LLM will never encounter adversarial language. Effective defence is layered: reduce the chance of unsafe instructions progressing, minimise the sensitive data available to the request, constrain the actions around the model and inspect what happens when controls trigger.
Apply policy before provider selection
When teams connect directly to several providers, injection controls can drift. One application may use a carefully maintained wrapper, another may bypass it during an urgent release, and a third may log prompts differently. A request-level gateway applies the same policy boundary regardless of the provider ultimately selected.
This also avoids treating security and cost as competing projects. Routing rules and priorities can choose an appropriate capable model, while prompt shielding, DLP and output moderation remain part of the same governed request path. Automatic failover does not require teams to recreate safeguards for every provider integration.
Treat DLP as a containment control
Indirect injection can try to exploit data already supplied to the model. DLP reduces that exposure by identifying sensitive information in the request and applying the configured action: log, warn, redact or block. Where redaction is configured, the value sent onwards is replaced with [REDACTED].
This is not a substitute for access control. It does not make it acceptable to retrieve broad datasets into a prompt. It does, however, provide a practical containment layer when an application includes personal or confidential information that should not leave the governed boundary in its original form.
Output moderation provides a second boundary on the response. It can help prevent harmful or policy-breaking material from reaching the user, but it should not be mistaken for authorisation of downstream actions. If a response can trigger a financial, administrative or data-access outcome, the application should validate the intent and enforce its own permissions.
Design retrieval and tool workflows for low authority
The most reliable mitigation begins before a request reaches any model. Separate content by trust level, and give the workflow only the minimum context required for the task. A public web result and an approved internal policy document should not automatically have equal influence.
For retrieval, preserve source information in your application even if the model receives selected excerpts. Set clear inclusion rules for repositories, document owners and recency. Review indexed content for instructions that look like operational commands rather than reference material. If a source cannot be trusted, use it as evidence to be checked rather than as a basis for action.
Tool results deserve the same treatment. External systems can return text that has been manipulated by a user, supplier or attacker. Keep tool permissions narrow, avoid granting write access merely because read access is useful, and require explicit application-side checks before consequential actions.
A helpful architecture question is: if this retrieved paragraph were malicious, what could the model actually do with it? If the answer includes seeing customer records, changing permissions, making payments or transmitting data externally, the workflow needs tighter boundaries. The solution may be an approval step, an allow-listed operation, reduced context or a redesign that moves the decision into deterministic code.
Make defence observable without retaining every prompt
Security controls are only useful if engineering and compliance teams can understand their effect. Per-request traces support investigation of how a request was handled, while metadata-only logging by default reduces unnecessary payload retention. Payload retention is an explicit opt-in decision, which matters when prompts may contain customer or employee data.
There is a trade-off. Metadata-only records are better aligned with data minimisation, but they may not provide the full prompt needed to reproduce a complex incident. Teams should decide in advance which authorised workflows justify opt-in payload retention, for how long and under whose access controls. That decision belongs in the operating model, not in a hurried post-incident response.
Scoped API keys and named routes further reduce ambiguity. They allow teams to separate workloads and apply the intended routing and policy configuration without embedding provider credentials across every service. Hard spend caps add another practical boundary: when a cap is reached, requests can be blocked with a 429 rather than allowed to create uncontrolled usage while an incident is investigated.
Test the workflow attackers will actually use
Do not assess indirect injection defence only with a single prompt in a playground. Test the complete path from content ingestion to final action. Include a harmless test document that instructs the model to disclose hidden context, ignore application rules or call an inappropriate tool, then verify that the workflow fails safely.
Test several conditions: a malicious instruction in a retrieved document, a suspicious instruction returned by a connected tool, sensitive data adjacent to that instruction, and an output that attempts to persuade a user to take an unsafe action. Record which controls triggered, what data was redacted or blocked, and whether the application still delivered a useful outcome for the legitimate request.
The goal is not a perfect score against a static test set. Models, provider behaviour, connected systems and attack patterns change. Run these tests when retrieval sources expand, tools gain new permissions, models change or routes are updated. Per-request traces and audit trails then give teams evidence to improve policy rather than relying on assumptions.
Indirect injection defence becomes practical when it is part of the request path, not an optional wrapper around selected applications. Give untrusted content as little authority as possible, enforce controls before it reaches a provider, and keep enough evidence to answer a simple but decisive question after every incident: what was allowed to influence the model, and what was it allowed to do?