What is a key security concern when using generative AI? Prompt injection, and the nine behind it

The most cited key security concern when using generative AI is prompt injection, which OWASP ranks first in its Top 10 for LLM Applications. That list, published as version 2.0 in November 2024 by the OWASP GenAI Security Project, is the recognised baseline for the question. Prompt injection leads it because of a structural property of language models rather than a mistake in any particular product.

Why prompt injection is the answer

Because instructions and data arrive through the same channel, and nothing in the architecture separates them.

A language model receives one stream of text. Whatever an application puts at the front as a system prompt, whatever the user types, and whatever the model reads from a document, a web page or an email all enter the same way. The model has no reliable mechanism for deciding that one part of that stream is an instruction and another part is merely content to be processed.

So text the model encounters can behave like a command. A line buried in a page it summarises, a comment in a file it reviews, or an instruction in an incoming email can redirect what it does next. Our prompt injection explainer goes through the mechanics in detail.

Filtering reduces the problem and does not remove it, because there is no syntactic marker that distinguishes a malicious instruction from a legitimate one. That is why the entry has stayed at the top of the list between editions rather than being solved and demoted.

The list, in order

OWASP's 2025 edition reads: LLM01 prompt injection, LLM02 sensitive information disclosure, LLM03 supply chain, LLM04 data and model poisoning, LLM05 improper output handling, LLM06 excessive agency, LLM07 system prompt leakage, LLM08 vector and embedding weaknesses, LLM09 misinformation, LLM10 unbounded consumption.

Two entries are new. System prompt leakage addresses the exposure of the instructions an application gives a model, and vector and embedding weaknesses reflects how many applications now retrieve from a vector store before answering.

Two were renamed in ways that widened them. Training data poisoning became data and model poisoning, extending it from the dataset to the model itself. Denial of service became unbounded consumption, extending it from availability to cost.

And one moved up. Sensitive information disclosure rose to second, displacing insecure output handling, which is now LLM05 improper output handling.

The two that cause most of the damage

Prompt injection gets the attention. Improper output handling and excessive agency are usually what turn an injection into an incident.

Improper output handling is passing model output into another system without validating it. A generated string becomes a database query, a shell command, a file path or markup rendered in a browser. The principle is simple and routinely forgotten: model output is untrusted input to whatever consumes it next, and every classical injection defence still applies downstream.

Excessive agency is granting a model more permission, autonomy or tool access than the task requires. A model that can read a database is a disclosure risk. One that can write to it, send email, call an API or move money has been handed the ability to act. The mitigation is ordinary least privilege applied to the model as though it were an untrusted user, because functionally it is one.

Put those two together with prompt injection and you have the shape of almost every serious reported failure in this area: a model was persuaded to do something, its output was trusted, and it had the permissions to make that matter.

The entries that are procurement problems

Three of the ten are not solved by anything in your own code, which is worth separating out before an engineering team tries.

Supply chain, LLM03, covers the models, datasets, libraries and services you did not build. The questions are provenance, whether you are told when a model changes underneath you, and what you can verify about anything you pull from a public repository.

Data and model poisoning, LLM04, covers corrupted training data and tampered model weights. For anyone using a third-party model, this is entirely a matter of what the provider does and what it tells you.

Sensitive information disclosure, LLM02, sits across the boundary. Some of it is your data handling, and some of it is what the provider does with what you send, which is a contract question rather than a code question.

Where the system prompt fits

Not where most people assume, and this is the practical lesson in LLM07.

A system prompt is an instruction, not a security boundary. Anything placed in it is potentially retrievable by a determined user, and the new entry exists because applications routinely put business logic, pricing rules, internal system names and policy text in there.

The consequence is a rule rather than a technique: do not put anything in a system prompt that would matter if a user read it, and do not use it as an access control. If a user must not see certain data, the data must not reach the model, and no instruction telling the model to keep a secret is a substitute.

What retrieval adds to the problem

The new vector and embedding entry exists because the architecture changed faster than the guidance.

Most serious applications now retrieve relevant documents before answering, which introduces three distinct risks. A poisoned document in the retrieval corpus becomes an injection vector that reaches every user who triggers it. Embeddings can leak information about the text they encode. And access control applied at the document level but not at the chunk level lets a user retrieve fragments of material they should not see.

The last of those is the quiet one. A permissions model that was correct for a document store is frequently incorrect once that store has been split into chunks and indexed, and the failure is silent.

What misinformation means in this list

LLM09, and it is the entry most likely to be dismissed as not a security problem.

It covers the application presenting incorrect model output as reliable, with consequences that follow from somebody acting on it. That includes fabricated citations, invented package names in generated code, and confidently wrong factual claims inside a product that implies verification.

The security framing is specific rather than general hand-wringing about accuracy. If generated code references a package that does not exist, an attacker can register that name and wait, which converts a model's tendency to invent into a supply chain attack. If an application presents unverified output inside an interface users treat as authoritative, the design has created a risk the model alone did not.

The mitigation is interface honesty plus verification where it matters: show sources, make the uncertainty visible, and check anything that will be acted on automatically.

Where this sits against other standards

The OWASP list is an application security checklist, and it is not the only document in the space.

Governance frameworks address organisational process: who signs off, what gets documented, how risk is assessed and recorded. Those answer a different question and they do not tell an engineer what to validate before rendering model output in a browser.

The OWASP list is deliberately narrow in exactly that way. It names ten concrete technical risks with mitigations, which is why it is the thing security questionnaires and assessments quote, and why it is the right answer when the question is phrased as a key security concern rather than as a governance obligation.

How to use the list

As a checklist rather than a framework to reason from, which is the point of a published top ten.

Walk your application against each of the ten and write down what you actually do about it. The entries that most often come back blank are improper output handling, excessive agency and unbounded consumption, in that order, because the first two feel like model problems and the third feels like a billing problem.

Then separate what is yours from what is your vendor's. Supply chain and poisoning are answered in a contract and a procurement standard. Prompt injection, output handling, agency and consumption are answered in your own code. Confusing the two produces security reviews where everyone agrees a risk is real and nobody owns it.

The short version

The single answer to what is a key security concern when using generative AI is prompt injection, ranked LLM01 in the OWASP Top 10 for LLM Applications, and the reason is architectural rather than accidental.

The more useful answer is that it is a list of ten, that two entries are new in version 2.0, and that the ones which convert a bad answer into a real incident are improper output handling and excessive agency.

This article summarises a published security standard. For implementation, use the OWASP documents themselves.