AI tools are only as trustworthy as the instructions they follow. Prompt injection exploits that trust — and it is one of the most active threats facing organisations using AI today.
Prompt injection is a way of tricking an AI into ignoring its instructions and doing something it should not. An attacker hides commands inside content the AI is asked to process — a document, a webpage, an email — and the AI follows those hidden commands instead.
The result can range from the AI leaking sensitive information to taking harmful actions on a user's behalf, entirely without their knowledge.
The good news: there are concrete steps organisations can take to reduce the risk significantly. We cover them at the bottom of this article.
Every AI system that accepts text input operates on a set of instructions. Some of those instructions come from the organisation that built the tool — defining what the AI is allowed to do, what tone it should take, what data it can access. Others come from the user in real time.
Prompt injection is the act of inserting malicious instructions into that input stream. The goal is to override or replace the AI's original instructions so that it behaves in a way the attacker wants, rather than the way the organisation intended.
It sits at number one on the OWASP Top 10 list of risks for large language model applications — not because it is the most technically complex, but because it is pervasive, difficult to fully eliminate, and the consequences can be severe.
This is the more obvious form. A user interacts directly with an AI tool and deliberately crafts their input to manipulate the model's behaviour. Think of it as social engineering, but aimed at a machine.
In this case the attacker extracts the system prompt — which may contain confidential business logic, internal data references, or security configuration. That information can then be used to craft further, more targeted attacks.
This is the more dangerous and harder-to-detect variant. Here, the attacker does not interact with the AI directly. Instead, they plant malicious instructions inside content that the AI will later be asked to process.
Indirect injection can occur entirely without the user's involvement. The victim never types anything suspicious — the attack is already waiting in a document, a webpage, or a calendar invite.
Traditional software follows deterministic rules. An if-statement does not get confused by a persuasive argument. An AI model, however, is trained to be helpful, to follow instructions, and to interpret natural language flexibly. Those strengths become weaknesses when the instructions are malicious.
The risk compounds when AI systems are given real-world capabilities — the ability to send emails, query databases, browse the web, or take actions on the user's behalf. An injected instruction that manipulates a read-only chatbot is annoying. The same attack against an AI agent with write access to business systems is a genuine incident.
If you have worked in security for any length of time, prompt injection will feel familiar. The underlying idea — that untrusted input bleeds into an instruction stream and gets executed — is exactly what SQL injection has exploited for decades. The comparison is a useful starting point, but it breaks down quickly, and understanding where it breaks down is what matters.
Both attacks exploit the same fundamental failure: the system does not cleanly separate data from instructions. In SQL injection, a user's input escapes its intended context and gets interpreted as a database command. In prompt injection, a user's input — or content the AI processes — escapes its intended context and gets interpreted as an instruction to the model.
That is where the similarity ends. The table below shows why the well-established fixes for SQL injection do not transfer cleanly to AI systems.
| SQL injection | Prompt injection | |
|---|---|---|
| Input grammar | Finite, structured SQL syntax — parsers can reliably distinguish commands from string values | Natural language has no fixed grammar — there is no reliable boundary between "data" and "instruction" |
| Primary fix | Parameterised queries and prepared statements — largely a solved problem solved | No equivalent exists for prose — you cannot parameterise natural language open problem |
| Attack surface | The database layer — impact is contained to data that database can access | Any system the AI agent touches: email, file storage, APIs, external services |
| Determinism | A given payload either works or it does not — behaviour is consistent and testable | The same injected text may succeed sometimes and fail others, depending on model state and conversation context |
| Input sanitisation | Works well — "clean" input has a clear definition and can be validated reliably | Largely ineffective — malicious and benign inputs are often grammatically identical and indistinguishable at face value |
| Token handling | Parser distinguishes tokens by type — string, integer, keyword — enforcing structure | Every token is treated as potentially meaningful input — the model cannot natively flag a word as "just data" |
The practical implication is that the security industry has thirty years of experience building reliable defences against SQL injection. For prompt injection, that playbook does not exist yet. Defence relies on layering imperfect controls rather than applying a single reliable fix — which makes the testing and mitigation work we cover below all the more important.
If your organisation is using or building AI tools, these are the test approaches that should be part of your evaluation process.
No single control eliminates prompt injection entirely. The approach that works is defence in depth — layering several controls so that bypassing one does not compromise the whole system.
Replace freeform user input with structured templates wherever possible. If the AI only ever receives inputs in a defined format, it is much harder to smuggle in override instructions. Freeform input fields are the primary attack surface.
Deploy a gateway that screens inputs before they reach the model. A prompt firewall can detect and block known injection patterns, instruction-override language, and anomalous input structure. It should sit between the user — and any external content the AI processes — and the model itself.
An AI that can only read should never be configured to write. An AI that handles internal documents should have no access to external communications. Limiting what actions an AI can take dramatically reduces the blast radius of a successful injection.
Any action that is difficult to reverse — sending communications, modifying records, accessing sensitive data — should require explicit human approval before execution. Do not allow AI agents to complete these actions autonomously, regardless of what the prompt says.
Log both the inputs sent to the model and the outputs it generates. Anomalous response patterns — unexpected disclosures, sudden changes in behaviour, outputs that do not match the apparent input — should trigger review. Monitoring creates the visibility needed to detect attacks that slip through other controls.
Configure the model to refuse requests that fall outside its defined scope, and validate its outputs before they are passed to downstream systems or acted upon. An AI that has been injected should not be able to silently pass malicious instructions to connected tools.
Prompt injection is not a theoretical risk. It is being actively exploited in real-world AI deployments today. The organisations best placed to manage it are those that treat AI inputs with the same scepticism they would apply to any other untrusted data source — because that is exactly what they are.
In the next post in this series, we look at data poisoning: how attackers manipulate an AI's behaviour not through what they say to it, but through what they fed it during training.