OWASP LLM Top 10 clarifies the security gaps in GenAI apps

At a glance

What this is: A practical overview of the OWASP Top 10 for LLM applications that maps the main GenAI security risks to concrete mitigations.

Why it matters: It matters because LLMs can expose identity, data, and control-plane weaknesses that cut across NHI, autonomous, and human identity programmes.

👉 Read Lasso Security's guide to the OWASP Top 10 LLM vulnerabilities

Context

LLM application security fails when teams treat model behaviour as separate from identity and access control. Prompt injection, sensitive information disclosure, supply chain compromise, and excessive agency all become governance problems once an LLM can read data, invoke tools, or shape downstream actions.

For IAM, PAM, and NHI teams, the useful question is not whether an LLM is clever, but which permissions it inherits, which outputs are trusted, and which actions are allowed to proceed without review. The article is a broad checklist guide, not a breach report, so the value lies in translating model risks into control boundaries.

Key questions

Q: How should security teams implement controls for LLM applications that can access sensitive data?

A: Start by separating model context, retrieval sources, and execution paths so that untrusted text cannot directly influence privileged actions. Then require validation for outputs before they are used in code, customer responses, or access decisions. If the application can touch secrets or records, apply the same governance discipline you would use for any privileged identity.

Q: Why do LLM applications complicate identity and access management?

A: They complicate IAM because the model can sit between a user, a data source, and an action without being a traditional identity in the human sense. That makes authorisation harder to reason about, especially when the system can retrieve data, call tools, or generate outputs that later become operational decisions.

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

A: They often treat prompt injection as a content-filtering problem alone. In practice, it is a trust-boundary problem. If untrusted input can reach the model, and model output can reach privileged workflows without review, the attack path is already open even when the prompt itself looks harmless.

Q: Who should be accountable when an LLM triggers an unauthorized action?

A: Accountability should rest with the team that granted the LLM its reach, defined its permissions, and allowed the action to proceed without adequate gating. The right governance model treats the model as a system component with delegated authority, not as a black box that sits outside ownership.

Technical breakdown

Prompt injection and output trust boundaries

Prompt injection works because LLMs can be steered by untrusted text that enters the model context alongside legitimate instructions. Once that context is polluted, the model may reveal data, ignore prior intent, or generate outputs that the surrounding application treats as authoritative. In practice, the weakness is not just the prompt itself. It is the assumption that model output can be used downstream without a trust boundary, policy check, or content validation layer.

Practical implication: separate model output from execution paths and validate any text that could influence access, disclosure, or code execution.

Supply chain vulnerabilities in LLM applications

LLM supply chains include training data, plugins, embeddings, external APIs, and third-party services that can all alter the integrity of the application. A compromised dependency can inject tainted instructions, leak credentials, or change model behaviour without touching the model weights directly. That makes the LLM stack more like a distributed identity environment than a single application. Security teams need to think about provenance, trust, and revocation across every external component that the model can read from or call into.

Practical implication: inventory every LLM dependency and enforce provenance checks, review gates, and revocation paths for external integrations.

Excessive agency in LLM-enabled workflows

Excessive agency appears when an LLM is allowed to take material actions rather than simply recommend them. The risk is not that the model is autonomous in the strict agentic sense, but that it can make decisions that alter money, data, or privileges without strong human or policy constraints. In identity terms, this is where operational intent collides with delegated power. The control problem is defining what the model may suggest, what it may trigger, and what must remain gated by a person or a policy engine.

Practical implication: classify every LLM action by blast radius and require approval for anything that changes access, data, or financial state.

Threat narrative

Attacker objective: The attacker aims to turn model trust into operational abuse, data exposure, or unauthorized downstream action.

1. Entry occurs when a malicious prompt, tainted dependency, or compromised plugin reaches the LLM application through a normal user or supply chain path.
2. Escalation follows when the model treats injected instructions or unsafe outputs as trustworthy and reveals sensitive data, executes harmful code paths, or triggers unintended actions.
3. Impact lands when those actions propagate into exposed records, unauthorized transactions, or broader compromise of connected systems and identities.

Breaches seen in the wild

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

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OWASP’s LLM Top 10 is really an identity boundary document, not just an application checklist. The article’s risks all converge on one issue: who or what is trusted to influence model behaviour, output handling, and downstream action. Once an LLM can ingest external content, call tools, or shape privileged workflows, the security problem becomes identity, not just prompt hygiene. Practitioners should treat LLM risk registers as control-boundary design work.

Excessive agency is the first OWASP LLM risk that starts to look like agentic governance. The article stops short of full autonomy, but it already shows why model-assisted action needs stricter controls than ordinary application logic. When an LLM can make or trigger decisions that change state, the relevant question is no longer only output quality. It is who owns the authority to convert that output into action, and what gates remain in place before that happens.

Supply chain vulnerability in LLM systems is really identity sprawl in a new form. Plugins, third-party APIs, embedded data sources, and model-adjacent services all become part of the trust surface. That means the old distinction between software integrity and identity governance is breaking down. Practitioners need to account for every external component that can read context, return instructions, or inherit access to sensitive data.

Prompt injection exposes a named concept we should use more often: context trust collapse. This is the point where the system can no longer distinguish between instructions, content, and attacker-controlled text inside the same context window. The result is not just a bad answer. It is a failure of the assumption that model context is safely interpretable without stronger policy enforcement. Teams should design for untrusted context from the start, not as a later hardening step.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a wider control lens, see OWASP NHI Top 10 for the risks most likely to surface as LLM workflows move toward agent-like behaviour.

What this signals

Context trust collapse: LLM programmes fail fastest when teams assume prompts, retrieval sources, and tool outputs can share the same trust level. As usage expands, security leaders should map which workflows can influence data, secrets, or access and isolate those paths with the same discipline used for privileged identities. The OWASP framing is useful, but the operating model has to be stricter than a checklist.

The practical signal for practitioners is that LLM security will increasingly sit at the intersection of application security, secrets management, and identity governance. When model-driven workflows can reach credentials or downstream systems, the control model should align with OWASP Non-Human Identity Top 10 and zero-trust thinking, not generic content moderation.

For practitioners

• Define trust boundaries around model inputs and outputs Separate user content, system instructions, retrieval data, and tool responses so that no single text channel can silently steer privileged behaviour. Apply content validation before any model output is used in code, customer interactions, or access decisions.
• Inventory every LLM dependency and plugin List the APIs, models, extensions, and data feeds that each LLM application can reach, then require review and revocation paths for any dependency that can alter output or access sensitive context. Include third-party services in the same control register as internal components.
• Gate state-changing actions behind policy checks Require human approval or policy-engine approval before any LLM output can change permissions, send money, expose records, or trigger automation with meaningful business impact. Treat those actions as privileged operations, not ordinary application behaviour.
• Classify LLM usage by blast radius Separate read-only assistants from systems that can access secrets, customer data, or operational tools, then tighten monitoring as the blast radius expands. The same model can be low risk in one workflow and high risk in another.

Key takeaways

• LLM security is fundamentally a trust-boundary problem because untrusted text can influence outputs that downstream systems treat as authoritative.
• Supply chain components, plugins, and exposed secrets expand the attack surface far beyond the model itself.
• Teams should classify every LLM action by blast radius and gate any state-changing step with policy or human approval.

Key terms

• Prompt Injection: A prompt injection is an attacker-controlled instruction embedded in text that causes an LLM to behave in ways the application did not intend. The risk is not limited to bad answers. It can also steer tool use, data disclosure, and downstream actions if the application trusts model output too readily.
• Excessive Agency: Excessive agency is the condition where an LLM is given authority to take meaningful actions instead of merely recommending them. In practice, this becomes a governance issue when the model can trigger payments, change access, or influence operational systems without strong approval controls.
• Model Supply Chain: The model supply chain is the set of external and internal components that shape an LLM application, including data sources, plugins, embeddings, APIs, and third-party services. Security teams must govern it as a trust surface because compromise can alter behaviour without changing the core model.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Lasso Security: OWASP Top 10 LLM Vulnerabilities and Security Checklist. Read the original.