AI agent auth checklist: why per-agent identity now matters

At a glance

What this is: A practical audit checklist for agentic system authorization that argues agents need separate identities, scoped tokens, explicit approvals, and immutable logging.

Why it matters: IAM, NHI, and platform teams need this because agentic systems create machine identity and delegated access patterns that human-centric controls and shared credentials cannot safely govern.

👉 Read WorkOS's AI agent auth checklist for identity, delegation, and token controls

Context

AI agent authorization fails when teams treat an agent like a session extension instead of a distinct identity. The problem is not complexity alone, but the assumption that a borrowed user session or static API key can safely represent independent tool use, delegation, and revocation in production.

For IAM and NHI programmes, that assumption creates a governance gap across identity assignment, scoping, and auditability. Once an agent can act on behalf of users, the control model has to answer which principal acted, what it was allowed to do, and how quickly that access can be cut off.

The article’s checklist is aimed at shipping systems, but the real issue is programme design. Teams that already govern service accounts, OAuth clients, and delegated access will recognise the same pattern: access is only safe when identity, token design, and logging are engineered together.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: They should treat each agent as a separate principal, then apply delegated access only where the agent’s configured rights and the user’s current rights overlap. That model supports attribution, revocation, and least privilege. It also keeps the agent from inheriting more power than the human or workload that invoked it intended.

Q: Why do borrowed sessions and shared service accounts create agent security risk?

A: Because they destroy identity boundaries. When multiple agents or users share one credential, you lose the ability to answer who acted, what was allowed, and how to revoke one actor without breaking others. That makes incident response and access governance much harder, especially when the agent can call external tools.

Q: What do security teams get wrong about agent access tokens?

A: They often treat a token as proof that the agent should be trusted broadly. In reality, the token should be short-lived, audience-bound, and scoped to a single task or resource server. If it can be replayed elsewhere, or if it doubles as a login token, it becomes persistent privilege instead of controlled delegation.

Q: Who is accountable when an AI agent takes an unintended action?

A: Accountability sits with the organisation that designed the delegation model, not with the agent itself. The system has to preserve enough context to show which user initiated the request, which agent executed it, what authorisation was in force, and whether the action should have been blocked or approved.

Technical breakdown

Per-agent identity and OAuth client registration

A production agent should be treated as its own principal, not as a shared service account or a disguised human session. In practice, that means independent client IDs, explicit registration, and separate authentication flows for machine-to-machine and delegated use cases. This is what makes attribution, revocation, and least privilege possible at the agent level. Without per-agent identity, an audit log can only tell you that some user triggered a sequence of calls, which is not enough for incident response or access governance.

Practical implication: register each agent as a separate identity so logs, permissions, and revocation operate at the right granularity.

Intersection-based authorisation and token scoping

Agent authorisation should be the intersection of what the agent is allowed to do and what the user currently can do. That prevents a powerful user token from becoming a blanket delegation path and stops a confused or manipulated agent from inheriting more authority than intended. The same principle applies to token design: access tokens need subject, actor, audience, and scope claims so they are task-bound, resource-bound, and short-lived. If any of those pieces are missing, the token becomes a reusable privilege object rather than a controlled delegation artefact.

Practical implication: enforce per-action policy checks with audience-bound, short-lived tokens instead of reusing broad login tokens.

Immutable audit logging and fail-closed revocation

Agent systems need logs that preserve the full execution context, including user, agent, resource, action, and authorisation decision. That is what turns an agent action into something you can investigate, certify, and revoke with confidence. The same architecture should fail closed when authorisation is unclear, because retrying with cached credentials or falling back to broader access quietly defeats the control plane. In other words, logging and revocation are not separate concerns. They are the operational proof that delegated access is actually governed.

Practical implication: build immutable, queryable logs and hard stop behaviour for denied or revoked agent actions.

NHI Mgmt Group analysis

Per-agent identity is now a governance baseline, not an implementation preference. Shared service accounts and borrowed user sessions collapse attribution, revocation, and scoping into one opaque control surface. That model was designed for a simpler world in which one principal, one role, and one audit trail were usually enough. The implication is that agentic systems force identity teams to govern the agent itself as the accountable principal.

Intersection-based authorisation is the only defensible model for delegated agent access. The article correctly rejects the union of user privilege and agent capability, because that design turns a manipulated agent into an over-entitled actor. This aligns with OWASP NHI thinking: the effective permission set must be constrained at runtime, per action, not inferred from a static role. Practitioners should treat token scope as a live policy problem, not a provisioning checkbox.

Short-lived, audience-bound tokens are a control against replay, not a substitute for delegation design. The article shows why a token without audience and scope binding becomes portable privilege. That is especially dangerous in agent workflows because model context, logs, and debug paths can expose credentials in places the original user never intended. The practitioner takeaway is that token format and token handling have to be governed as one system.

Immutable auditability is the line between a controlled agent and an ungoverned one. If teams cannot answer who initiated an action, which agent executed it, what changed, and why it was allowed, the agent is operationally outside identity governance even if it authenticates correctly. The article’s emphasis on immutable logs is therefore not a reporting nicety. It is the minimum condition for enterprise trust in agentic access.

Fail-closed authorisation is the control that prevents small mistakes from becoming broad compromise. Many agent incidents are not caused by stolen credentials alone, but by systems that keep trying after a denial or quietly fall back to broader access. That behaviour turns a single failed check into a hidden privilege escalation path. The practical conclusion is that a denied request must end the path, not reroute it.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader governance baseline, see Ultimate Guide to NHIs for identity lifecycle, access review, and delegated access patterns.

What this signals

Agent governance is moving from experimental controls to identity programme design. The article points to a future where agent identity, delegated access, and auditability are treated like core IAM primitives rather than add-ons. That shift matters because the same control failures that break service accounts also break agentic systems, only faster and with less human visibility. Practitioners should expect more pressure to prove who or what actually acted in production, and to justify every delegation path with policy evidence.

With 80% of current AI agent deployments already showing rogue behaviour in the SailPoint research, the next control discussion is not whether agent governance is needed, but which controls can withstand runtime autonomy. Teams that already use Top 10 NHI Issues as a baseline should extend the same discipline to agent workloads, then align the delegation model to OWASP Top 10 for Agentic Applications 2026.

Identity blast radius becomes the decision metric. When agents can act across tools, the real question is how far one compromised or over-permissioned principal can reach before a denial stops it. That means revocation speed, audience binding, and immutable logging become programme-level priorities, not engineering details. Teams should prepare to measure agent access in terms of containment rather than convenience.

For practitioners

• Register each agent as a separate principal Assign a distinct client identity to every agent or agent class so you can revoke, scope, and audit access without affecting unrelated workloads. Do not let multiple agents share one service account when their actions need to be traced individually.
• Enforce intersection-based authorisation at runtime Evaluate the agent’s configured permissions together with the user’s current permissions before every tool call. If the user cannot perform the action directly, the agent should not inherit that power through delegation.
• Separate login tokens from delegated access tokens Use OpenID Connect for user authentication and OAuth 2.1 for downstream authorisation, then keep the resulting access token short-lived, audience-bound, and scoped to one resource server. Never reuse the same token for login and tool execution.
• Write full-context audit logs for every action Log the user, agent, action, resource, result, and authorisation basis in a structured, tamper-resistant record. If one of those fields is missing, incident reconstruction and access review will both fail.
• Fail closed on denials and revocations Stop execution when a resource server returns a denial, and remove any fallback path that retries with cached or broader credentials. A revoked token should end the action path immediately, not redirect it.

Key takeaways

• AI agent security fails most often when teams blur the boundary between human identity, delegated access, and machine principal design.
• The evidence points to a governance gap, not an edge case: current deployments already show rogue behaviour, missing auditability, and over-broad access patterns.
• The decisive controls are separate agent identities, runtime intersection checks, short-lived scoped tokens, immutable logging, and fail-closed revocation.

Key terms

• Per-agent identity: A separate digital identity assigned to each AI agent or agent class so its actions can be authenticated, authorised, and audited independently. This prevents shared credentials from hiding which agent acted and makes revocation possible without disrupting other workloads.
• Intersection-based authorisation: A delegated access model where the final permission at runtime is the overlap of what the agent is configured to do and what the user currently can do. It blocks privilege inflation and keeps agent behaviour within the smallest valid authority set.
• Audience-bound token: An access token that can only be used against a specific resource server or API. Audience binding limits replay, reduces token portability, and ensures that a credential minted for one task cannot be reused elsewhere.
• Fail-closed authorisation: A control posture in which denied or uncertain access stops the workflow instead of triggering retries, credential fallbacks, or alternative paths. In agentic systems, this is essential because permissive fallback behaviour can quietly turn a denied action into an authorised one.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by WorkOS: The 2026 AI agent auth checklist: 9 things to audit before you ship. Read the original.