Runtime authorization now anchors LLM application security

At a glance

What this is: PlainID maps the 2026 OWASP Top 10 for LLM Applications to the case for runtime authorization, highlighting Excessive Agency as a top-three risk and treating prompt injection as an expected failure mode.

Why it matters: IAM and security teams need policy decisions that evaluate the human, the agent, and the action at execution time, because model-context controls alone cannot contain agentic blast radius.

By the numbers:

• OWASP’s 2026 incident corpus contained 7,714 records, of which 6,639 were classifiable.

👉 Read PlainID's analysis of runtime authorization for the OWASP Top 10 for LLM Applications

Context

The core problem is not whether an LLM can be tricked. The governance gap is that many AI programmes still assume model behaviour is the primary control point, when the real security decision is whether a requested retrieval or action is authorised at runtime. In practice, the primary keyword here is runtime authorization, because that is where access to data, tools, and downstream actions is either contained or allowed to propagate.

PlainID’s article frames the 2026 OWASP Top 10 for LLM Applications as a shift toward the point of consequence. That is the right lens for identity teams: the question is no longer only what the model sees, but what the requesting human, workload, or agent is allowed to do when the model is prompted, manipulated, or acting on behalf of a task.

For regulated environments, this changes the control model around RAG, tool use, and agentic execution. Security teams need to treat authorization as a separate enforcement plane from prompts, memory, and model output, because those layers can be compromised without automatically becoming a policy failure.

Key questions

Q: How should teams implement runtime authorization for LLM applications?

A: Treat runtime authorization as the enforcement point for data access, tool use, and downstream actions. The policy decision should evaluate identity, task, resource, and context together, then approve only the minimum action needed. This keeps a manipulated model from turning input into unchecked access or business impact.

Q: Why do LLM applications need authorization before retrieval as well as before action?

A: Because retrieval can place sensitive information into model context before any output is generated, and that context can be reused in later tool calls or responses. If access is not checked at retrieval time, the model may already have seen data it should never have reached, making downstream controls too late.

Q: What breaks when excessive agency is not bounded by policy?

A: The system can turn a model suggestion into a real-world action with too much authority, too much scope, or too much autonomy. That breaks blast-radius control, because the problem is no longer just wrong output. It becomes an authorised or semi-authorised action that can affect systems, data, or customers.

Q: What should teams do when AI agents act on behalf of real users?

A: Treat the agent as a scoped identity with explicit permissions, audit trails, and revocation rules. The human owner should be verified strongly, but the agent still needs its own access boundaries. That prevents delegated activity from becoming invisible shadow access.

Technical breakdown

Why Excessive Agency changes the control plane

Excessive agency means the system can take actions or invoke tools with authority that exceeds what the task requires. In LLM applications, that is materially different from a bad answer, because the risk is no longer only misinformation but an authorised or semi-authorised action with real business effect. Runtime authorization becomes the compensating control because it evaluates the request at execution time, using identity, resource, context, and policy. That matters for tool calls, API operations, parameter choices, and delegated actions in agent workflows. The control question shifts from “Can the model reason?” to “Should this specific action be permitted now?”

Practical implication: enforce action-level policy at the point of execution, not only at prompt ingress.

How hidden context exposure differs from prompt leakage

Hidden Context Exposure is broader than system prompt leakage. It includes reasoning artifacts, memory, and tool context, which means sensitive control information can exist outside the visible prompt and still influence behaviour or be revealed. The security issue is that hidden context is not the same thing as permission. If entitlements are embedded in model context, exposure does not automatically mean access should be granted, but it can still create confidentiality and governance problems. The stronger pattern is to keep authorisation logic external and deterministic, so context can inform the decision without becoming the decision itself.

Practical implication: separate policy from model context and keep entitlements outside the probabilistic layer.

Why retrieval authorization matters in RAG and agentic execution

Retrieval-augmented generation fails safely only when retrieval is constrained by the same identity and policy logic that governs downstream actions. Without that, a model can surface data it should not reach, then pass it into further reasoning or tool use. The article’s emphasis on authorization before retrieval reflects a key IAM principle: access must be evaluated at the resource boundary, not assumed from the application session alone. In agentic systems, that boundary has to extend to the tool, the dataset, the destination, and the parameters chosen at runtime.

Practical implication: apply policy at retrieval time and again before any tool or API action executes.

NHI Mgmt Group analysis

Runtime authorization is now the primary control boundary for LLM applications. The 2026 OWASP Top 10 makes it harder to pretend that model safeguards alone are enough, because Excessive Agency sits near the top of the risk list and prompt injection is treated as a given. That shifts the governance problem from model behaviour to authorised consequence. For practitioners, the decisive question is which requests a fooled or manipulated model can still turn into real actions.

Hidden Context Exposure shows why policy cannot live inside the model. The article’s renaming of System Prompt Leakage is more than semantics, because it broadens the problem to memory and tool context as well as prompt text. If access logic is co-located with the model, exposure of that context becomes a security and governance failure. The implication is straightforward: policy needs to remain external, deterministic, and auditable.

LLM security is becoming an identity problem, not only an AI problem. The article correctly evaluates the human, workload, and acting agent together, which is where IAM teams add value that model teams usually cannot. Authorization decisions have to follow the access path across RAG, tools, APIs, and downstream destinations. That means identity context, task context, and policy context now need to converge at runtime.

Blast-radius control is the right named concept for agentic AI governance. The practical objective is not perfect prevention of manipulation, because the OWASP model assumes failure modes will happen. The real control is to limit what the actor can reach or do after manipulation succeeds. That reframes AI governance around containment, and practitioners should judge every control by how much damage it limits when the model is wrong.

Policy-driven approval for high-risk actions is becoming a baseline requirement. The article’s mapping of tool and action authorization, step-up approval, and zero standing privilege reflects a broader market direction: security teams are moving from static access grants to contextual enforcement. For regulated use cases, that is the difference between experimentation and defensible deployment.

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.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Blast-radius control: AI governance now depends on limiting what a manipulated model can reach, not on assuming the model will consistently behave. That means teams should design authorization boundaries around execution time, not around prompt quality alone.

Access reviews become weaker in agentic environments when privileges are acquired and released within the same task flow. The governance response is to shift emphasis toward issuance-time policy, task-scoped approvals, and auditable decision records rather than retrospective certification.

According to the State of Secrets in AppSec, 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases. That concern maps directly to policy design because leaked context is only dangerous when it becomes actionable access.

For practitioners

• Enforce runtime authorization for AI actions Place deterministic policy checks in front of every retrieval, tool call, API operation, and downstream destination so a model request is not the same thing as an approved action.
• Separate policy from model context Keep entitlements, approval rules, and sensitive access logic outside prompts, memory, and hidden reasoning artifacts so exposure of context does not become exposure of authority.
• Scope agent authority by task and identity Evaluate the human user, the workload, and the acting agent together so the permitted action set is only the intersection of current task need and standing authority.
• Add step-up approval for high-risk actions Require an explicit approval gate before destructive, irreversible, or regulated actions can execute, especially when the request originates from an LLM or agent.
• Audit retrieval boundaries before model rollout Check that RAG paths enforce document, row, field, and purpose constraints before data reaches the model, not after it has already entered context.

Key takeaways

• The article reframes LLM risk around runtime authority, not just prompt quality or model safety.
• OWASP’s 2026 update shows Excessive Agency moving into the top tier of practical concern, which aligns with execution-time controls.
• The right containment model is deterministic authorization across retrieval, tools, and downstream actions, with policy kept outside model context.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

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

• The full risk-by-risk mapping from OWASP LLM01 to LLM10, including PlainID's control boundary for each one
• The article's detailed explanation of how runtime authorization fits across RAG, APIs, microservices, and MCP servers
• PlainID's specific capability mapping for tool allowlisting, parameter controls, and step-up approval
• The evidence-weighted methodology used in the 2026 OWASP Top 10 update

👉 PlainID's full article covers the OWASP mapping, control boundaries, and runtime enforcement detail

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 building or maturing an IAM programme, it is worth exploring.