The goal is not to detect every malicious instruction. It is to prevent external content from silently reaching a dangerous capability.
Indirect prompt injection becomes dangerous when untrusted content can steer an agent toward a sensitive capability. An email, web page, shared document or tool result may contain an instruction that the model mistakes for the legitimate request. If the same agent can read confidential data, send a message, change a record or initiate a payment, an interpretation failure becomes a business incident.
The answer is not to look for a perfect filter. It is to break the chain between an influenceable source and a dangerous action. External content stays labeled as data, model output remains a proposal, authorization is decided by a deterministic control and the tool executes only a bounded capability. This architecture limits impact even when a malicious instruction is not detected.
The risk begins when a source can reach an action
A direct injection comes from the person interacting with the model. An indirect injection is placed in a source the agent consults to complete a task: hidden text on a page, an instruction in an attachment, a comment in a ticket or content returned by a connector. OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications and notes that retrieval-augmented generation or fine-tuning does not eliminate the risk.
Exposure alone does not determine severity. An agent that summarizes a public document inside an isolated environment may produce a poor summary, but its blast radius remains limited. The same content becomes far more dangerous if the agent can also access an internal mailbox and call an external URL. The attack then combines a third-party-controlled source with a sink capable of creating an effect.
OpenAI described this logic in March 2026 through source-sink analysis. The operational goal is no longer limited to recognizing a hostile string. It is to prevent untrusted content from silently causing sensitive transmission or action. The threat model for an autonomous team should therefore connect every content origin to the capabilities it could indirectly reach.
A filter is not a security boundary
An injection classifier, system instruction and model training are useful. They can stop known attacks, reduce errors and provide signals for supervision. They remain probabilistic, however: malicious content may resemble a normal business request, use several languages, be split across documents or rely on contextual persuasion instead of an explicit command.
That limitation changes the filter's role. It becomes a detection layer that raises or lowers confidence, not the authority that decides whether an action can execute. A high-risk alert may block a case, while a low-risk score must never be enough to authorize a payment, external transmission or deletion. No detection is not proof of safety.
Trusted-domain lists have a comparable limit. A seemingly legitimate address may redirect to another destination, and a URL can carry sensitive data in its parameters. In January 2026, OpenAI documented a protection designed specifically for automatic URL retrieval: the complete address is checked against an independent public index, then an unverified address is blocked or requires confirmation. This guarantee addresses one exfiltration path, not the general trustworthiness of the content retrieved.
Defense becomes credible when multiple layers have different responsibilities. The model gets better at distinguishing instructions from data. A filter identifies suspicious patterns. An output schema constrains the proposal. A policy engine checks authority. A tool broker limits the real effect. Monitoring and adversarial testing then measure which paths remain open.
Build a containment chain to the business system
The strongest design starts with the system that executes the action and works backward toward the sources. For each capability, the team asks which data can influence it, which identity invokes it, which object it changes and which evidence confirms the intent. The following diagram is an illustrative architecture, not an announced Atlensia feature.
Atlensia diagram: external content may inform a plan, but only a deterministic control can authorize a bounded business capability.
The critical break sits between planning and authorization. A model may propose “send this response to the supplier,” but that sentence is never passed directly to a messaging API. It becomes a structured object that identifies the recipient, case reference, data category, message template and identity on whose behalf the send is requested. The policy check can then approve, request human review or reject against explicit criteria.
A second break sits between authorization and the tool. Instead of giving the agent a broad token, a broker issues a short-lived capability for one action on one object. The business system checks that capability again, applies its own validation and records the actual effect. If context is ambiguous, a required field is missing or the destination violates policy, the task enters quarantine under an identifiable human owner.
Reduce context before it can influence the plan
Separating instructions from data does not mean deleting all external text. A support agent must read a customer's message, and a procurement agent must analyze a supplier offer. The relevant question is which representation enters the reasoning context and which material remains available only as retrievable evidence.
The first step preserves provenance: source, apparent author, channel, timestamp, document identifier and sensitivity level. A second step extracts expected facts into a schema defined by the process. The original text remains connected to the case, but it is not indiscriminately merged with system rules and user instructions. A sentence in an invoice cannot become a new payment policy merely because it appears in the same model context.
Structured extraction does not make content true. It makes the claim inspectable. “Bank account changed” becomes a field with a source, while “pay the next invoice immediately” remains non-authoritative text. The process can verify the change through an approved channel instead of allowing the agent to infer that a document instruction is an authorization.
This discipline reinforces the distinction among API, workflow and MCP connections for autonomous teams. A connection protocol describes how a resource or tool is exposed. It does not automatically decide whether returned content is trustworthy or whether the agent has business authority to act on it.
Model output remains an untrusted proposal
An application makes a common mistake when it carefully validates inputs and then directly executes generated text. The output may reflect a successful injection, a hallucination or a benign ambiguity. OWASP treats this separately as improper output handling: generated content must not become an executable command, query, path or message without validation appropriate to the destination.
Narrow output contracts provide the practical answer. An agent preparing a CRM update can return an intent, record identifier, proposed fields, supporting references and uncertainty level. Deterministic code checks types, allowed fields, formats, destinations and business rules. The system rejects additional properties instead of passing them through for convenience.
The policy engine should not ask the same model whether its own proposal is safe. It combines known attributes: user identity, agent role, mandate scope, data classification, destination, potential amount, reversibility and recorded approval. This separation prevents the instruction that manipulates the plan from manipulating the control intended to stop it.
Human confirmation is useful only when it displays the actual effect. “Allow the agent to continue?” asks the reviewer to trust opaque reasoning. “Send fields A and B from case 184 to partner.example on behalf of procurement?” lets the reviewer inspect destination, data and identity. Confirmation should occur close to execution and expire whenever the proposal changes.
Identity and permissions determine the blast radius
Prompt injection does not create permission out of nothing. It exploits permissions the application has already placed within the model's reach. OWASP describes excessive agency as a combination of excessive functionality, excessive permissions or autonomy without independent control. Risk reduction therefore starts by removing unnecessary capabilities, not adding another sentence to the system prompt.
Each agent or process stage should use a distinct identity with the minimum required rights. A reading task does not need a send function. An agent preparing a draft cannot publish it. An invoice analysis does not inherit a payment permission. Sensitive operations use short-lived credentials bound to the user or role delegating the work so the downstream system can enforce its own rules.
In February 2026, the NIST National Cybersecurity Center of Excellence published a draft concept paper on identity and authorization for software and AI agents. Its immediate value for enterprise architecture is not a finished implementation recipe but the problem it frames: agents that act across systems need identities, policies and authorization mechanisms those systems can interpret. A permanent shared key makes that chain much harder to govern.
The complete approach extends the framework for securing autonomous team access. In indirect prompt injection, least privilege also serves as containment. Even if the model follows a hostile instruction, the capability available to it should not cross the defined business boundary.
Choose controls according to the sink
Different effects justify different levels of friction. Requiring human approval before every read would make the system unusable; automatically allowing every write would make incidents too easy. The decision should start from the sink, the sensitivity of the data and how difficult the effect is to reverse.
| Sink | Possible effect | Minimum control before execution | Appropriate human involvement |
|---|---|---|---|
| Read a public page | Manipulated content enters context | Provenance, isolation, size limit and filtering | No, unless scope changes or an alert fires |
| Read an internal document | Sensitive data exposure | Read-only identity, access check and reference log | Depends on case classification |
| Prepare a draft | Incorrect content with no external effect | Output schema, isolated workspace and draft status | Review before sensitive use |
| Send an external message | Disclosure or unintended commitment | Approved recipient, exact preview and one-use capability | Yes for a new destination or sensitive data |
| Update a business record | Corruption of a system of record | Field allowlist, version check and change history | For critical fields or conflicts |
| Retrieve a URL | Silent exfiltration through the address | Full URL, destination and outbound-data validation | If the address is unverified |
| Initiate a financial operation | Loss or fraud | Separation of duties, threshold, approval and downstream checks | Always according to financial policy |
| Delete or publish | Hard-to-reverse effect | Deny by default, precise scope and recovery mechanism | Yes before the real effect |
This grid is not a universal policy. A CRM update may be routine for an internal work-status field and critical for consent or contractual information. The matrix must be adapted by the process owner and then tested with the same objects, identities and destinations used in production.
Reversibility is an especially useful criterion. A proposal stored as a draft can be reviewed without urgency. A sent email, external publication or payment requires a stronger gate because the company cannot simply erase its consequences. The less reversible the effect, the more independent authorization should be from model reasoning.
Test the complete path, not only the model
A useful security test starts with a controlled source and ends at the sink. The team places adversarial instructions in the channels the deployed agent actually reads: email, document, page, search result or tool response. It then observes whether content crosses extraction, changes the plan, alters the structured proposal, obtains authorization and reaches the business system.
This method distinguishes detected attempts from contained impact. A filter may miss an instruction while the policy engine still blocks the action. Conversely, a model may refuse the attack during a test while an excessive permission remains exposed. Monitoring should therefore cover destination changes, privilege requests, unexpected fields, denied calls, approvals and confirmed effects in the system of record.
Scenarios should also include non-malicious ambiguity. An old email may contain an obsolete instruction; a copied document may mix data with procedures; another agent may return text that reads like a command. A control design that handles only obvious attacks can still fail on ordinary provenance and ownership errors.
The team finally tests recovery. A denied action returns to an owner, a capability expires, a retry does not duplicate an effect and an alert preserves the references needed for analysis. Robustness is not measured only by how many injections are recognized. It is also the system's ability to remain within bounds when recognition fails.
Adapt containment to the business scenario
In customer support, inbound messages are necessary but untrusted. The agent can extract the reason, order references and requested outcome, then consult systems with a read identity. A refund or external response passes through policies for amount, recipient and case; pressure expressed in the message changes neither the threshold nor the authority.
In procurement and finance, supplier documents may inform matching without dictating action. A bank-detail change triggers verification through an approved channel. Preparation remains automatable, while master-data changes and payments retain separate identities and approvals.
In research work, an agent can explore more public sources because its main sink is a synthesis. It should still cite references, distinguish facts from instructions encountered and avoid carrying the same access as an agent that sends or modifies. If the research later feeds a decision, the transfer carries structured evidence rather than an instruction copied from the web.
Conclusion
Indirect prompt injection is not a defect that can be eliminated once and forgotten. It is manipulation risk in a system where external content influences a component capable of acting. Effective defense accepts that uncertainty and creates multiple breaks between source, plan, authorization and execution.
The practical next step is to inventory every sink available to an autonomous team, then trace backward to the sources that may influence it. For each path, the company defines a structured representation, least-privilege identity, deterministic policy, proportionate approval and proof of the actual effect. An agent can then read an imperfect environment without turning every piece of encountered text into an executable instruction.
Primary sources and references
OpenAI, Designing AI agents to resist prompt injection, March 11, 2026
OpenAI, Keeping your data safe when an AI agent clicks a link, January 28, 2026
OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, 2025
OWASP Gen AI Security Project, LLM05:2025 Improper Output Handling, 2025
OWASP Gen AI Security Project, LLM06:2025 Excessive Agency, 2025
NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization, draft dated February 5, 2026
Atlensia, platform for autonomous enterprise teams, 2026