Prompt injection: how the attack works and how to defend against it

The essentials at a glance

Definition. Prompt injection consists of slipping instructions into the text processed by a large language model (LLM). The goal is to make it do something other than what its designer or its user intended.
Two routes. Injection is direct when the attacker writes to the AI themselves. It is indirect when the instructions are hidden in a web page, an email, a document or a tool's output that the AI reads on the user's behalf.
Risk #1. OWASP ranks it first in its Top 10 for LLM applications (LLM01:2025). MITRE ATLAS lists it under identifier AML.T0051.
No definitive fix. The UK's NCSC believes it may never be fixed as completely as SQL injection. OpenAI and Anthropic also acknowledge that the problem is not solved.
The right strategy: limit the damage. That means reducing the AI's privileges, never combining private data, untrusted content and an outbound channel, having a human approve sensitive actions, logging, and testing.

What are we talking about?

An AI assistant receives a single stream of text. It contains the designer's instructions (the "system prompt"), the user's request and the content the tool fetches: a web page, an email, a file, a response from third-party software. The model processes all of it as a sequence of words. It draws no reliable boundary between what is a command and what is mere data. Prompt injection exploits this confusion: a well-crafted text, placed in the right spot, is taken for an instruction.

OWASP (the Open Worldwide Application Security Project) states that these inputs "can be imperceptible to humans," as long as the model reads them. It adds that neither retrieval-augmented generation (RAG) nor fine-tuning eliminates this risk. For its part, MITRE ATLAS, the knowledge base of attacks against AI systems, distinguishes three sub-techniques: direct (AML.T0051.000), indirect (AML.T0051.001) and triggered (AML.T0051.002).

Direct injection

Here, the user types instructions to hijack the tool. They may try to get it to reveal the system prompt, to pull a customer-service chatbot out of its role, or to obtain a commitment the company never meant to make. The risk is real. But it is generally limited to what that user can already reach.

Indirect injection

This is the most worrying form for an organization. The attacker never addresses the AI: they plant their instructions where it will go to read. The victim then triggers the attack with an ordinary request such as "summarize my emails" or "look at the open tickets." The documented carriers are varied:

white text on a white background or an HTML comment in a web page the assistant summarizes;
an invisible layer in an email (CSS-hidden text, zero-width Unicode characters, Base64-encoded data);
an instruction slipped into a résumé, such as "give the highest score";
a document dropped into an internal knowledge base queried by the AI;
a ticket, code comment or request in a public repository;
the description of a calendar invitation;
a response returned by a tool or an MCP (Model Context Protocol, the protocol that connects agents to external tools) server;
an image containing text, for models that also read images.

Prompt injection or jailbreak?

The two notions are often confused. A jailbreak seeks to make the model produce what its vendor forbids, such as dangerous content. For OWASP, a jailbreak is a particular form of prompt injection: one that aims to make the model abandon its safety rules.

For an organization, the difference is practical. Jailbreaking is mainly a matter for the model vendor and for abuse of the service. Indirect injection hits the application you deploy directly: a third party takes control of a tool that acts with your privileges. A model that resists jailbreaks well can still be vulnerable to injection. An instruction like "attach this summary to an email to this address" is not forbidden in itself.

Why no defense is complete

On December 8, 2025, the NCSC (National Cyber Security Centre, the UK's cybersecurity agency) published an analysis titled "Prompt injection is not SQL injection (it may be worse)." SQL injection was largely tamed thanks to parameterized queries, which strictly separate code from data. An LLM offers no such separation. According to the agency, prompt injection may therefore never be fixed as completely as SQL injection. It suggests viewing the model as an "inherently confusable deputy": you cannot stop it from being fooled, you can only limit what it can do once fooled.

Vendors say much the same. On December 22, 2025, in a post about hardening its Atlas browser, OpenAI wrote that prompt injection would probably never be fully "solved." The company compares it to scams and social engineering. On November 24, 2025, Anthropic called prompt injection a problem that is "far from solved." It added that "no browser agent is immune" and that a 1% attack success rate "still represents meaningful risk." These figures are measured by the vendors themselves, on their own test benches. They are not comparable from one vendor to another and do not replace an independent assessment. This caveat also applies to Anthropic, whose Claude model is used to write this site.

Independent evaluations point the same way:

In January 2025, NIST's CAISI (Center for AI Standards and Innovation) developed new attacks against a hardened version of Claude 3.5 Sonnet: the success rate of the best attack rose from 11% (best baseline attack) to 81%. Across five injection tasks, repeating each attack 25 times, the average rose from 57% to 80%.
In October 2025, a team of fourteen researchers bypassed twelve published defenses, with a success rate above 90% for most of them. Most had nonetheless reported rates close to zero.
In March 2026, CAISI published, together with Gray Swan, the organizer, and the UK's AISI (AI Security Institute), the analysis of a public red-teaming competition. More than 250,000 attempts were made, and at least one attack succeeded against each of the thirteen models tested.

The lesson is simple. A filter that "blocks 95% of attacks" is not enough, because the attacker can retry as many times as they like.

What an organization stands to lose

OWASP lists several possible consequences:

Data leakage. The assistant reads your emails or documents, then sends them out. Often, the data is slipped into the URL of an image or link that the interface loads automatically.
Unintended agent actions. The agent sends a message, modifies or deletes a file, publishes code, runs a command or places an order.
Manipulated answers. A summary presents a fraudulent email as urgent and legitimate, a résumé is over-scored, a recommendation is skewed.
Configuration disclosure. The attacker obtains the system prompt, the list of tools or infrastructure details.
Code execution. It becomes possible when the model's output is passed unchecked to an interpreter or a connected system.

Two frameworks help spot dangerous situations. In June 2025, researcher Simon Willison described a "lethal trifecta": an agent is exposed to leakage as soon as it combines access to private data, exposure to untrusted content and the ability to communicate externally. On October 31, 2025, Meta proposed an "Agents Rule of Two." Within a single session, an agent should combine no more than two of these three properties: processing untrusted inputs, accessing sensitive systems or private data, and changing state or communicating externally. If all three are essential, the agent must not act alone and must be supervised, for example through human approval.

Documented examples

EchoLeak, Microsoft 365 Copilot (June 2025). Aim Security showed that a single booby-trapped email could lead Copilot to extract the organization's internal data, without any click from the victim. Microsoft rated the flaw critical (CVE-2025-32711, CVSS score of 9.3). It fixed it on the server side, with no action required from customers, and no known exploitation.
GitHub MCP server (May 2025). Invariant Labs planted in a public repository an issue containing a prompt injection. A user's agent, tasked with reading issues, retrieved information from their private repositories (including a salary) and published it on the public repository. According to the researchers, the problem lies in the agent's architecture, not in GitHub's code: no server-side fix can solve it.
Gemini and Google Calendar (2025). Researchers from Tel Aviv University, the Technion and SafeBreach booby-trapped calendar invitations. When the user asked Gemini about their schedule, the assistant executed the hidden instructions: deleting events, starting a video call, controlling connected devices. Google says it has deployed multi-layered protections, including more confirmation requests to the user.
Semantic Kernel (May 2026). Microsoft described two flaws in its agent framework (CVE-2026-26030 and CVE-2026-25592). A prompt injection could lead to code execution on the host machine. Microsoft draws this principle from it: any tool parameter the model can influence must be treated as attacker-controlled input.
AWS AgentCore (2026). According to Zenity, a single request sent to a public agent made it possible to reach other agents and their secrets. AWS disputes that this is a vulnerability (see our article).

What do we see in the wild? In April 2026, Google analyzed the public web archive Common Crawl (2 to 3 billion pages per monthly snapshot). The company found a relative increase of 32% in malicious injections between November 2025 and February 2026. It considers their technical level still low, but expects both their number and their sophistication to grow. In October 2026, Barracuda Networks described emails that combine classic phishing with invisible instructions aimed at the recipient's AI assistant, so that it presents the message as legitimate.

The frameworks to know

Framework	What it provides
OWASP Top 10 for LLM applications, risk LLM01:2025	The definition, the distinction between direct and indirect injection, nine typical scenarios and seven families of prevention measures.
OWASP Top 10 for agentic applications 2026 (published December 9, 2025)	Risks specific to agents. The first, ASI01, covers hijacking of the agent's goal, most often through indirect injection.
MITRE ATLAS, technique AML.T0051	A taxonomy (direct, indirect, triggered injection) and case studies, useful for threat modeling and exercises.
ANSSI (France's national cybersecurity agency), Recommandations de sécurité pour un système d'IA générative (security recommendations for a generative AI system, April 29, 2024)	Filter requests and responses, compartmentalize the AI system, avoid automated actions between the AI and the information system as much as possible, log everything.
CERT-FR, CERTFR-2026-ACT-016 (April 13, 2026)	An advisory on agents installed on workstations (OpenClaw, Claude Cowork, etc.). It cites LLMs' intrinsic vulnerability to prompt injection and requires human approval for any action with side effects.
NCSC, post of December 8, 2025	A clear doctrine: reduce the impact rather than promise a block. It aligns with the ETSI TS 104 223 standard (baseline cybersecurity requirements for AI models and systems).
NIST AI 100-2 E2025 (March 2025) and CAISI work	The reference terminology for attacks on AI and methods for evaluating agent hijacking.

Timeline

April 2024: ANSSI guide on the security of generative AI systems.
March 2025: 2025 edition of the NIST AI 100-2 taxonomy.
May-June 2025: GitHub MCP and EchoLeak flaws.
October-December 2025: Meta's "Rule of Two," OWASP's agentic Top 10, the NCSC post, positions from Anthropic and OpenAI.
February 2026: CERT-FR overview of generative AI and cyberattacks (CERTFR-2026-CTI-001).
April 2026: CERT-FR advisory on workstation agents and Google's measures on the web.
As of October 18, 2026: no European or French text specifically addresses prompt injection. The subject falls under general obligations on the security of systems and data.

Where to start

These measures are ranked by priority. They apply to a chat assistant connected to your data as much as to an agent able to act. For the overall governance of agents (identities, MCP servers, oversight), see our guide AI agent security.

Take inventory. List the assistants and agents in use, including browser extensions and tools installed without approval. For each one, note what it reads and what it can do.
Treat all external content as untrusted. This applies to web pages, incoming emails, shared documents, tickets and responses from tools or MCP servers, even when they come from a known partner.
Break the "lethal trifecta." For each use case, remove at least one of the three capabilities. An assistant that reads external emails must not be able to send messages. An agent that browses the web must not have access to HR folders.
Apply least privilege. Use dedicated accounts and tokens, limited to a narrow scope (one mailbox, one repository, one folder) and read-only by default. The NCSC adopts this rule, proposed by Simon Willison and Baibhav Bista: when an AI processes a third party's data, its privileges drop to those of that third party.
Have a human approve sensitive actions. This is essential for sending messages, payments, deletions or system commands. Disable "always allow" options and clearly show the user what is about to be executed.
Close the leak channels. Prevent the automatic loading of AI-generated images and links, or restrict it to a list of allowed domains.
Put the controls outside the model. Have the application verify tool parameters and the format of responses. Never pass a model's output to an interpreter unchecked. Defensive instructions written in the prompt help, but CERT-FR points out that an injection can bypass them.
Separate and mark data. Wrap external content in tags that flag it as data. The NCSC notes that this makes injection harder, but not impossible. Avoid blocklists of forbidden words: the possible phrasings are endless.
Filter and monitor. Detection classifiers are a complement, not a guarantee. Log inputs, outputs and tool calls. Watch for failed or unusual tool calls, which can betray an attack in preparation.
Test before and after going into production. Commission a penetration test of the AI application. It must include indirect scenarios and repeated, adaptive attacks. Redo it with every model change or added tool.
Govern and train. Have each deployment approved by the IT department and the CISO, with written acceptance of the residual risk. Teach users that an AI-generated summary may have been manipulated. Ask vendors how they reduce the risk, and be wary of those who claim to eliminate it.