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

At a glance

What this is: This is an analysis of how Lakera aligns its GenAI controls to the OWASP Top 10 for LLM Applications (2025), with emphasis on lifecycle risk coverage and runtime protection.

Why it matters: It matters because IAM, NHI, and AI governance teams need controls that address agent behaviour before and during execution, not just after a policy violation is detected.

👉 Read Lakera's analysis of OWASP Top 10 for LLMs coverage in GenAI applications

Context

GenAI application security is no longer just a prompt-filtering problem. The core governance gap is that modern LLM systems can ingest data, call tools, emit output, and trigger downstream actions across the AI lifecycle, which makes identity, authorisation, and data protection part of the same control plane.

That matters for NHI and IAM programmes because many of the failure modes in GenAI map directly to privilege, secret handling, and runtime control issues. When an application can be over-permissioned, leak sensitive context, or turn user input into unauthorised action, the security model has moved beyond simple content moderation.

For teams building GenAI applications, the practical question is not whether to use OWASP guidance, but how to translate it into controls that work across development, deployment, and runtime. The right benchmark is whether identity governance keeps pace with how the system actually behaves.

Key questions

Q: How should security teams govern LLM applications that can call tools and access data?

A: Treat the LLM application as a delegated identity with bounded authority. Separate retrieval, tool access, and execution permissions, then review each integration as an access grant rather than a feature. If the model can reach sensitive data or trigger actions, identity governance, logging, and incident response must cover the full chain.

Q: Why do generative AI systems create more risk than simple chatbots?

A: Because many GenAI systems do more than generate text. They can retrieve data, call tools, and influence downstream processes, which turns a content issue into an authorisation issue. The moment the model can act on behalf of a user or workflow, poor privilege design can produce unauthorised access or harmful action.

Q: What do security teams get wrong about prompt injection?

A: They often treat prompt injection as a pure content filtering problem. In reality, the risk depends on what the model can reach after the injection succeeds. If tool access, memory, or data retrieval are over-broad, a single malicious prompt can become a privilege abuse event.

Q: How do you know if AI guardrails are actually working?

A: Guardrails are working when they block harmful behaviour without breaking legitimate workflows and when test results match runtime outcomes. Measure denied injections, blocked data leakage attempts, unsafe output rates, and whether privileged actions still require explicit policy approval. If the model can still cross trust boundaries silently, the guardrail is cosmetic.

Technical breakdown

Prompt injection and system prompt leakage in LLM applications

Prompt injection is an input manipulation technique that steers a model away from intended instructions by embedding hostile directives in user content, retrieved content, or adjacent context. System prompt leakage is a related failure mode where the model reveals internal instructions, policies, or security boundaries that were meant to stay hidden. In production LLM stacks, both issues become more dangerous when the model has access to tools, memory, or privileged data sources, because the prompt becomes a control surface rather than a simple interface. Runtime detection matters, but so does testing for these conditions before deployment.

Practical implication: test for injection and leakage at both design time and runtime, especially where the model can reach tools or sensitive data.

Excessive agency and over-permissioned LLM workflows

Excessive agency happens when a model or agent can take actions that exceed the intent of the requesting user, the workflow owner, or the surrounding policy. In practice, this is an identity and authorisation problem as much as an AI problem, because the system is being trusted to act within boundaries it cannot reliably infer on its own. The risk grows when tool access, retrieval access, and execution permissions are bundled together. Once that happens, a single successful prompt can become an access decision, a data access event, and an outbound action in one chain.

Practical implication: separate read, write, and execute privileges for GenAI workflows and review every tool grant as an identity decision.

Data leakage, output handling, and model behaviour evaluation

Sensitive information disclosure and improper output handling show why LLM security cannot stop at input classification. A model may surface personal data, proprietary context, or unsafe output even when the original request looks benign, especially if the retrieval layer, logging layer, or downstream consumer is weakly controlled. That is why pre-deployment red teaming and runtime guardrails need to be paired with system design that constrains where data enters, how it is transformed, and where it can leave. OWASP-style risk mapping is useful because it links model behaviour to operational failure modes rather than abstract AI risk language.

Practical implication: treat output pathways, retrieval sources, and logging as part of the security boundary, not as neutral plumbing.

NHI Mgmt Group analysis

LLM security is now an identity and privilege problem, not only a content problem. The article’s core value is that it maps generative AI risk to controls across the full lifecycle, including prompt attack detection, data-leak detection, and behaviour evaluation. That is the right framing for practitioners because the most damaging failures occur when a model can access something it should not, not merely when it produces a bad answer. The implication is that GenAI governance must be tied to authorisation boundaries, not just moderation rules.

Excessive agency is the clearest example of governance drift in AI systems. When a model can decide how to route a request, what context to retrieve, and which tools to call, the security issue is no longer simple misuse by a user. It becomes a privilege boundary problem, because the system is acting inside delegated authority with more freedom than traditional IAM assumptions allow. Practitioners should recognise that this is the same class of control failure as over-permissioned NHI, but with faster and less predictable execution.

Prompt attack, data leakage, and output abuse need different control types, not one universal guardrail. The article shows the value of separating development-time testing from runtime protection, which is a useful discipline for AI governance programmes. A red-team finding is not the same thing as a runtime detection rule, and neither is the same thing as a policy decision about who may connect the model to business data. The implication is that teams need layered control ownership across security, engineering, and identity governance.

OWASP-style risk mapping gives AI security teams a shared language, but the organisation still has to define who owns each boundary. Framework alignment helps with consistency, yet it does not remove the need to decide whether an issue belongs to the IAM team, the platform team, the ML team, or the risk function. That ownership question matters most where a model can cross from text generation into action. Practitioners should treat each LLM integration as a delegated access relationship that must be governed explicitly.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented policies to govern AI agents, according to SailPoint research, even though 92% say governance is critical.
• For a broader control lens, read OWASP Agentic AI Top 10 for how agentic risks map to runtime and lifecycle controls.

What this signals

The practical signal for programmes is that GenAI governance must be measured as an identity and access control problem, not as a prompt-safety project. If teams cannot trace which data sources, tools, and execution rights a model can reach, they do not have a security boundary, they have a probability boundary.

Agent authority creep: once a model can move from suggestion to action, the review cadence used for human access becomes too slow to be meaningful. That is why OWASP-style lifecycle mapping needs to sit beside entitlement management, not beside content policy alone.

With 80% of organisations already reporting AI agents acting beyond intended scope in the SailPoint research, the operating assumption should change from trusted output to bounded action. Use that shift to prioritize control ownership, logging, and restricted delegation paths before more workflows depend on model-driven decisions.

For practitioners

• Separate model access from execution rights Do not let the same identity handle prompt ingestion, tool invocation, and outbound action approval. Split read, write, and execute permissions so a model compromise cannot immediately become a privileged workflow.
• Red-team for prompt and output abuse Test for direct injection, indirect injection, system prompt leakage, unsafe output handling, and data exfiltration before production. Re-test after every major prompt, tool, retrieval, or policy change.
• Treat retrieval layers as governed identity surfaces Inventory which sources the model can query, which principals can influence retrieval, and which datasets are exposed through embeddings, plugins, or memory. Apply access review to those paths as you would to other non-human identities.
• Define ownership for AI boundary controls Assign clear accountability for data exposure, tool permissioning, runtime detection, and incident response. If those controls sit between teams, model risk will outpace the programme’s ability to respond.

Key takeaways

• GenAI security fails when teams treat model behaviour as separate from identity and access control.
• OWASP alignment is useful because it separates prompt, data, output, and agency risks into distinct failure modes.
• Practitioners should govern AI systems as delegated actors with explicit boundaries, reviewable rights, and measurable enforcement.

Key terms

• Prompt Injection: A prompt injection is a malicious instruction embedded in user input or retrieved content that attempts to override the model's intended behaviour. In production systems, it becomes a security issue when the model can act on the injected instruction through tools, memory, or data access.
• Excessive Agency: Excessive agency is the condition where a model or agent can take actions beyond the intended scope of the request or workflow. The risk is not just bad output. It is unauthorized behaviour enabled by permissions, integrations, or delegated execution paths that were too broad.
• Runtime Guardrail: A runtime guardrail is a control that inspects model inputs, outputs, or actions while the application is live. It aims to detect or block harmful behaviour in real time, but it is only effective when paired with restricted privileges and well-defined system boundaries.

What's in the full article

Lakera's full article covers the operational detail this post intentionally leaves for the source:

• The per-risk coverage table showing which OWASP LLM issues Lakera Guard addresses strongly, partially, or not at all.
• The distinction between Lakera Red testing and Lakera Guard runtime protection across the AI lifecycle.
• The product-specific examples of prompt attack detection, content filtering, and custom guardrail design.
• The article's detailed mapping of supply chain, poisoning, and output-handling gaps to specific controls.

👉 The full Lakera article includes the OWASP-by-OWASP coverage breakdown and lifecycle control mapping.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.