Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Prompt Injection?

AI agent prompt injection is an attack in which content an agent processes causes it to follow instructions from an unauthorized source. Because instructions and data reach the model in the same stream, detection alone cannot settle it. What sets the damage is what the agent holds when the injection succeeds and which actions wait for a named person.

Content cards pass a model inspection stage before a gate routes access to enterprise systems.

AI agent prompt injection is an attack in which content an agent processes causes it to follow instructions from an unauthorized source. Because instructions and data reach the model in the same stream, detection alone cannot settle it. What sets the damage is what the agent holds when the injection succeeds and which actions wait for a named person. The instructions it follows arrive instead of, or in addition to, those of the person or organization that deployed it. In a simple chatbot the result may be a wrong or embarrassing answer. In an agent, which reads records and takes actions in real systems, the result can be a disclosure of data the agent holds, a change to a record, a message sent, or a task quietly redirected. The attack has direct and indirect forms, and defenses that limit what the agent holds and what it may do alone, such as render-layer tokenization and approval gates, matter as much as defenses that try to detect the attack. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • OWASP ranks Prompt Injection as LLM01, the first entry in its Top 10 for LLM Applications, in the 2025 edition (OWASP, 2025).
  • OWASP distinguishes direct injection, where the attacker supplies the prompt, from indirect injection, where instructions are planted in content the system later retrieves or displays (OWASP, 2025).
  • The underlying cause is architectural: a language model receives instructions and data in the same stream of tokens and has no built in, reliable way to tell which parts carry authority, which is why OWASP describes the risk as inherent to how models process prompts (OWASP, 2025).
  • Indirect injection is the more significant form for agents, because agents routinely read web pages, emails, documents, tickets, and notes written by parties outside the organization; the pattern was documented against deployed LLM-integrated applications by Greshake et al. (2023).
  • Detection helps but does not settle the problem. Controls that limit what the agent holds, and that require approval for consequential actions, determine the damage when an injection succeeds; OWASP's mitigation guidance for LLM01 and Excessive Agency, LLM06, points the same way (OWASP, 2025).

What exactly is being injected, and into what?

The injected object is an instruction, expressed in ordinary language, sometimes disguised, sometimes encoded, sometimes split across pieces of content. The destination is the agent's context: the combined material the model is working from at a given moment, including the system instructions, the user's request, the history of the task, and any content the agent has retrieved or been shown. If the model treats the planted instruction as if it came from a legitimate source, the injection has worked.

An example in plain form makes the mechanism concrete. An agent is asked to process supplier invoices from an inbox. One message contains, in its visible body or in text hidden from a human reader, an instruction to forward the previous invoice and its bank details to an external address before continuing. A person reading the inbox would see a suspicious message. The model sees additional text in its input, and depending on how the system is built, it may weigh that text alongside the operator's instructions rather than beneath them.

Nothing in this mechanism requires the attacker to have an account, to breach a system, or to write code. The attack surface is content. Any place where outside parties can place text that an agent will later read is a potential delivery route: a web page, a customer note, a resume, a support ticket, a product listing, a shared document, metadata, or the output of another tool. That breadth is the reason OWASP treats prompt injection as a category of its own rather than as a variant of input validation (OWASP, 2025).

Prompt injection also differs from jailbreaking, with which it is often merged. Jailbreaking aims to make a model disregard its safety constraints, usually for the attacker's own interaction. Prompt injection aims to redirect a system acting for someone else, usually to reach data or actions belonging to that someone else. The techniques overlap; the victim and the objective differ.

What is the difference between direct and indirect injection?

Form Who supplies the instruction Typical setting Who is harmed
Direct The person interacting with the system A user tries to override the system's instructions in their own session The operator, if the override reaches data or tools beyond that user
Indirect A third party who plants content in advance Pages, emails, documents, records, or tool outputs the agent later reads The operator and the people whose data the agent holds
Stored A third party, in a system the agent revisits Notes, tickets, knowledge bases, shared files Later users of the same workflow

Direct injection is the easier form to reason about, because the attacker is present in the interaction and the session can be limited to that person's own entitlements. Indirect injection removes the attacker from the scene. The payload waits in content until an agent with broader access arrives to read it. The person who asked for the work may have no connection to the attacker, and the content may have been planted long before the workflow existed.

For an organization deploying agents on internal work, indirect injection is the form that should drive design. Its agents will read inboxes, portals, documents from counterparties, and records that customers and suppliers can influence. OWASP's description of LLM01 covers both forms and notes that indirect injection is particularly relevant where a system processes untrusted content (OWASP, 2025). Provider material reaches the same conclusion from the product side: OpenAI's Operator system card describes web content as a source of adversarial instructions and reports mitigations built around monitoring, confirmation, and restricting the agent's scope (OpenAI, 2025).

Hidden placement deserves a specific mention. Practitioners repeatedly observe payloads placed where a person will not look: in HTML that is not rendered as visible text, in white text on a white background, in document metadata, in alt text, or in a part of a long record far from the section a person reviews. This is a predictable consequence of the difference between human and machine reading. A person reads the rendered surface and skims. A model may receive the underlying text in full.

Why are agents a larger target than chatbots?

Three properties of agents compound the risk. Access is the first. An agent deployed for real work holds, or can reach, material that a public chatbot never touches: customer records, financial details, internal documents, and authenticated sessions. Influence over the agent is therefore influence over that material. Action is the second. An agent can do things: send, submit, change, delete, purchase, approve. A chatbot that is manipulated produces text that a person can ignore. An agent that is manipulated may produce a state change that a person discovers later. Persistence is the third. Agents work through queues, so a single planted payload in a shared inbox or a popular page can be encountered by many runs, and a successful payload placed in a record the agent writes can affect later runs that read it.

OWASP captures the action dimension separately as Excessive Agency, LLM06, and the disclosure dimension as Sensitive Information Disclosure, LLM02 (OWASP, 2025). Prompt injection sits upstream of both: it is frequently the means by which an attacker reaches the agency and the data. This is why ranking it first in the list is defensible. It is not necessarily the most damaging failure in isolation. It is the failure that turns other weaknesses into incidents.

Scale changes the defensive problem as well. A person who reads something odd can be puzzled, suspicious, or slow. An agent processes content uniformly and quickly, and the same workflow may run hundreds of times before anyone reviews a sample. Detection and design controls therefore have to work without relying on the reader noticing that a piece of content feels wrong.

What does a successful injection actually get?

It helps to enumerate the payoff, because defenses should be judged against it. A successful injection can pursue four kinds of gain. Extraction: causing the agent to reveal or send material in its context, including other customers' data, internal instructions, or credentials that were improperly present. Redirection: changing the destination or recipient of legitimate work, for example altering where a payment, a report, or a message goes. Action abuse: causing the agent to perform an operation it is permitted to perform, but for the attacker's benefit or at the wrong target. Persistence and contamination: causing the agent to write the payload, or false information, into a record, note, or knowledge source that later runs will trust.

The size of each payoff is set by design choices made before the attack. Extraction is bounded by what the agent holds during that run. Action abuse is bounded by which actions the agent may commit without approval. Redirection is bounded by which destinations are fixed in advance and which the model is free to choose. Persistence is bounded by whether agent output is written directly to systems of record or staged for review. This is the practical reason that least privilege, data minimization, and approval gates appear in every serious treatment of the subject, including OWASP's own mitigation guidance for LLM01 and LLM06 (OWASP, 2025).

One further point is often missed. An injection does not need to fully succeed to cost money. A partial success that makes an agent produce subtly wrong work, skip a record, or misclassify a case can pass review and propagate. Defenses that only look for dramatic exfiltration will miss the low and slow failures, which is an argument for sampling agent output and for recording enough of each run to reconstruct decisions afterwards.

Which defenses exist, and what can each one not do?

Defenses fall into five families, and each has a stated limit. Instruction hierarchy and system design try to make the model privilege operator instructions over content, through training and prompt structure. This reduces casual success but cannot be relied on as a boundary, because the model is still interpreting all of it as language. Detection and filtering scan inputs and outputs for known patterns, suspicious instructions, or sensitive values. Filters catch known shapes and miss novel phrasing, and they face the same ambiguity as the model does.

Isolation and structure separate untrusted content from instructions mechanically, for example by marking retrieved content as data, constraining the formats an agent may act on, or keeping a planning component away from raw content. This is a stronger direction, because it relies less on the model's judgment, but it is harder to retrofit. Scope limitation reduces what the agent holds and can do: least privilege on systems, minimization of the data presented, and replacement of sensitive values with tokens. Scope limitation does not prevent injection. It determines the payoff, which is often the more useful property. Human approval places a person at the point of commitment for consequential actions, so that even a fully persuaded agent cannot complete the harmful step alone.

Providers describe layered combinations rather than a single fix. OpenAI reported using monitoring, confirmations, and restrictions for Operator (OpenAI, 2025). Google describes a per step safety service and developer configurable confirmations for its computer use model (Google, 2025). Anthropic has published work on measuring and reducing agent susceptibility to indirect injection, and treats the problem as ongoing rather than solved (Anthropic, 2025). The NIST AI Risk Management Framework provides the process wrapper: identify the risk, measure it with testing, and manage it with controls whose effectiveness is revisited (NIST, 2023).

A reviewer should be skeptical of any claim that a product prevents prompt injection. The credible claims are narrower: that certain content is never given to the model, that certain actions cannot complete without a person, and that each run leaves a record.

Where does RedactSure sit?

RedactSure is built for the case in which detection fails. Planning for attacker success is where it belongs in an injection strategy. Inside the governed environment, every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, so the model receives the task's fields with identifiers as tokens. If hostile page text does persuade a RedactSure agent, the material it can gather is tokens such as ACCT_001 and VENDOR_001 plus whatever task context remains, not the real customer or payment values those tokens replaced. Real values resolve only at approved destinations at the moment of an approved action.

The consequential step the injection wants, such as a submission or a record change, still halts for a named approver under Supervised Delegation, so a successful trick collects substitutes and runs into a person. The Planner sets which values are tokenized and what the agent may do on each screen, and a named person confirms that policy before the run. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, which supplies the per-run record that the low and slow failures require. The environment is model agnostic, needs no per-application integration, and leaves user permissions unchanged. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page rests on the OWASP Top 10 for LLM Applications, 2025 edition, which defines and ranks the risk in its LLM01, LLM02 and LLM06 entries (industry standard); provider publications describing how agent systems address injection, namely OpenAI's Operator system card (January 2025, vendor documentation), Google's announcement of the Gemini 2.5 Computer Use model (October 2025, vendor documentation) and Anthropic's published guidance on Claude in Chrome (vendor documentation); Greshake et al. on indirect prompt injection against LLM-integrated applications (2023, preprint); and the NIST AI Risk Management Framework for the surrounding risk process (official guidance). All sources were read as of October 13, 2026.

No injection testing was performed, no success rates are reported, and no claim is made about the relative effectiveness of specific detection techniques, because published measurements use different tasks, models, and attack sets and cannot be compared directly. No hands-on testing of Operator, the Gemini computer use model or Claude in Chrome was performed; what each provider detects, confirms or restricts is that provider's own description. Vendor features and published mitigations change, and the page carries its date and is revised when the documentation changes. The illustrative invoice example is a constructed scenario, not a reported incident, and describes a record type rather than any organization; no customer or prospect is described. RedactSure statements are limited to design facts the company publishes about itself.

Whether any combination of controls meets an organization's requirements, and how its agents should be scoped, approved and recorded, belongs to its counsel, its assessor and its own security and compliance officers, not to this page.

What the record shows

Prompt injection is an architectural problem before it is a detection problem. A language model receives instructions and data in a single stream and has no reliable way to know which parts carry authority, so outsider content can arrive formatted as orders and be followed as orders. Indirect injection, the form that matters most for agents, plants instructions in the pages, documents, and records an agent reads during ordinary work. The consequences exceed a bad answer, because an agent holds data and can act. Detection deserves investment, but an incident's outcome is set by what the agent held when the injection succeeded and by which actions required a person's approval. The test for any agent is one question: show what the model held during one run of the workflow, and name the actions that could not complete without a person.

Frequently asked questions

What does indirect prompt injection look like in practice?

It looks like ordinary content. Instructions are planted in material the agent will retrieve or be shown, a web page, an email, a document, a ticket, or a note, rather than typed into the prompt by the attacker. The constructed invoice scenario above makes the shape concrete: a document that appears to be an item of work carries directions aimed at the agent processing it. The agent encounters those directions while doing its task, with no difference between them and the legitimate instructions it was given.

Why can the model not just ignore instructions found in data?

Because, mechanically, there is no separate channel. The deployer's instructions and the content reach the model as one stream of tokens, and the model has no built-in, reliable mechanism for tagging which spans of that stream it should obey and which it should treat as inert material. Techniques can make obedience to outside instructions less likely, and providers apply several, but likelihood is not a boundary. Injection is a property of how models consume text, rather than a bug awaiting a patch.

If detection is in place, are human approvals still necessary?

Yes, because the two controls answer different questions. Detection asks whether an input looks like an attack, and it will sometimes be wrong in the attacker's favor. Approval asks whether a consequential action, a payment, a submission, a record change, may proceed, and it is asked at the moment of the action regardless of how the instruction arrived. An agent can carry an injected instruction to the point of action and still cause no harm, provided the action stops there and the data it holds is limited.

Is prompt injection the same as jailbreaking?

No. Jailbreaking aims to make a model disregard its own safety constraints, usually within the attacker's own session and for the attacker's own output. Prompt injection aims to redirect a system that is acting for someone else, usually to reach data or actions that belong to that someone else. The techniques overlap, and a single payload can do both, but the victim and the objective differ, which is why OWASP treats injection as a category of its own.

Can a product prevent prompt injection?

Treat that claim with skepticism. No published technique gives the model a reliable boundary between instruction and data, and providers describe layered mitigations rather than a fix. The credible claims are narrower: that certain content is never given to the model, that certain actions cannot complete without a person, and that each run leaves a record. A buyer should ask a vendor which of those three it delivers and how, rather than whether injection is prevented.

Where do attackers hide injected instructions?

Where a person will not look and a model will still read. Reported placements include HTML that is not rendered as visible text, white text on a white background, document metadata, image alt text, and a section of a long record far from the part a person reviews. A person reads the rendered surface and skims; a model may receive the underlying text in full. Any content an outside party can place in the agent's path is a candidate location.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.