TL;DR: OWASP’s 2026 Top 10 for LLM Applications blends practitioner ranking with 7,714 real incidents, and Cycode’s analysis says the biggest changes are stronger evidence weighting, a renamed scope boundary, and higher urgency around models that can act, leak, or consume resources. The governance lesson is that AI risk now sits across prompts, retrieval, tool use, and output sinks, not just model quality.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cycode's blog post: OWASP's 2026 Top 10 for LLM Applications re-ranks model risk around incident evidence, with special attention to prompt injection, data disclosure, excessive agency, and output handling.
Why it matters: AI application teams need this because LLM risk now sits across model inputs, retrieval layers, tool use, and sinks, which means classic AppSec scanning misses much of the real attack surface.
By the numbers:
- OWASP pulled a corpus of 7,714 real AI-related security incidents for the 2026 ranking.
- 6,639 of those incidents carried enough detail to classify.
- Cycode’s 2026 State of Product Security report found that 81 percent of organisations lack full visibility into how AI is used across the SDLC.
- Cycode’s 2026 State of Product Security report found that 65 percent of organisations report increased security risk from AI tooling.
Context
The problem space is not simply “model security” but the governance gap created when AI systems can read, retrieve, generate, and act across multiple trust boundaries. In practice, that means prompt handling, retrieval permissions, tool execution, output sinks, and resource limits all need to be governed as one control surface rather than as separate technical concerns. For appsec and platform teams, the primary question is whether the control is placed before the model, around the model, or only after the model has already influenced an action.
OWASP’s 2026 edition matters because it reflects a shift from opinion-led risk ranking toward evidence-weighted governance. That change aligns with what AI and IAM practitioners are already seeing: models are no longer isolated chat interfaces, they are identity-bearing system components that can inherit privileges, expose secrets, or trigger downstream workflows. The article’s core message is that AI governance now depends on controlling how the system can act, not just how well it can answer.
Key questions
Q: What breaks when an LLM can act with more privilege than the task requires?
A: The failure is privilege amplification. A model that can call tools, edit files, send messages, or hit APIs with standing access can turn a minor error into a real change, data exposure, or cost event. The safest pattern is least agency, where each action is narrowly scoped and irreversible operations require explicit human approval.
Q: Why do AI-enabled security tools need governance beyond traditional security controls?
A: AI-enabled tools introduce non-deterministic behaviour, which means security controls must address both the system and the model lifecycle. Traditional controls can show a vendor protects data and infrastructure, but they do not prove the AI’s behaviour is reviewed, monitored, and corrected over time. Governance matters because the risk can change as prompts, models, and features evolve.
Q: What are the signs that an LLM workflow is mishandling hidden context?
A: Look for system prompts, policy text, secrets, or tool schemas being embedded in places the model can read back or leak indirectly. Repeated disclosure of internal instructions, unexpected tool calls, and prompts that change behaviour after retrieved content is added are common indicators that hidden context is too accessible.
Q: How should teams govern LLM output that reaches a shell, query, or browser?
A: Treat model output as untrusted input at the sink, not as trusted instruction. Encode and validate before execution, and use allowlists for commands, queries, and rendered content. This matters because the model may be correct most of the time, but the sink only needs one unsafe instruction to create impact.
Technical breakdown
Why prompt injection remains the anchor risk
Prompt injection is the failure mode where untrusted content is interpreted as instruction. In LLM systems, that content can arrive directly from a user or indirectly through retrieved documents, web pages, tickets, memory stores, or multimodal payloads such as images and audio. The technical problem is authority confusion: the model cannot reliably tell whether a string is data or policy. Once the injected content reaches system prompts or persistent memory, the risk extends beyond one session and can influence later tool use or outputs.
Practical implication: isolate privileged instructions from untrusted content and treat retrieval and memory as potential instruction channels.
How excessive agency turns model output into an execution risk
Excessive agency is not about the model being wrong, but about the model being allowed to act with too much privilege. When an LLM can call tools, modify files, send email, or hit cloud APIs, its outputs become executable decisions rather than suggestions. The mechanism is borrowed privilege plus insufficient human gating. That is why a bad answer can become a bad ticket, a bad command, or a destructive change if the action is not constrained by scope, approval, and sink-side validation.
Practical implication: bind every tool to least privilege and require explicit approval for irreversible actions before execution.
Why hidden context and output sinks widen the attack surface
Hidden context exposure and improper output handling show that the model boundary is larger than the prompt window. System prompts, tool schemas, retrieved policy text, and configuration values can all leak if they are placed into the model context, while generated output can become dangerous when rendered in a shell, IDE, browser, or database query. The technical issue is that the model is now sitting between sensitive context and executable sinks. Security therefore depends on both input containment and output sanitisation, not one or the other.
Practical implication: keep secrets out of context windows and validate or encode model output at every execution sink.
Threat narrative
Attacker objective: The attacker’s objective is to manipulate model behaviour so that trusted automation discloses information, misroutes work, or executes harmful actions on their behalf.
- Entry begins when untrusted text, retrieved content, or multimodal input reaches an LLM workflow and is treated as instruction rather than data.
- Credential access or privilege abuse follows when the model can read hidden context, retrieve protected data, or call tools with standing authority.
- Impact occurs when the model’s output feeds a sink such as a shell, query, ticket queue, or API call and causes an incorrect or unauthorized action.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
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 2026 LLM Top 10 is really a control-boundary document, not just a risk list. The important change is not the order of the categories but the fact that the list now reflects how AI applications behave in production: they read, retrieve, remember, call tools, and emit actions. That makes governance depend on where authority is granted and where it is revoked. Practitioners should treat the LLM as a governed component inside a larger identity and control chain, not as a standalone model.
Hidden context exposure is the named concept teams should internalise. The article makes clear that system prompts are only one part of the hidden state, with tool schemas, policy text, and configuration values also sitting inside the context window. Once that material is assumed readable, the old security assumption of “keep the instructions secret” stops working. Security teams should redesign around exposed context, not protected context.
The AI app risk shift is toward actionability, which is where identity governance becomes unavoidable. Excessive agency, sensitive disclosure, and improper output handling all show that AI now behaves like a non-human identity when it can consume privileges and influence execution. That means AI governance, IAM, and PAM can no longer be separated cleanly in practice. The practitioner conclusion is straightforward: govern AI systems by authority, not by interface.
Evidence-weighted ranking is a better operating model than practitioner intuition alone. OWASP’s use of 7,714 incidents and 6,639 classifiable records shows why list maintenance matters. Teams should not assume the highest-profile risk is always the most common failure mode in their own environment. The right response is to align controls to observed usage patterns, especially where tool access, retrieval, and execution converge.
For AI security, the relevant unit of control is the workflow, not the model. The article’s framework mapping, and its separation of LLM, Agentic, and MCP risk, underline that a single model can sit inside several governance domains at once. That is the real operating challenge for security architects and IAM leads. The control objective is to make each boundary explicit before autonomous behaviour reaches production scope.
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.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Hidden context exposure is becoming a governance problem, not a prompt-tuning problem. Once teams accept that tool schemas, policy text, and retrieved data can be surfaced or inferred, they have to move controls upstream into context design and permission scoping. That is especially important for environments where agentic behaviour and non-human identities overlap, because hidden context can become the shortest path from discovery to misuse.
The practical boundary for AI risk is now the workflow around the model. The model may be the visible component, but the attack paths run through retrieval permissions, secret handling, tool authority, and sink validation. 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.
Identity teams should expect AI governance to converge with PAM and workload identity controls. When models can read context and trigger actions, the question becomes who or what is allowed to act, under what scope, and with which revocation path. That is already the language of identity security, so AI programmes that ignore it will keep discovering the same weaknesses from a different angle.
For practitioners
- Map AI workflows to distinct control boundaries Separate prompt handling, retrieval, agent tool use, and output sinks into different control domains so you can assign the right approvals and logging to each stage.
- Reduce model authority to least agency Remove standing permissions wherever the model does not need them, and require human approval for actions that change state, spend money, or touch production systems.
- Treat hidden context as readable Keep secrets, tokens, and sensitive policy text out of system prompts, memory stores, and retrieved context whenever the application can function without them.
- Validate every executable sink Apply encoding and validation at shells, SQL layers, ticket queues, and browsers that receive model output, because those sinks are where wrong answers become harmful actions.
- Build an AI bill of materials for the workflow Track models, adapters, connectors, and external dependencies together so provenance, ownership, and review responsibilities remain visible across the Agentic Development Lifecycle.
Key takeaways
- LLM security is shifting from model quality to control of the surrounding workflow, especially prompts, retrieval, agency, and output sinks.
- Evidence now matters more than intuition alone, because the 2026 ranking is grounded in 7,714 real incidents and 6,639 classifiable records.
- The control objective is to reduce the authority of AI systems so that wrong outputs cannot easily become wrong actions.
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 MITRE ATT&CK 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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article repeatedly shows AI systems gaining too much authority through tools and memory. |
| ASI02 — Tool Misuse | Tool calling is a central risk surface when model output can trigger real actions. | |
| ASI09 — Human-Agent Trust Exploitation | The article highlights trust in fluent output and hidden context as a misuse vector. | |
| Recommendation — Constrain agent identity and privilege so tool use stays within task-scoped authority. Validate every tool invocation path and restrict actions to approved tasks only. Require human review where agent output can influence irreversible or high-impact decisions. | ||
| NIST AI RMF | MAP — Map the AI context and impacts | The article is fundamentally about mapping AI risks across context, tools, and sinks. |
| MANAGE — Manage AI risks | Governance must reduce authority, leakage, and unsafe output handling in production. | |
| Recommendation — Map each AI workflow boundary, dependency, and downstream impact before granting production access. Manage AI risk with scoped permissions, sink validation, and explicit approval for high-impact actions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI systems in this article need explicit authorization boundaries around tools and data. |
| Recommendation — Apply PR.AA-05 to limit AI access to the minimum permissions needed for each workflow. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article includes disclosure paths where sensitive context or credentials can be read back out. |
| Recommendation — Hunt for credential access and exfiltration paths in prompts, retrieval, logs, and generated output. | ||
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.
- Hidden Context Exposure: Hidden context exposure occurs when system prompts, tool schemas, policy rules, or other non-user-facing instructions are revealed to an attacker. That knowledge often improves follow-on attacks because it exposes how the agent reasons, routes requests, and enforces boundaries.
- Output Sink Validation: Output sink validation is the control discipline applied where model output becomes executable input, such as a shell, query engine, browser, or ticketing system. It ensures generated content is encoded, constrained, or checked before it can cause an action or render unsafe content.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, helps practitioners connect identity governance, machine identity security, and agentic AI identity to real-world control design. It is suitable for security, IAM, and platform teams that need a shared model for governing non-human access.
Published by the NHIMG editorial team on September 16, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org