Prompt injection is an attack in which text supplied to an AI tool changes what the tool does, against the intentions of the person or company that built it. The text can come from the user, or from a web page, email or file the tool reads while doing its job. It matters most when the AI tool can act: send a message, open a link, edit a record or call another service.
Direct and indirect injection
The OWASP Gen AI Security Project lists prompt injection as LLM01, the first entry in its 2025 list of risks for applications built on large language models. It separates two forms:
- Direct injection: a user’s own prompt changes the model’s behavior in an unintended way, deliberately or by accident.
- Indirect injection: the model takes in content from an outside source, such as a website or file, and that content changes its behavior.
OWASP adds that the injected text does not need to be visible or readable to a person. It only has to be processed by the model. Text hidden in a web page’s layout, for example, is invisible to a reader but not to the model.
Consider an assistant asked to summarize your unread email. One message, written by a stranger, contains a paragraph addressed to the assistant rather than to you, telling it to forward the latest invoice to an outside address. If the assistant can send email and treats that paragraph as an instruction, the stranger has borrowed your access. Our guide to AI agent inbox access covers which permissions such a tool asks for.
Why it is harder to fix than SQL injection
Security teams know a similar-sounding bug: SQL injection, where data typed into a form is run as a database command. In a December 2025 blog post, the UK’s National Cyber Security Centre argues that the comparison misleads.
SQL injection has a fix at its root. Parameterized queries keep data and instructions apart, so the database never runs input as a command. The NCSC points out that inside a language model there is no such distinction: there is “only ever ‘next token’”. For that reason, it says, prompt injection “may never be totally mitigated” the way SQL injection can be.
The NCSC suggests treating a model as an “inherently confusable deputy”: a component that can be talked into using its privileges on behalf of someone with fewer of them. The task then becomes limiting what a successful injection can achieve, rather than hoping to block every malicious input. If a system cannot tolerate the remaining risk, the NCSC says, it may not be a good use for a language model.
Controls that limit the damage
Both sources concentrate on design rather than filters alone. OWASP’s mitigation list includes:
- Least privilege. Give the application its own credentials, handle extended functions in code rather than handing them to the model, and restrict the model’s access to what the task needs.
- Human approval for high-risk actions. Require a person to confirm privileged operations.
- Separate and label outside content. Mark untrusted text clearly so it has less influence on the instructions.
- Adversarial testing. Test the system while treating the model as an untrusted user, to check the trust boundaries.
The NCSC stresses deterministic safeguards, meaning ordinary code outside the model that constrains what the system is allowed to do. When the model’s output triggers tools or APIs, an attacker who controls that output gets, in the NCSC’s words, the worst-case result of “direct access to those tools/APIs”.
What to check as a user
You rarely see how an AI product is built, but its settings tell you a lot.
- List what the tool can do on its own: read, write, send, buy or delete.
- Prefer settings that ask before sending, paying or sharing.
- Be careful when an assistant works on content from strangers, such as inbound email, public web pages or shared documents.
- Grant access per task where possible, and remove connections you no longer use.
The same habits apply to browser add-ons that read every page you visit; see our guide to browser extension permissions.
