Agentic AI identity and authorisation need stronger trust controls

At a glance

What this is: Token Security’s analysis says agentic AI needs stronger identity, authentication, authorisation, and trust controls because autonomous agents create traceability and governance gaps when they act across systems on their own.

Why it matters: IAM, PAM, and governance teams need to treat agentic AI as a distinct identity class, because human-centric controls do not reliably contain autonomous API use, delegated actions, or policy drift.

Context

Agentic AI changes the identity problem because the actor is no longer a person clicking through a workflow. When an autonomous system can trigger actions, call APIs, move data, and create other agents, the programme has to govern runtime behaviour rather than just user login events.

The governance gap is that many identity models still assume access is assigned to stable subjects and reviewed later. That assumption fails when the subject is an agent that can appear, act, delegate, and disappear within the same operational window. The result is weaker provenance, weaker accountability, and a much larger policy surface for IAM and security teams.

Token Security frames this as a trust problem built into the identity layer, not just an AI safety issue. The practical question is how to bind each agent’s actions, permissions, and purpose tightly enough that compliance and oversight still hold when autonomy is the default.

Key questions

Q: Why do agentic AI deployments become risky when identity controls are coarse-grained?

A: Agentic AI becomes risky because it can act within whatever access it is given, including broad permissions that were never designed for autonomous decision making. If workloads are not individually credentialed and governed, the system inherits overpermissioned access paths. Fine-grained authorization and workload identity reduce that blast radius and make agentic systems safer to operate in production.

Q: Why do autonomous agents make traditional access reviews less effective?

A: Access reviews assume permissions persist long enough to be observed, challenged, and recertified. Autonomous agents can obtain, use, and discard access within a single session, which means the risky action may occur before the next review cycle. That makes runtime enforcement more important than periodic certification alone.

Q: What are the signs that AI agent permissions are too broad in enterprise environments?

A: Common warning signs include agents accessing tools they do not need, performing irreversible actions without confirmation, retrieving cross-tenant or unrelated data, and acting with long-lived credentials. If logs show the agent is using broad user permissions instead of scoped access, the control model is too loose and the environment is exposed to accidental or malicious misuse.

Q: Should organisations use human IAM patterns for agentic AI systems?

A: Only as a starting reference, not as the operating model. Human IAM assumes a stable person, a durable session, and clear intent, while agents can act, delegate, and change scope dynamically. Teams need agent-specific identity, continuous verification, and finer-grained authorisation if they want control to survive autonomy.

Technical breakdown

Why anonymous or shared agent identities break provenance

Agentic systems fail fast when multiple agents share the same API key, service account, or token. Provenance depends on a stable identity boundary, meaning each action must be attributable to one execution context. If an agent calls systems without sending identity information, logging may still record the event, but attribution and accountability collapse. In practice, that makes incident reconstruction, policy enforcement, and post-action review unreliable. The problem is not only theft of credentials. It is that the identity model no longer maps cleanly to the actor model when many agents reuse the same machine credential.

Practical implication: assign unique identities to every agent and stop using shared credentials for agent workloads.

How sender-constrained OAuth changes agent authentication

OAuth 2.1 can support agent authentication better than static credential patterns because it introduces token-based access, rotation, and sender constraint. Sender-constrained tokens reduce replay risk by tying the credential to the specific agent that received it, which is important when tasks are short-lived and execution paths vary. But authentication alone does not solve delegation risk. An agent can still misuse authorised access if the permission boundary is too broad or if policy checks happen only at issuance time. The control value comes from combining token binding with continuous trust evaluation.

Practical implication: use sender-constrained, short-lived tokens, then re-check authorisation at each sensitive action.

Why Zero Trust must be per-request for autonomous agents

Zero Trust for autonomous systems is not a one-time registration control. It is a per-request verification model that assumes an agent’s current context may differ from its startup state. That matters because prompt injection, poisoned data, or interference from other agents can change behaviour mid-session without changing the identity record. If policy evaluation only happens at login, the organisation loses control over what the agent does later. Continuous validation turns identity into an ongoing decision rather than a static trust grant, which is the only defensible posture when actions are runtime-driven.

Practical implication: move policy enforcement from onboarding events to every API call and high-risk decision point.

Threat narrative

Attacker objective: The attacker’s objective is to exploit weak agent identity boundaries to perform unauthorised actions while avoiding attribution and policy enforcement.

1. Entry occurs when an agent is provisioned with an anonymous identity or a shared credential, so the system cannot distinguish one runtime actor from another.
2. Credential abuse follows when the same API key or service account is reused across agents, creating an access path that cannot be cleanly attributed or constrained.
3. Escalation happens when an agent with broad permission levels uses its authorised access to trigger workflows, move data, or delegate to other agents without fresh verification.
4. Impact is loss of provenance, weak accountability, and policy bypass across a multi-agent environment where malicious or compromised behaviour blends into normal automation.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

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

NHI Mgmt Group analysis

Identity for agents is now a governance primitive, not an implementation detail. When autonomous systems can trigger workflows, call APIs, and delegate to other agents, identity is the only durable way to preserve provenance. Human-centric admin patterns do not scale to runtime decision-making, so the governance model has to move to verifiable, agent-specific identity at the point of action. Practitioners should treat agent identity as part of the control plane, not a background configuration task.

Shared credentials create identity ambiguity that no audit log can fully repair. If several agents use the same service account or API key, the programme loses the ability to prove which actor made which decision. That is not just a logging weakness. It is a structural failure of accountability, because the identity boundary no longer maps to the behavioural boundary. The practical conclusion is that agent reuse patterns should be considered a governance defect, not merely a security smell.

Access review processes assume access persists long enough to be reviewed; autonomous agents can acquire and release privilege inside a single task. That assumption fails under runtime autonomy because the subject is not a stable user with a durable entitlement record. This is the core assumption collapse in agentic identity governance: review cadences are built for persistent access states, not ephemeral machine decisions. Practitioners need to rethink where trust is established, because post hoc review cannot be the primary control.

Zero Trust becomes more important, but also more expensive to operationalise, when the actor is autonomous. Every request must carry identity, context, and purpose, because past behaviour does not guarantee current safety. That means policy engines, token design, and trust evaluation have to be tightly coupled. The field is moving toward lifecycle-based authorisation for agents, and teams that keep treating agent behaviour as a variant of human access will miss the real control boundary.

Agentic AI exposes an identity blast radius problem that traditional IAM models do not describe well. One overbroad agent can delegate, call, and compound actions across multiple systems faster than a human reviewer can intervene. The right unit of analysis is no longer the account alone but the action chain behind it. Practitioners should measure how far a single agent credential can propagate across systems, permissions, and delegated sub-agents before containment fails.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agent identity lifecycle is now the control boundary: when an agent can be created, tasked, delegated, and retired at machine speed, joiner-mover-leaver assumptions built for humans no longer protect the system. Governance teams should shift from periodic review to lifecycle-aware issuance, delegation, and revocation controls. A useful next step is to align policy with the agent identity lifecycle rather than the account record.

The most practical shift is to treat runtime authorisation as the new review point. Access decisions that used to happen once at provisioning now need to happen at each sensitive action, especially where delegation or cross-system movement is possible. That changes how teams measure control effectiveness: success is not just clean audit trails, but bounded behaviour under changing context.

For practitioners

• Define unique identities for every agent Do not let multiple agents share the same API key, service account, or token. Separate identities per agent make provenance, containment, and revocation materially more reliable.
• Bind credentials to the issuing agent Use sender-constrained, short-lived tokens so a stolen credential cannot be replayed by a different agent. This limits reuse and keeps authentication tied to the runtime subject.
• Move authorisation checks to each sensitive call Evaluate context, purpose, and permission at every high-risk API call rather than only at startup or registration. That is the practical control point for autonomous behaviour.
• Document human ownership for high-risk agent actions Require a named human owner for sensitive operations such as financial actions, access to sensitive data, or delegation to another agent. That keeps accountability attached to the control process.
• Review agent lifecycle controls separately from human IAM Build joiner-mover-leaver, offboarding, and recertification processes that assume agents can be created, changed, and retired at machine speed. Human cadences are too slow for autonomous systems.

Key takeaways

• Agentic AI creates an identity problem because autonomous systems can act across environments without the stable human subject model that traditional IAM assumes.
• Shared credentials, opaque calls, and weak runtime verification make provenance and accountability difficult to preserve in multi-agent ecosystems.
• The decisive control shift is toward unique agent identity, sender-constrained credentials, and per-request authorisation tied to lifecycle governance.

Key terms

• AI Agent Identity Lifecycle Management: AI Agent Identity Lifecycle Management is the process of creating, governing, monitoring, rotating, and retiring identities used by autonomous software agents. It covers how an agent is authenticated, what it can access, how its credentials are issued and revoked, and how changes are tracked across its operational life to reduce misuse and drift.
• Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
• Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
• 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.

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.