Prompt injection is the number one risk for enterprise applications using language models, according to OWASP, which has maintained its top spot in its Top 10 list for the second year running. It's not a theoretical scenario or a laboratory problem: it's a direct consequence of how these systems work.
A language model does not distinguish between the instructions given to it by its developer and the text it processes. Everything arrives as words. If a document the system reads contains something in the form of an instruction, there is a possibility that it will treat it as such.
The known version —a user writing "ignore your instructions"— is the least worrying, because the attacker has to be present and their permissions are those of any other user.
The version that matters in a business environment is the indirect injectionThe malicious text is not written by the user; it comes within the content that the system processes as part of its normal work.
The usual vectors:
In every case, the process is the same: someone external writes text that your system will read and that can influence what it does. And in every case, the potential damage is exactly equal to the scope of the permissions you've granted them.
The intuitive answer is to filter out suspicious instructions at the input. This doesn't work reliably, for three reasons:
Language has infinite forms. Any list of prohibited patterns can be rephrased. The instruction can be in another language, paraphrased, or broken down into several sentences.
It may be hidden. Blank text on a blank page in a PDF, metadata, content that the user doesn't see but the system does read.
The filter cannot know the intention. A legitimate email might contain the phrase "please forward this to accounting." The system has no robust way of deciding whether that's an instruction for itself or information for a person.
The operational conclusion is both uncomfortable and clarifying: We have to assume that the injection will happen and design so that it doesn't matter.
Principle | What does it involve? | What it prevents |
|---|---|---|
Minimum permit | The system only accesses what its specific task requires | That an injected instruction reaches external data |
Channel separation | External content is never treated as a system instruction | Let a PDF redefine behavior |
Whitelist of shares | Only explicitly listed operations are permitted | That something unforeseen happens |
Human validation in the irreversible | Payments, external communications, production changes | That the damage materializes without review |
Full registration | It records what was entered and what was executed. | That the incident is irreparable |
These five are architectural decisions, not tool configurations. And all five cost little if made before building, which is why this article belongs more to a design conversation than a security one.
OWASP adds two related risks to this table that should be mentioned: LLM02, disclosure of sensitive information, and LLM06, excess capacity. The three present the same problem viewed from different angles: what the system can read, what it can do, and who can influence it. We have developed this in Granting permissions to an agent is a risky decision
Imagine an assistant that processes invoices arriving in the administration email: it extracts the amount, supplier, and account number, and prepares the payment.
A fraudulent supplier sends an invoice that includes a small instruction at the bottom to the system to use a different account number. If the assistant has permission to prepare payments and no one verifies the account number against the supplier's record, the fraud is executed with the efficiency of an automated system.
Note that in this example the model hasn't failed: it has done exactly what a text asked it to. The flaw lies in the design, which allowed an external text to determine a critical piece of information without verifying it against the source of truth.
Hence the rule we repeat in every project: The model drafts and interprets; the system decides the facts.. Amounts, accounts, statuses, and permissions are checked against the source system; they are never accepted from processed content.
When someone presents an AI-powered solution that reads external content, three questions separate the serious from the improvised:
A provider who responds "our model doesn't fall into that trap" hasn't grasped the risk. Containment doesn't depend on the quality of the model, it depends on the scope that has been granted to it.
It is the manipulation of a language model's behavior through text that the model processes as if it were instructions. OWASP ranks it as the top risk in its Top 10 for LLM applications by 2025, because the model does not structurally distinguish between the developer's instructions and the content it analyzes.
This is the relevant variant in business environments: the instructions are not written by the user, but come within the content that the system routinely processes — a supplier email, a PDF, a web page, a support ticket, or a form field.
Not reliably. Language allows for infinite reformulations, instructions can be hidden in invisible text or metadata, and a filter cannot determine intent. The correct approach is to assume it will happen and limit the potential harm through permissions and controls.
With five design principles: minimum permission per task, separation between external content and system instructions, whitelist of allowed actions, mandatory human validation in irreversible operations, and complete logging of inputs and actions performed.
Yes, if the system processes them and has broad permissions. The typical example is an invoice that includes an instruction to change the payment account number. The problem isn't with the model itself, but with the design that allows external text to determine critical data without verifying it against the source.
What happens if the processed content includes instructions directed at the system? What can the system do in the worst-case scenario? And could an incident that occurred a month ago be reconstructed? An answer that denies the possibility of an attack indicates a lack of awareness of the risk.
Does your AI system read content written by third parties? We review scope, permissions, channel separation, and traceability, and tell you what the worst possible scenario is with the current design. Request a review →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
