Prompt injection: how attacks work and how to defend AI agents

What is prompt injection?

Prompt injection is an attack that tricks an AI system with hidden instructions. A large language model (LLM) reads the developer's instructions, the user's request and any data it works on as one stream of text. It has no reliable way to tell which part is a command and which part is only information. An attacker uses this gap by writing text that the model follows as if it were a new instruction.

The OWASP Top 10 for LLM Applications (opens in a new tab) lists prompt injection as LLM01, its top risk, in both the 2025 and 2026 editions. OWASP describes it as input that changes the model's behavior in ways the developer did not intend. That input can be typed by a user, retrieved from a document, returned by a tool or hidden in an image or audio file.

The UK National Cyber Security Centre (NCSC) explains why this is harder than older injection bugs. In a database, parameterized queries keep commands and data apart, and that fixes SQL injection. An LLM has no such boundary. In its analysis of prompt injection (opens in a new tab), the NCSC warns that these attacks may never be fully mitigated in the same way and advises teams to focus on reducing the impact.

Direct and indirect prompt injection

The NIST report on adversarial machine learning, NIST AI 100-2 E2025 (opens in a new tab), separates two routes. The route decides who the attacker is, who gets hurt and which defenses help.

Direct prompt injection

In a direct attack, the attacker is the user. They type instructions into a chat window, a web form or an API call and try to override the rules the developer set in the system prompt. Typical goals are to reveal the system prompt, see data meant for other users or make the agent use a tool outside its task.

Indirect prompt injection

In an indirect attack, the attacker does not interact with your AI at all. They plant instructions in content the AI will read later, and the harm usually falls on the legitimate user. NIST describes this as an attack through control of a resource instead of through user input. Common hiding places include:

• Web pages an agent browses or summarizes, including text that people cannot see on screen
• Emails and attachments that reach an inbox agent
• Documents, PDFs and forms that users upload or share
• Knowledge base content the AI retrieves to answer questions, a setup known as retrieval-augmented generation (RAG)
• Tool and API outputs: search results, ticket fields, CRM notes and database records
• Images and audio processed by models that handle more than text

Indirect injection matters most for a business because the attacker needs no account and no access. Anyone who can send you an email, submit a support ticket or edit a public web page can put text in front of your AI.

Why AI agents with tools raise the stakes

A chatbot that only answers questions can be tricked into a wrong answer, but a person still decides what to do with it. An AI agent is different. It can send email, update your CRM, issue a refund, change a record or call another system's API. When an agent is fooled, the attacker's instruction turns into an action.

NIST makes the same point in its section on agent security. Because agents act through tools, prompt injection can let an attacker hijack an agent to run code or take data out of the environment it works in.

The highest risk comes from one combination of capabilities, which the 2026 OWASP entry recommends checking before launch. An agent has the conditions for serious harm when it can do all three of these things:

• Read private data: customer records, inboxes, internal files or financial systems.
• Process untrusted content: emails from any sender, public web pages, uploaded files or third-party tool outputs.
• Send data out: email, web requests, chat messages and links or images in its replies.

Remove any one of the three and data theft through injection becomes much harder. When a business need requires all three, add human approval for every action that sends data out and test that agent hardest.

How prompt injection attacks work in practice

Real attacks combine a few basic moves, described here at a conceptual level. Our post on prompt injection examples we test for covers 10 patterns in more detail.

• Instruction override. The attacker tells the model to disregard its earlier rules or to take on a new role with fewer limits.
• Hidden text. Instructions sit in parts of a page or document that a person does not see but the model reads, such as text hidden by formatting or placed in page code.
• Knowledge base poisoning. One planted document in a source the AI trusts can steer its answers. NIST cites research in which a single crafted document was enough.
• Data exfiltration through output. The model is told to add private data to a link or image address in its reply. When the chat interface loads the image or the user clicks the link, the data goes to a server the attacker controls.
• Self-spreading messages. An email read by an AI email assistant tells it to send similar emails to everyone in the user's contacts. NIST describes this worm-like pattern in its taxonomy.
• Obfuscation. The attacker encodes the instruction, writes it in a less common language or splits it across several fields, so filters that look for known phrases miss it.
• Gradual steering. Across many turns, each message looks harmless, but together they lead the model to a result it would refuse in one step.

Defense in depth for prompt injection

No single defense stops all prompt injection. NIST states that current mitigations do not offer full protection against all attacker techniques and suggests designing systems on the assumption that injection is possible whenever a model reads untrusted input. OWASP also frames its controls as defense in depth. Some controls make an attack less likely to succeed, and others limit the damage when one does. Agents with tools need both.

Least-privilege tool access

Give each agent only the tools, data and permissions its task needs, and prefer read-only access. Keep credentials in application code, not in the prompt, and give each agent its own account so its actions are easy to trace and revoke. The NCSC suggests a useful design rule: when a model processes content from a party, its privileges should drop to the level of that party. Our guide to AI agent permissions explains how to map this for each agent.

Human approval for risky actions

Require a person to approve actions with financial, legal or customer impact: payments, refunds, deletions, permission changes and messages to external recipients. Show the reviewer the exact action, such as the recipient, the amount and the full text, not the agent's summary of it. Keep the volume of approvals manageable, because reviewers who see too many requests start to approve them without reading.

Separate trusted and untrusted content

Mark external content clearly in the prompt, for example with labels or tags, and instruct the model to treat it as data. The NCSC notes that this makes injection harder but does not remove the risk, and OWASP points out that an attacker who knows the format can imitate it.

Stronger separation is architectural. An agent that reads public emails or web pages should not also hold tools that move money or send data out. Where one workflow needs both, split it: a component with few permissions reads the untrusted content and passes structured fields, not free text, to the component that acts.

Output checks and allow-lists

Check what the model produces in application code before anything acts on it. Validate the format and the allowed values of every tool call, such as the recipient domain of an email or the maximum amount of a refund. In chat interfaces, allow links and images only from domains on an approved list, and do not load external images automatically. These checks help block common exfiltration routes, but a response in the right format can still carry the wrong intent.

Input filtering and its limits

Filters and classifiers can catch known attack phrasing and remove invisible characters from input. They are worth having as one layer and weak as the only layer, because attackers rephrase, encode or switch languages until something passes. In a 2025 study of adaptive attacks (opens in a new tab), researchers bypassed 12 recent defenses with attack success above 90% for most of them, even though most of those defenses had originally reported near-zero attack success.

Monitoring, logging and rate limits

Log the model's input and output, every tool call and every API request, as the NCSC recommends, so you can spot and investigate suspicious activity. Alert on patterns such as a new external domain in replies, a spike in records read or repeated failed tool calls. Protect these logs like other sensitive data, because they contain everything the agent saw.

Rate limits on actions and messages per session slow down an attacker who is probing the system and cap the damage of a successful attack. NIST also notes that limiting the number of queries a user can make can make some attacks harder.

Attack testing before launch and after changes

Test each agent the way an attacker would before it goes live, and again when you change the model, the prompts, the tools or the data sources. Each change can open a path that earlier tests did not cover. Testers should know the defenses and try to get around them, because fixed lists of known attacks overstate protection. In our attack testing, we try every input the agent reads, not only the chat window, and we retest after fixes. Our guide to AI red teaming, a structured attack test of an AI system, explains how a test is scoped.

Prompt injection attack types and matching defenses

Check your own AI agents against this table. Every attack type needs more than one defense, because each control has limits.

What OWASP, NIST and cyber agencies recommend

OWASP. The 2026 edition keeps prompt injection first and moves Excessive Agency, the risk of giving a model too many functions, permissions or too much autonomy, up to third place. OWASP says agentic deployments are where the damage is landing. For systems where the model acts on its own, OWASP publishes a separate Top 10 for Agentic Applications (opens in a new tab), where the matching entry is ASI01, Agent Goal Hijack. Our guide to the OWASP Top 10 for LLM applications walks through the full list.

NIST. AI 100-2 E2025 covers direct prompting attacks in section 3.3, indirect prompt injection in section 3.4 and agent security in section 3.5.

National cyber agencies. In May 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the UK NCSC, the Australian Cyber Security Centre and partner agencies published joint guidance, Careful adoption of agentic AI services (opens in a new tab). It advises against broad or unrestricted access to sensitive data or critical systems and recommends starting with low-risk use cases. The NCSC's summary of the guidance (opens in a new tab) adds that agents should get the minimum access they need for the shortest time, and that an agent whose actions you cannot understand, monitor or contain is not ready to go live.

A starting plan for your AI agents

1. 1List every AI agent and chatbot, and write down what each one can read, change and send.
2. 2Mark each input source as trusted or untrusted. Treat email, web content, uploads and third-party tool outputs as untrusted.
3. 3Find agents that combine private data, untrusted content and a way to send data out. Remove one of the three or add approval steps.
4. 4Add human approval for actions with financial, legal or customer impact.
5. 5Log inputs, outputs and tool calls, and set alerts for unusual activity.
6. 6Attack-test each agent before it goes live and after every significant change.

Our secure AI agent checklist turns these steps into controls you can assign and track. For an outside view, our AI security consulting team runs prompt injection tests with a written scope, reports each finding with a fix and retests after you apply it.