OWASP Top 10 for LLMs: what Lakera’s coverage changes

At a glance

What this is: Lakera maps the OWASP Top 10 for LLM Applications (2025) to development and runtime controls, showing that GenAI risk spans prompt attacks, data leakage, excessive agency, output abuse, and partial coverage for supply-chain risk.

Why it matters: IAM, PAM, and AI governance teams need this split because LLMs are being secured as operating systems for access and action, not just as text generators.

Context

LLM security is now a governance problem, not just a content-moderation problem. Once a model can reach tools, data, or downstream workflows, the real question becomes who controls the conditions under which it can act, what it can expose, and where review happens across the lifecycle.

Lakera’s article frames the OWASP Top 10 for LLMs as a production control map rather than a model-only checklist. That matters because development-time testing, runtime filtering, and permission boundaries solve different problems, and teams that collapse them into one layer miss the actual failure modes.

For identity programmes, the key issue is that LLMs behave like non-human actors when they are connected to systems of record, but many controls still assume static permissions and human-paced review. That mismatch is now visible in deployment design, not just in theory.

Key questions

Q: What breaks when LLMs are protected only with runtime filters?

A: Runtime filters can reduce harmful prompts and outputs, but they do not solve upstream poisoning, dependency compromise, or over-scoped tool access. If the model can still reach privileged systems or inherit unsafe context, the control is only covering the last step of the chain, not the conditions that created the risk.

Q: Why do LLMs create risk in identity and access management?

A: LLMs create risk when teams confuse fluent answers with verified security evidence. A model can summarize access patterns quickly, but it can also hide missing context, stale data, or inaccurate scope. In IAM, that means every output needs traceability back to the underlying identities, entitlements, and events.

Q: How do organisations decide when an LLM is safe enough for production use?

A: They should evaluate the exact workflow, not the model in isolation. Safe enough means the system can verify claims, handle uncertainty, and prevent unreviewed output from changing records, access, or customer outcomes. If those safeguards are missing, the model is not production ready for that use case.

Q: What is the difference between model behaviour testing and runtime protection for LLMs?

A: Model behaviour testing looks for weaknesses before deployment, such as injection sensitivity or disclosure tendencies. Runtime protection inspects live traffic and output to stop harmful behaviour as it happens. The first finds latent risk, while the second limits impact after the system is already in use.

Technical breakdown

Prompt injection and sensitive data disclosure in LLM apps

Prompt injection is an input manipulation problem. Attackers try to override the model’s intended behaviour by embedding instructions in user prompts, retrieved content, or adjacent data. Sensitive data disclosure follows the same pathway when the model is induced to reveal secrets, PII, or internal context that should never have been available to the session in the first place. In practice, this is an application integration issue as much as a model issue: the system must decide what the model can see, what it can pass onward, and what gets filtered before output leaves the boundary.

Practical implication: Treat the LLM as part of the access path and restrict what data reaches the prompt and output pipeline.

Excessive agency and permission boundaries for agentic systems

Excessive agency appears when an LLM is allowed to take actions that exceed the task it was meant to perform. The risk is not only model behaviour, but the mismatch between the model’s action surface and the permissions attached to tools, APIs, or workflows. Lakera’s mapping shows this is partly a design issue: runtime detection can catch abuse attempts, but the deeper control is whether the system can act beyond its intended scope at all. Once the model can chain requests into external actions, identity and authorisation become part of the model’s threat surface.

Practical implication: Constrain tool access and authorize each action at the narrowest possible scope before the model can execute it.

Why supply-chain risk is only partially covered by runtime protection

Supply-chain risk sits outside the reach of runtime guardrails because it concerns how a model, dependency, or package was built and delivered, not just how it behaves once live. That means poisoned components, compromised dependencies, and other upstream integrity failures can survive into production even when runtime checks are active. Lakera’s own mapping is explicit that evaluation can observe model behaviour, but it cannot verify provenance, integrity, or tamper resistance in the surrounding supply chain. This is why lifecycle controls and build trust matter alongside operational filters.

Practical implication: Pair runtime inspection with provenance and dependency controls rather than assuming model behaviour testing covers supply-chain trust.

Threat narrative

Attacker objective: The attacker wants the LLM application to disclose data, ignore guardrails, or perform actions that expand the blast radius beyond its intended role.

1. Entry begins when malicious prompts, retrieved content, or poisoned inputs reach the LLM application and shape the model’s behaviour.
2. Credential or data exposure follows when the model is induced to reveal sensitive information, internal instructions, or context that should have stayed private.
3. Escalation occurs when excessive agency lets the model trigger downstream tools or workflows beyond the intended task boundary.
4. Impact lands as unauthorized action, leaked data, manipulated output, or exposure of connected systems and users.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM security has moved from prompt filtering to lifecycle governance. The 2025 OWASP map makes one thing clear: the control problem begins before inference and continues after output. That means development-time red teaming, runtime protection, and upstream integrity checks are different layers of the same governance model, not interchangeable features. Practitioners should stop treating LLM security as a single control plane.

Excessive agency is an identity problem before it is an AI problem. Once an LLM can call tools or trigger workflows, the question is no longer only what the model says, but what authority it carries into external systems. The governance issue is whether the action surface is constrained to the task, or whether the model can turn language into unauthorized execution. Security teams need to treat action scope as part of identity design.

Supply-chain risk is the clearest example of where runtime controls stop. Lakera’s own mapping acknowledges that some LLM risks can be evaluated but not fully prevented at the point of use. That distinction matters because provenance, dependency integrity, and model delivery trust are upstream questions, not output-sanitization questions. The implication is simple: if integrity is not governed before deployment, runtime guardrails arrive too late.

OWASP-style LLM coverage is becoming the common language for AI governance, but coverage is not control. Framework alignment helps teams compare risks consistently, yet the real programme decision is where each risk is owned: application security, IAM, data governance, or model operations. That shared taxonomy is useful only if it forces clearer accountability across teams. Practitioners should use the framework to assign ownership, not to assume resolution.

Trust assumptions around LLMs are now breaking at the boundary between human intent and machine action. The model may appear conversational, but once it can retrieve, transform, and execute, its governance must resemble workload and delegated identity control. That is where identity teams, AI teams, and security architecture teams finally converge. The field should expect more postures built around scoped authority, not around content inspection alone.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Generative AI use specifically increased from 33% in 2023 to 79% in 2025, according to McKinsey’s Global Surveys on the State of AI.
• Read next: Agentic AI Security Guide

What this signals

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That pattern reinforces the core governance point in this article: the LLM itself is only one layer in a broader identity and secrets exposure surface.

LLM security programmes should be organised around control boundaries, not product boundaries. Prompt safety, tool authorization, supply-chain integrity, and disclosure prevention sit in different ownership domains, and the article’s framework mapping is most useful when it forces those boundaries to be explicit. Teams that treat all AI risk as a single “runtime” problem will keep missing the upstream trust layer.

Action scope is the new pressure point for GenAI governance. The moment an LLM can trigger tools or data access, it inherits a delegated identity problem that conventional content filtering cannot solve. Security architecture should therefore be designed around scoped authority and separate approval paths, not around the assumption that safer text equals safer behaviour.

For practitioners

• Map LLM controls by lifecycle stage Separate development-time testing, runtime filtering, and supply-chain assurance into distinct control owners and success criteria so coverage gaps are visible.
• Restrict tool-facing permissions Treat every connected API, workflow, or data source as a privileged boundary and grant only the minimum action scope required for the task.
• Test for prompt injection and disclosure paths Run adversarial evaluations against user prompts, retrieved content, and system instructions to see what the model can be made to reveal or do.
• Add provenance checks for upstream model risk Verify model, dependency, and package integrity before deployment so runtime guardrails are not carrying supply-chain trust on their own.
• Create explicit escalation limits for AI actions Define where the model may suggest, where it may stage, and where human approval is still required before external side effects occur.

Key takeaways

• LLM risk now spans the full lifecycle, from adversarial testing to live enforcement and upstream trust controls.
• The most important control gap is not one bad prompt, but the combination of exposed context, excessive agency, and weak supply-chain assurance.
• Teams should govern LLMs as delegated actors with scoped authority, separate ownership, and controls that match the stage where each risk appears.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
• Supply Chain Risk: Supply chain risk is the chance that a weakness, failure, or compromise in an external supplier, partner, or upstream dependency will affect your organization. It includes software, hardware, cloud, data, and service dependencies, where trust, integrity, availability, or confidentiality can be disrupted through third-party access, updates, or operational failure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.