Agentic AI identity and authorisation need stronger trust controls

At a glance

What this is: This is a vendor analysis of why agentic AI needs identity, authentication, authorisation, and trust frameworks built for autonomous behaviour rather than human-centric IAM patterns.

Why it matters: It matters because IAM, NHI, and governance teams need controls that can verify, scope, and audit agents that act independently across systems, not just users and service accounts.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Token Security's analysis of identity and authorisation for agentic AI ecosystems

Context

Agentic AI changes the identity problem because the subject is not just a tool user, but a runtime actor that can choose actions, call APIs, and delegate work without waiting for a human decision. In that model, traditional IAM assumptions about stable identity, predictable intent, and login-based trust no longer hold.

Token Security’s core argument is that agentic systems need identity and authorisation controls that work at the level of each action, not just at registration or startup. That places agent governance squarely inside IAM, NHI, and zero trust programmes, where provenance, least privilege, and lifecycle control already matter.

The practical difference is that an agent can look compliant at registration and still become unsafe once it begins chaining calls, sharing context, or interacting with other agents. That is why agentic AI should be treated as a governance problem, not only an orchestration problem.

Key questions

Q: How should security teams govern AI agents that can act on their own?

A: Security teams should govern AI agents as runtime actors with unique identities, bounded permissions, and continuous verification at each action boundary. That means eliminating shared credentials, using short-lived bound tokens, and requiring human approval for high-risk actions. The goal is to keep execution traceable, revocable, and tied to a named owner.

Q: Why do autonomous agents create more risk than ordinary automation?

A: Autonomous agents create more risk because they can choose actions, select tools, and change behaviour during execution without a human approval gate. Ordinary automation follows predefined logic. Autonomous behaviour can expand scope mid-session, which makes static IAM assumptions, especially role-based access, too coarse for reliable governance.

Q: What breaks when AI agents use shared credentials or opaque API calls?

A: Shared credentials and opaque API calls break attribution, auditability, and containment. If multiple agents use the same key or service account, security teams cannot tell which actor performed a sensitive action or whether access exceeded intent. That makes incident investigation and least-privilege enforcement much harder.

Q: Who should approve high-risk actions taken by AI agents?

A: High-risk actions should require human approval from the accountable business or security owner before the action completes. Financial transactions, sensitive data access, and delegation to other agents are the clearest candidates. Approval should be tied to the specific action and context, not to a blanket role.

Technical breakdown

Why agent identity breaks human-centric IAM models

Agentic systems can act, decide, and operate independently across environments, which means the identity subject is no longer a person waiting to authenticate once and then remain predictable. In practice, an agent may trigger workflows, call APIs, move data, and create other agents within the same operating session. Human-centric IAM assumes a stable operator and a clear approval path. Agentic identity needs provenance, unique identity, and per-action traceability because the actor can change state and context faster than review cycles can catch up.

Practical implication: stop modelling agents as human users with automation attached; model them as non-human actors with their own identity lifecycle.

OAuth 2.1, sender-constrained tokens, and temporal keys for agents

The article frames OAuth 2.1 for agents as a way to issue token-based access that is bound, rotated, and harder to reuse across identities. Sender-constrained tokens matter because they prevent simple token replay by another agent, while short-lived keys reduce the exposure window if credentials leak. This is a tighter pattern than long-lived secrets or shared service accounts, but it still depends on accurate policy enforcement at the moment of use. The point is not authentication alone, but authentication tied to runtime scope.

Practical implication: issue short-lived, bound credentials per agent task and remove any shared credential path that obscures attribution.

Zero trust for autonomous agents requires continuous verification

The article’s zero trust framing is clear: never trust an agent once and assume the trust holds. Every API call must confirm who the agent is and what context it is operating in. That matters because compromised or manipulated agents can change behaviour after initial authentication, especially when prompt injection, poisoned data, or other agents interfere with their decisions. For agentic systems, zero trust is not a network posture only. It is an execution model that must re-evaluate identity, intent, and policy on every step.

Practical implication: move access checks from session start to every action boundary, especially where an agent can delegate or escalate.

Threat narrative

Attacker objective: The objective is to turn autonomous agent access into untraceable, over-scoped execution that can move data, trigger transactions, or expose secrets without clear accountability.

1. Entry occurs when an agent is provisioned with access to workflows, APIs, or data sources through credentials that may be shared, opaque, or not uniquely attributable.
2. Escalation occurs when the agent uses those permissions to call additional systems, delegate to other agents, or access data beyond the original intent of the request.
3. Impact occurs when the system can no longer trace which agent acted, which data was touched, or whether the action remained within approved scope.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic AI is not a human IAM variant, and treating it that way creates false confidence. The article is right to move beyond login-centric thinking because an agent can initiate actions, chain tools, and re-enter policy paths without a human operator in the loop. That makes identity a runtime governance problem rather than a user authentication problem. Practitioners should read this as a shift from identity as access to identity as execution context.

Identity and authorisation for agents fail when teams assume intent is known at provisioning time. That assumption was designed for human-paced approvals and static service accounts. It fails when the actor can decide which tool to call, when to call it, and whether to spin up another agent mid-task. The implication is not just stronger controls, but a redesign of the governance premise that access is stable enough to be reviewed later.

Temporal keys and sender-constrained tokens are useful, but they do not solve provenance on their own. The article correctly treats short-lived credentials as one layer in a broader trust framework, not as the answer. Without identity-specific attribution and action-level context, a compromised agent can still appear legitimate while crossing system boundaries. Practitioners should treat traceability as a first-class control.

Zero trust becomes more demanding when the subject can delegate or self-direct across environments. In agentic ecosystems, policy checks must follow the action, not just the session, because the session itself can mutate into a new workflow. That is why fine-grained authorisation, continuous validation, and human review for high-risk actions belong in the same operating model. Security teams need to govern execution paths, not just identities.

PBAC and ABAC are more aligned to agentic behaviour than static role models, but they must be paired with lifecycle governance. The article points to contextual authorisation, which is the right direction for autonomous systems, yet the lifecycle question remains critical: who owns the agent, when is it retired, and how is delegated authority revoked. In practice, agent governance must connect policy to lifecycle so access does not outlive the task.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• That governance gap is why readers should also review OWASP Agentic AI Top 10 for the control patterns most directly tied to tool misuse and scope drift.

What this signals

Scope drift is the right named concept for agentic governance. The practical failure is not simply that agents are insecure, but that they can exceed their intended scope after deployment while still appearing authenticated. With 80% of organisations already seeing that pattern in market research, the reader’s programme needs to treat runtime scope as a governance object, not a one-time design choice.

For most teams, the near-term signal is whether agent identities are uniquely attributable and revocable across every system they touch. If a service account, token, or delegated agent path cannot be linked to a named owner and a finite lifecycle, the programme still depends on assumptions that autonomous systems routinely violate. That is where Ultimate Guide to NHIs remains the foundational reference point.

The next step for mature programmes is to align agent controls with external frameworks that already expect continuous verification and contextual access. OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both reinforce the same direction: identity, policy, and accountability must move with the action, not trail behind it.

For practitioners

• Assign unique identities to every agent Eliminate anonymous, shared, or unregistered agent access paths. Each agent should have a distinct identity, clear ownership, and a traceable relationship to the workload or workflow it operates.
• Bind credentials to the requesting agent Use sender-constrained tokens and short-lived keys so access cannot be replayed by another agent. Avoid shared API keys and long-lived secrets that make attribution and containment impossible.
• Move authorisation to the action boundary Re-evaluate permissions at every API call or workflow step, especially where agents can invoke tools, access sensitive data, or delegate to other agents. Session-start checks are not enough for autonomous execution.
• Require human approval for high-risk agent actions Gate financial operations, sensitive data access, and authority delegation through a human-in-the-loop control that is triggered by the specific action, not by a broad user role.
• Connect agent governance to lifecycle offboarding Track when an agent should lose access, retire, or be replaced, and make revocation part of the operating model rather than an afterthought. Autonomous access that cannot be retired cleanly becomes permanent risk.

Key takeaways

• Agentic AI changes identity governance because the actor can make decisions, call tools, and delegate work without human pacing or approval.
• The strongest warning sign is scope drift, with research showing most organisations already see agent behaviour exceed intended boundaries.
• Security teams need unique identities, bound credentials, action-level authorisation, and lifecycle revocation for agents, not human IAM patterns copied into a new context.

Key terms

• Agentic Ai Identity: The identity assigned to an AI system that can select actions, call tools, and operate without waiting for a human decision at each step. It must be traceable, scoped, and owned because the actor can change context during execution, which makes static user assumptions unreliable.
• Sender-constrained Token: A token that is bound to the specific agent or client that received it, so another actor cannot reuse it easily. For agentic systems, this reduces replay risk and improves attribution, but only if the surrounding policy checks also evaluate the action being attempted.
• Policy-based Access Control: An authorisation model that makes access decisions based on contextual policy rather than only on fixed roles. In agentic environments, it is useful because the same agent may need different permissions depending on task, data sensitivity, timing, and delegation path.
• Runtime Scope Drift: The tendency for an autonomous actor to move beyond its intended permissions as it chains actions, invokes tools, or delegates work. This differs from a simple misconfiguration because the risk emerges during execution, not only at setup or provisioning time.

What's in the full article

Token Security's full blog post covers the operational detail this post intentionally leaves for the source:

• A more granular explanation of OAuth 2.1 patterns for agent authentication and token binding.
• A practical comparison of RBAC, ABAC, and policy-based access control for autonomous workflows.
• The article's own trust framework comparison table, including the governance strengths of Zero Trust and AI RMF.
• The author’s framing of human-in-the-loop checks for high-risk agent actions and delegation.

👉 Token Security's full post covers the trust framework comparison and agent authentication patterns in more detail

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 governance maturity, it is worth exploring.