By NHI Mgmt Group Editorial TeamBased on Lasso Security: “OWASP Top 10 LLM Vulnerabilities & Security Checklist” (June 9, 2026)

TL;DR: The OWASP Top 10 for LLM applications ranks the most common GenAI risks, from prompt injection and insecure output handling to supply chain vulnerabilities and excessive agency, and pairs each with prevention guidance, according to Lasso Security. The list matters because it turns LLM security from an abstract concern into a control checklist that IAM, security, and application teams can operationalise.


At a glance

What this is: This guide summarises the OWASP Top 10 for LLM applications and frames the main GenAI risks as a practical checklist for hardening model-driven apps.

Why it matters: It matters because IAM, security, and application teams need to govern not only model access but also prompts, plugins, outputs, and delegated actions across the full GenAI workflow.


Context

Large language model security is not a single control problem. The article groups the main risks into input manipulation, output misuse, training data compromise, availability attacks, third-party dependency exposure, and excessive agent-like decision scope, which means conventional application security reviews often miss where the real failure path starts.

For identity and access teams, the important point is that GenAI applications create new trust boundaries around who or what can influence the model, consume its output, or act on its decisions. That makes the governance question broader than prompt filtering alone, because the operational risk spans data, application logic, and delegated authority.

The article is aimed at practitioners who need a usable security checklist rather than a theoretical taxonomy. Its value is in connecting common OWASP-style control thinking to LLM-specific failure modes that can be evaluated during design, build, and deployment.


Key questions

Q: What breaks when prompt injection defenses are not in place for LLMs?

A: When prompt injection defenses are weak, attacker-controlled text can override the model's intended instructions, especially when the text arrives through retrieved content or external documents. The result is not always obvious compromise. It can be silent instruction hijacking, unsafe output, leaked context, or model behaviour that downstream systems trust too much.

Q: Why does excessive agency change how organisations govern GenAI?

A: Because the risk moves from what the model says to what the model can do. If an LLM can call tools, read internal data, or trigger actions, security teams must govern action scope, approval gates, and revocation paths the same way they govern privileged access.

Q: What do security teams get wrong about LLM supply chain risk?

A: They often focus on the core model and underweight the dependencies around it. In practice, compromised data providers, plugins, retrieval sources, or integrations can shape the model's behaviour as much as the model itself. The mistake is assuming third-party components are peripheral when they can directly influence trust and execution.

Q: How should organisations govern model output before it becomes an action?

A: They should require policy checks and approval gates wherever model output can change records, trigger transactions, or publish content. The key is to keep generation separate from execution so the model cannot directly exercise high-impact authority. That design reduces the chance that a single bad response becomes an operational incident.


Technical breakdown

Prompt injection and output handling in LLM applications

Prompt injection is an input-control failure where attacker-supplied text alters model behaviour or causes it to reveal information the application never intended to expose. Insecure output handling is the downstream version of the same problem: the model emits content that the application then trusts, renders, or executes without validation. Together, these two risks show that the security boundary in GenAI is not the model alone. It is the full input-to-output pipeline, including any place where model output becomes code, content, or workflow input.

Practical implication: validate inputs, constrain prompts, and sanitize outputs before they are rendered or reused.

Supply chain vulnerabilities and plugin risk in LLM apps

LLM applications often depend on external data providers, embeddings, plugins, extensions, or other third-party components that can shape model behaviour without being visible to end users. That creates a supply chain problem rather than a purely model problem, because compromised dependencies can alter training inputs, retrieval results, or execution paths. In practice, plugin design also expands the trusted computing base, since a weak extension can introduce injection, over-collection, or unsafe action execution even when the core model is unchanged.

Practical implication: inventory every external dependency and review what authority each plugin or data source can exercise.

Excessive agency and overreliance change the control model

Excessive agency describes the point where an LLM is allowed to take consequential actions without adequate guardrails, while overreliance describes human operators accepting model output without sufficient review. These are different problems but they interact, because the more autonomy an application has, the harder it is to rely on human correction after the fact. The governance shift is from reviewing outcomes to constraining permitted actions before they happen, especially where refunds, account changes, approvals, or content publishing are involved.

Practical implication: separate recommendation from execution and require approval gates for high-impact actions.


Threat narrative

Attacker objective: The attacker wants to manipulate model behaviour into producing disclosure, unsafe action, or service impact that the surrounding application treats as legitimate.

  1. Entry occurs when an attacker supplies a crafted prompt, poisoned training data, or a compromised third-party component that influences the LLM application.
  2. Credential access or control follows when the model is induced to reveal sensitive information, process unsafe output, or invoke a plugin with more authority than intended.
  3. Escalation happens when the application trusts the model's output or delegated action and turns it into a real system change, disclosure, or service disruption.
  4. Impact is achieved through data exposure, unauthorised transactions, corrupted decisions, or degraded availability across the GenAI workflow.

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

OWASP's LLM Top 10 makes one thing clear: GenAI security is a boundary problem, not a model problem. Prompt injection, output misuse, third-party exposure, and excessive agency all sit at different points in the same workflow. That means teams that only assess prompts or only assess the model are testing the wrong layer. The practical consequence is that GenAI governance has to follow the request, response, and action chain end to end.

Excessive agency is the most underestimated risk because it turns a model into an execution path. Once an LLM can approve, change, refund, publish, or route work, the control question changes from output quality to authorisation scope. That is a governance problem for IAM, application owners, and security architecture together. Practitioners should treat delegated action as a distinct trust boundary, not as a feature toggle.

Supply chain exposure is now a first-class LLM risk because model behaviour is increasingly shaped outside the model. Retrieval sources, plugins, fine-tuning data, and external services can all alter what the application knows and what it does. The named concept here is LLM trust expansion: every new dependency enlarges the set of places where attacker influence can enter the system. Teams should govern dependencies as part of the identity and data plane, not as separate implementation detail.

The OWASP Top 10 for LLMs is useful because it translates a fast-moving category into shared control language. That matters for boards and security committees as much as for engineers, because the risk taxonomy creates a common way to prioritise investment. The broader signal is that GenAI governance is converging with application security, IAM, and third-party risk management rather than sitting outside them.

LLM security programmes fail when they assume human review can always catch unsafe model behaviour after the fact. In practice, many risks are realised before a human sees the output, especially when the application chains retrieval, generation, and action. The implication is not just more review, but earlier policy enforcement at the point where the model is allowed to act.

From our research library:

What this signals

LLM trust expansion: GenAI applications become harder to govern as more of their behaviour is shaped by external inputs, retrieval systems, and plugins. Security teams should expect the control surface to expand beyond the model lifecycle and into the surrounding application stack.

The article's checklist aligns well with the direction of modern AI security practice: earlier policy enforcement, stronger dependency review, and tighter control over delegated actions. That is the right lens for programmes that need to govern model-driven workflows without assuming human review can always intervene in time, according to the State of Secrets Sprawl 2026


For practitioners

  • Map the full GenAI trust boundary Document every point where prompts, retrieval data, plugins, and outputs can change system behaviour. Treat the model as one component in a larger application path, not the whole control surface.
  • Constrain delegated model actions Separate suggestion from execution for refunds, approvals, account changes, publishing, and other high-impact functions. Require explicit approval or hard policy checks before the application converts model output into action.
  • Inventory third-party dependencies List every external model integration, plugin, data source, and retrieval service, then review what data and authority each one can influence. Remove any dependency that can modify behaviour without a clear business need.
  • Sanitize both inputs and outputs Use input validation, context filtering, output encoding, and content handling rules to stop prompt injection and unsafe rendering. Do not assume that a well-behaved model makes the surrounding application safe.

Key takeaways

  • LLM security failures often begin outside the model itself, in prompts, outputs, dependencies, and delegated actions.
  • The most dangerous GenAI risks are the ones that let an application trust model behaviour too far or too early.
  • Practitioners should focus on boundary control, output discipline, and approval gates before model output becomes operational change.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI02 — Tool MisuseThe article covers unsafe model actions and delegated execution in GenAI apps.
ASI03 — Identity & Privilege AbuseExcessive agency and overbroad access are central risks in the guide.
Recommendation — Constrain agent tool use and approve high-impact actions before execution. Limit model privileges to the smallest action set needed for each workflow.
OWASP API Security Top 10API10 — Unsafe Consumption of APIsLLM apps consume plugins and external services that can be abused or misused.
Recommendation — Validate every external API call path that an LLM can trigger or influence.
NIST AI RMFMANAGE — AI Risk Management and MonitoringThe article is about governing GenAI risks through controls and monitoring.
Recommendation — Maintain continuous oversight of AI risks across the application lifecycle.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe guide repeatedly stresses limiting who and what can act through LLM apps.
Recommendation — Apply least-privilege authorisation to models, plugins, and connected workflows.

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.
  • Insecure Output Handling: Insecure output handling happens when downstream systems trust LLM output without validation, encoding, or policy checks. Because model responses can be manipulated, this creates pathways to XSS, SSRF, privilege escalation, remote code execution, and other unsafe actions. The control failure is treating generated text as reliable application input.
  • LLM Supply Chain: The collection of models, datasets, repositories, tokens, and build paths that determine what an AI system consumes and distributes. In practice, it is a trust chain for AI content, and a compromise at any point can affect downstream users and applications.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org