OWASP LLM Top 10 (2025) — Reading It Like a Builder, Briefing It Like a CISO

OWASP's Top 10 for LLM Applications has become the de facto reference that boards, auditors, and platform teams now triangulate against. The 2025 update reorders the list in light of 18 months of public incidents — from indirect prompt injection via support tickets at a major SaaS, to embedding inversion attacks against open RAG endpoints, to a $2M cloud bill triggered by an unbounded agent loop.

This piece is written for two readers: the CISO who needs a 30-second board narrative, and the staff engineer who has to close out the controls by Friday. Both views are required — an LLM security program that lives only in slides will fail at the first agentic deployment, and one that lives only in code will be defunded.

The list, in 2025 attack-surface order

OWASP keeps the LLM01–LLM10 numbering, but the underlying weight of each item has shifted. Below is the 2025 ordering with the operational verdict from our incident response practice.

LLM01 + LLM06 — the paired control nobody plans for

Across the incidents we triaged in 2024 and the first half of 2025, two-thirds began with a prompt injection delivered through trusted-looking content (a calendar invite, a Jira comment, a PDF) and ended only because the agent had the authority to act. Either failure alone would have been a near-miss. The combination is the breach.

The architectural fix is to refuse to give a single model both untrusted text and high-authority tools. Run untrusted input through a 'view-only' model that produces a small, schema-constrained summary. A second model — the planner — receives only the summary and is the only one allowed to call tools.

The reference architecture that holds in production

Below is the simplified topology we now recommend for any agent that can take an irreversible action (write to a database, send a message, move money, deploy code). It is the single change with the largest defense-in-depth payoff per engineer-hour.

# Untrusted text NEVER reaches a tool-enabled model directly.

[ untrusted_input ]               (email, ticket, PDF, web page)
        │
        ▼
[ view_only_llm ]                 (no tools, no system prompt secrets)
   produces strict JSON:
     { intent, entities, risk_flags, summary≤256w }
        │
        ▼
[ schema_validator ]              (zod / pydantic / proto)
        │
        ▼
[ planner_llm ] ───► [ tools ]    (least-privilege, scoped per user
   sees ONLY the                    + per-tenant + per-resource)
   structured object.
        │
        ▼
[ irreversible_action_gate ]      (human-in-the-loop OR
                                   policy engine, e.g. OPA)
        │
        ▼
[ audit_log + replay_index ]      (SIEM-bound, tamper-evident)

LLM02 + LLM07 — sensitive disclosure and system-prompt egress

These are usually treated as separate items but they share a root cause: the model has access to information that the requesting user does not. System prompts containing API keys or business rules, retrieved RAG chunks from another tenant, training data memorized verbatim — all leak the same way: the model is asked, directly or obliquely, to repeat what it knows.

The control is data minimization at the context layer, not output filtering. If the model never sees the secret, it cannot leak it. Concretely: scope every retrieval to the calling identity, strip secrets from system prompts (use environment-bound tool authentication instead), and log every retrieved chunk with the identity it was returned to so you can audit cross-tenant exposure after the fact.

• 01Per-identity retrieval — tenant ID and ACL filters are query-time, not post-filter
• 02No secrets in system prompts — tools authenticate via the runtime, not the model
• 03Output egress monitoring — flag any response containing high-entropy strings or known secret patterns
• 04Synthetic canary documents — seeded into RAG indexes per-tenant; their appearance in another tenant's response is a P1 alert

LLM08 — embedding inversion, the sleeper risk for RAG

Vector and Embedding Weaknesses became its own LLM Top 10 entry in 2025 because attacks moved from theory into the public domain. Embedding inversion — reconstructing the original text from its vector — has been demonstrated against OpenAI, Cohere, and Sentence-BERT embeddings with reconstruction quality high enough to leak sensitive snippets.

If you expose any cosine-similarity or vector-search API to the public internet — even an internal one to authenticated users with broad scope — assume the embeddings can be exfiltrated and inverted. The mitigation is the same zero-trust playbook as any other data store: scope by identity, rate-limit aggressively, and never allow raw embeddings to leave the security boundary.

LLM10 — Unbounded Consumption is a finance-team incident

Cost-side denial of service is the LLM risk that most often surprises CFOs. An agent that recursively calls itself, a token amplification attack via repeated tool returns, or a prompt-engineered loop can burn six-figure cloud spend in hours. Treat token spend like egress bandwidth: per-tenant budgets, hard ceilings, and circuit breakers that fail closed.

• 01Per-tenant per-day token budget (hard cap, not a soft warning)
• 02Per-conversation step ceiling — agents terminate at N tool calls, default N≤8
• 03Per-tool concurrency limit — prevents fan-out amplification
• 04Real-time spend anomaly detection — z-score on per-tenant token velocity

The four KPIs your board should see every quarter

Boards do not need ten LLM metrics. They need four that any non-technical director can interpret and that, taken together, prove the program is functioning.

A defensible 90-day plan

1. 01Days 0–30 — Inventory every LLM-touching system. For each, document: input sources (trusted/untrusted), tools available, authority level, and tenant model. This artifact alone often surfaces the LLM06 incidents you didn't know you were running.
2. 02Days 30–60 — Stand up the isolated-planner pattern in front of the highest-authority agent (the one with payment, deploy, or admin scope). Add per-tenant token budgets and the four board KPIs to your existing dashboard.
3. 03Days 60–90 — Move RAG retrieval behind per-identity ACL filters; instrument output egress monitoring; deploy canary documents per-tenant. Run a tabletop with the IR team using the OWASP scenarios — half will surface a control gap you can close in a sprint.

Closing — defenses are mature; discipline is the gap

There is no 2025 LLM threat in the OWASP Top 10 for which a working defense does not exist. Every item has a published mitigation, often several. The reason organizations are still being breached is that the AI feature roadmap is being shipped two quarters ahead of the AI security program, and the controls are being retrofitted under incident pressure rather than designed in.

The CISO's job for the next year is not to invent new controls. It is to make sure the existing ones — isolation, least authority, per-identity retrieval, irreversible-action gates, token budgets — are part of the same launch readiness review that already gates a database migration or a payment-flow change. Treat LLM features like any other production system, and the Top 10 stops being a backlog.