TL;DR: Scoped tokens reduce blast radius for AI agents, but they do not decide whether a specific action should execute in the moment, according to Permit.io’s analysis of agent identity and runtime policy. Token scope is admission, not authorization, so the real control point shifts to per-call evaluation, delegated intent, and live context.
At a glance
What this is: This analysis argues that AI agent identity cannot be governed by scoped tokens alone because execution-time decisions still need runtime authorization.
Why it matters: It matters because IAM, PAM, and NHI programmes must distinguish between who can start an agent and whether the agent should be allowed to act right now.
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
👉 Read PermitIO's analysis of agent identity, scoped tokens, and runtime authorisation
Context
AI agent identity is the governance problem that appears when a software actor can generate actions at runtime rather than follow a fixed script. In this model, the primary question is not just who authenticated the actor, but what it is allowed to do at the moment of execution.
Scoped tokens and service accounts still matter, but they only establish coarse admission boundaries. When an agent’s context, intent, or trust posture changes mid-session, static token scope cannot make the final authorization decision for the next tool call.
Key questions
Q: How should security teams govern AI agents that use scoped tokens?
A: Security teams should use scoped tokens for coarse identity and access boundaries, but require runtime authorisation for each sensitive action. The deciding control should evaluate the delegating human, the agent, the current task, and live risk signals before execution. That prevents a token from becoming a standing approval for generated behaviour.
Q: Why do scoped credentials fail to fully control AI agent behaviour?
A: Scoped credentials fail because they answer who may enter a system, not whether a specific generated action should happen now. AI agents can choose different tool paths at runtime, so the authorisation decision must be made at execution time. Without that, valid access can still produce unsafe or unintended actions.
Q: What do security teams get wrong about zero standing permissions for agents?
A: Teams often treat short-lived credentials as if they were zero standing permissions. They are not. A token still creates a real privilege window until expiry. Zero standing permissions removes persistent authority and forces every sensitive action to be authorised against current context, not historical access.
Q: How can organisations audit delegated AI agent actions properly?
A: Organisations should log the full delegation chain, including the human delegator, agent identity, task purpose, policy version, action request, and final decision. That makes accountability possible when something goes wrong and lets security teams distinguish between bad intent, bad policy, and bad execution.
Technical breakdown
Why scoped tokens are admission, not authorization
Scoped tokens answer a narrow question: can this actor start, and within what broad boundary? They do not answer whether a specific runtime action is acceptable under current conditions. For agents, that distinction matters because the action sequence is generated dynamically. The token may prove identity, ownership, and coarse scope, but it cannot evaluate prompt injection, session trust drift, or policy changes after issuance. In practice, the enforcement point has to sit at tool-call time, where identity, intent, context, and policy are evaluated together.
Practical implication: keep tokens as a boundary control, but move sensitive action approval to runtime policy evaluation.
Zero standing permissions versus short-lived credentials
Short-lived credentials reduce exposure windows, but they still create standing privilege for the life of the token. Zero standing permissions removes persistent execution authority altogether and derives permission only when an action is requested. That difference becomes critical for AI agents because their behaviour is not deterministic in the way a batch job is. A token with a narrow scope can still be used for the wrong action if the runtime context has changed. The security model must therefore treat every invocation as a fresh decision, not a continuation of an old grant.
Practical implication: design agent workflows so that each sensitive tool invocation is independently authorised against live context.
Full-chain auditability for delegated agent actions
Traditional logs often stop at the workload identity, but agent governance needs the full delegation chain. That means the human delegator, agent identity, task purpose, scope, trust level, policy decision, and outcome all need to be captured together. Without that chain, incident review becomes attribution theatre, because no one can tell whether the failure came from the prompt, the policy, the session context, or the delegated authority. Good telemetry is not just observability. It is the evidence base for accountability when a generated action crosses a boundary.
Practical implication: log delegation, intent, policy version, and tool outcome together so every agent action is reconstructable.
Threat narrative
Attacker objective: The objective is to get a generated agent action approved by inheritance from the token rather than by a fresh runtime decision.
- Entry occurs when a user delegates an AI agent with a scoped token that grants coarse access to tools and resources. Escalation begins when the agent generates a runtime tool call that is technically within scope but no longer aligned to current context or trust posture. Impact follows when static token scope is treated as final authorisation, allowing an inappropriate action to execute without a live policy check.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scoped tokens were designed for admission control, not for deciding whether a generated action should execute right now. That assumption holds for deterministic workloads, where the next action is known in advance. It fails when the actor is an AI agent because the action sequence is generated at runtime and can shift with context. The implication is not simply that more policy is needed, but that the old grant model no longer describes the decision point correctly.
Zero standing privilege becomes the relevant governance concept once agent behaviour is runtime-driven. A short-lived token still creates a live privilege window, even if the window is brief. Agents can still act inside that window in ways that are technically valid and operationally wrong. Practitioners should treat this as a privilege timing problem, not just a credential lifetime problem.
Runtime authorisation is the missing control plane for delegated AI agents. The field is moving toward actor chains that combine human delegation, machine identity, and live context in a single execution path. That means IAM and PAM programmes need to understand whether a control is proving identity, constraining scope, or making the actual allow or deny decision. Practitioners should stop collapsing those functions into one token layer.
Identity blast radius is now determined by the combination of scope, context, and decision timing. In agentic environments, the size of the damage window is no longer set only by credential expiry. It is also set by how often the system re-evaluates trust before each tool call. Teams that still rely on issuance-time controls are measuring the wrong part of the attack surface. Practitioners need to map blast radius to execution-time governance.
From our research:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Use Ultimate Guide to NHIs to compare lifecycle controls for machine identities, delegated agents, and human access reviews.
What this signals
Runtime authorisation is becoming the real control plane for agentic access. Teams that still treat agent tokens as the final decision point will find that governance, audit, and incident response all fail at the same place: execution time. The shift is from managing what an agent can start to managing what it can do on each call.
Identity blast radius now depends on decision timing as much as privilege scope. A token that expires quickly still leaves a window for misuse if the environment does not re-check trust before every sensitive action. That is why agent governance needs to move closer to policy enforcement and away from static issuance assumptions.
Zero standing privilege should be read alongside NHI lifecycle discipline, not separated from it. With only 20% of organisations having formal processes for offboarding and revoking API keys, per Ultimate Guide to NHIs, the wider lesson is that identity programmes still struggle to close the gap between granted access and actual control.
For practitioners
- Separate admission from execution approval Use scoped tokens only to establish coarse access boundaries, then require a fresh runtime policy decision before any sensitive tool call executes.
- Define a live trust signal for each agent session Include delegated user, session purpose, trust level, and current risk posture in the authorisation context so the policy engine can re-evaluate access as conditions change.
- Log the full delegation chain Record the human delegator, agent identity, policy version, tool request, and allow or deny outcome in one audit event so incident review can reconstruct accountability.
- Treat prompt injection as an authorisation trigger If injected content can change tool selection or action timing, move the control boundary to the tool layer and force policy checks before execution.
- Reclassify agent tokens as temporary admission tickets Review existing documentation and control owners so teams stop describing agent tokens as the final authorisation layer and instead treat them as short-lived admission artefacts.
Key takeaways
- AI agent governance fails when scoped tokens are treated as the final authorisation layer rather than a coarse admission control.
- Runtime decision-making changes the meaning of privilege, because a short-lived grant can still be the wrong grant at the wrong moment.
- The practical fix is to evaluate identity, intent, context, and policy at tool-call time, then preserve the full delegation chain for auditability.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent tool use and runtime decisions map to agentic AI identity abuse and authorisation risks. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Scoped credentials and token lifecycle are central to NHI governance in agent workflows. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed so only current authorised actions are allowed. |
Evaluate agent tool access at runtime and treat each sensitive call as an enforceable policy decision.
Key terms
- Agent identity: Agent identity is the identity model used when a software actor can make decisions at runtime, not just execute a fixed script. It combines workload identity with delegation, task context, and trust state so authorisation can be evaluated against the action being requested, not only the actor that connected.
- Runtime authorisation: Runtime authorisation is the decision to allow or deny a specific action at the moment it is requested. For agents, it is the control that sits between broad token scope and actual tool execution, using live context, policy, and identity chain data to make the call.
- Zero standing privilege: Zero standing privilege is a model where no broad persistent access is kept available for later use. Instead, permission is derived just in time for each action, which reduces the chance that a token or account can be reused outside its current purpose or trust context.
- Delegation chain: A delegation chain is the sequence that shows who authorised the actor, what identity it used, and how the action was executed. In agent environments, it usually includes the human delegator, the agent principal, the session context, and the final policy decision that allowed or denied the call.
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 NHI governance in your organisation, it is worth exploring.
This post draws on content published by PermitIO: Agent Identity vs. Service Accounts: Why Scoped Tokens Still Need Runtime Authorization. Read the original.
Published by the NHIMG editorial team on 2026-06-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org