The OWASP Top 10 for Large Language Model Applications, maintained by the OWASP GenAI Security Project and updated for 2025, is the closest thing the industry has to a shared vocabulary for how AI applications get attacked. It is written for builders. This article reads it as a security team would: what does each risk look like in a deployment, and which of them can an outsider actually exercise?

The list, and what each one means#

  • LLM01 Prompt injection. Input, direct or hidden in content the model reads, that changes what the model does. The defining risk of the category and the one most often reachable from the internet.
  • LLM02 Sensitive information disclosure. The model reveals data it should not: other users' records, internal documents, credentials in its context, the system prompt itself.
  • LLM03 Supply chain. Compromised or poisoned models, datasets, adapters and plugins, pulled from registries with little verification.
  • LLM04 Data and model poisoning. Manipulating training or fine-tuning data to plant behavior, from subtle bias to backdoors.
  • LLM05 Improper output handling. Treating model output as trusted and passing it to a browser, a shell, a database or another system without validation. Classic injection, with the model as the vector.
  • LLM06 Excessive agency. Giving the model more tools, permissions or autonomy than its task needs, so that a manipulated model can do real damage.
  • LLM07 System prompt leakage. Exposure of the instructions the application relies on, which often contain logic, limits and sometimes secrets that should never have been there.
  • LLM08 Vector and embedding weaknesses. Attacks on retrieval-augmented systems: poisoning the documents a model retrieves, or extracting data from a shared vector store.
  • LLM09 Misinformation. Confident, wrong output that users act on, including fabricated references and code that does not do what it claims.
  • LLM10 Unbounded consumption. Requests designed to run up cost or exhaust capacity, sometimes called denial of wallet.

Which ones face the internet#

Security teams are used to splitting risks into those an outsider can exercise and those that need a foothold or an insider. The LLM list splits the same way. Prompt injection, sensitive information disclosure, improper output handling, excessive agency, system prompt leakage and unbounded consumption are all reachable by anyone who can send a message to the application. Supply chain, poisoning and embedding attacks mostly require access to the build pipeline or the data, and are controlled the way software supply chains are controlled.

That external set is where a CTEM program should start, because it is exactly what an attacker starts with: a chat box.

What an attack path looks like#

The risks combine. A typical path we validate runs like this: an assistant on a public site accepts a prompt injection hidden in a document the user asks it to summarize (LLM01); the injected instruction asks the assistant to call an internal tool it has access to (LLM06); the tool returns another customer's data, which the assistant repeats back (LLM02). Three items from the list, one conversation, one consequence. No single control on the list would have stopped it; the combination of a narrow tool permission and output handling would have.

Testing it from the outside#

  • Discover the endpoints first: assistants, chat widgets, model APIs, MCP servers. Many are not in the inventory because they were launched as experiments.
  • Treat each one as an unauthenticated user would, and attempt the externally reachable risks with realistic payloads, not canned strings.
  • Follow consequences, not responses. A model that says I cannot do that while the tool call already executed has still failed.
  • Keep the transcript as evidence, the same way you would keep a request and response for a web vulnerability.
  • Re-test after every change to the system prompt, the tools or the model version, because all three change behavior.

Where this fits in SecureX360#

SecureX360 treats AI applications as part of the attack surface, not a separate program. Discovery finds the assistants, agents and MCP servers attached to what you own; validation tests them from the outside the way it tests everything else, following the path from a prompt to a consequence; and the proof reaches the team that owns the application with the transcript attached. The OWASP list is the map. Validation is how you find out which roads are open.