Best practices for AI agent access control in enterprise IAM

At a glance

What this is: This is a practitioner guide to AI agent access control, arguing that agents need distinct identities, short-lived credentials, context-aware authorization, and out-of-band approval for high-impact actions.

Why it matters: It matters because the same governance patterns now have to cover human users, NHI principals, and autonomous agents without collapsing authority, auditability, or revocation discipline.

👉 Read WorkOS' guidance on AI agent access control best practices

Context

AI agent access control is the discipline of deciding what an agent can do, when it can do it, and under what context the action should be denied. Existing IAM models break down when the principal selects tools at runtime, chains calls, and persists long enough for static scopes to become too broad for the task.

For IAM, PAM, and NHI teams, the key issue is not whether an agent can authenticate, but whether its authority is separable from the user, bounded by task context, and revocable without relying on fragile session assumptions. That is why agent identity, policy-as-code, and short-lived credentials now sit in the same governance conversation as service accounts and workload identities.

Key questions

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

A: Treat the agent as a separate principal and preserve the user as a second principal in the authorization decision. Use token exchange or on-behalf-of flows so downstream services can evaluate both identities, then require approval for actions the user could not take alone. That keeps delegation auditable and prevents the agent from inheriting broader authority than intended.

Q: Why do AI agents complicate least privilege in enterprise environments?

A: Because agents can choose tool sequences at runtime, a scope that looks narrow on paper may still permit dangerous chained actions. Least privilege has to be capability-based, tied to specific verbs and resources, and enforced by runtime policy rather than by a one-time token grant. Otherwise the agent can turn broad authority into an oversized blast radius.

Q: What breaks when AI agents rely on long-lived API keys?

A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs. Once the key is reused across tasks, revocation becomes slow and unreliable. Short-lived credentials are safer because they reduce the window in which exposure can be exploited.

Q: How do security teams decide when an AI agent needs human approval?

A: Use approval for actions that are hard to reverse or have high blast radius, such as deleting records, sending external messages, or granting access. The approval must happen outside the agent's own context so injected instructions cannot fake it. That makes the human the final authorizer, not the model or tool chain.

Technical breakdown

Distinct agent identities and on-behalf-of delegation

An agent should authenticate as its own principal, not by borrowing a human session or reusing a long-lived API key. That distinction matters because downstream systems need to evaluate the agent and the user separately, especially when the agent acts on behalf of someone else. Token exchange and on-behalf-of flows preserve that separation, so the audit trail and authorization decision remain intelligible. Without that split, incident response cannot answer a basic question: did the human act, or did the agent act for the human?

Practical implication: Issue each agent a separate service identity and require delegation tokens when it acts for a user.

Capability-based scopes and policy-enforcing proxies

Least privilege for agents has to be narrower than broad role membership. Agents are probabilistic actors, so coarse scopes create a larger blast radius than human access usually does. Capability-based authorization narrows the grant to specific verbs on specific resources, while a policy-enforcing proxy becomes the control point when native API scopes are too coarse. The proxy also centralises logging, rate limiting, and approval gates, turning scattered checks into one auditable decision path.

Practical implication: Place a proxy in front of coarse APIs and scope agent credentials to that proxy, not to the backend directly.

Context-aware authorization, approvals, and sandboxed execution

Authorization for AI agents should not end at token presentation. Runtime context such as resource sensitivity, request origin, recent call rate, and the provenance of the triggering content should all factor into the allow or deny decision. For high-impact actions, the approval channel must be outside the agent's own context so it cannot forge the confirmation. Execution should also stay isolated in sandboxes with separate identities and network policy, because browsing, code execution, and file editing all expand the damage surface when combined with untrusted inputs.

Practical implication: Require runtime policy checks, out-of-band approval for irreversible actions, and isolated sandboxes for any agent that touches untrusted content.

Threat narrative

Attacker objective: The attacker wants to co-opt the agent's authority so the system itself performs unauthorized actions, data exposure, or privileged changes on the attacker's behalf.

1. Entry occurs when an agent receives untrusted content or user input that persuades it to invoke tools it was not meant to use, often through prompt injection or malicious documents.
2. Credential access or abuse follows when the agent operates under overly broad scopes, long-lived tokens, or borrowed user sessions that let a single misstep affect multiple systems.
3. Impact appears when the agent completes destructive or privacy-breaking actions at machine speed, turning a confused deputy event into large-scale unauthorized change or disclosure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

AI agent access control is now a delegated-identity problem, not a traditional app-permission problem. The article correctly frames agents as principals that select tools and chain actions, which means authorization has to follow the decision loop rather than the screen flow. That is a different control model from human IAM, because the meaningful unit of governance is the runtime path, not the login event. Practitioners should treat delegation as the core design question, not an edge case.

Least privilege becomes a capability problem when the actor can choose its own sequence of actions. A broad role that looks tolerable for a user becomes dangerous when a probabilistic agent can chain calls in ways the designer never expected. Fine-grained verbs, resource-specific scopes, and policy-enforcing proxies narrow that blast radius, but the governance lesson is broader: authority must be defined in terms of what can be done next, not just what was provisioned once.

Short-lived credentials are necessary, but short-lived authority is the real control objective. Minute-scale tokens reduce exposure, yet the article also shows that cached credentials, transcripts, logs, and tool outputs can extend the life of a grant beyond the token itself. The practical conclusion is that NHI governance for agents cannot stop at rotation. It has to account for every place the credential can reappear and be reused.

Context-aware authorization is the bridge between NHI governance and agentic AI oversight. ABAC-style decisions, out-of-band approval, and provenance checks create a control plane that can evaluate agent intent without trusting the prompt. That matters because agent behaviour is not just another NHI workload pattern. It is a runtime decision system that can turn untrusted content into privileged action, which is why policy must judge context, not only identity.

Runtime authorization checks assume the agent is an NHI with bounded behaviour, but the article shows how quickly that assumption erodes. The assumption that a principal's authority is stable long enough to review was designed for static service accounts and conventional workloads. That assumption fails when the actor can decide, chain, and execute multiple tool calls inside one session. The implication is that review-based governance alone cannot explain or constrain agent behaviour.

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 how slowly remediation can catch up to exposure.
• For lifecycle discipline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for offboarding and revocation patterns that reduce persistence.

What this signals

Identity blast radius: as agent adoption expands, the governance challenge shifts from proving who authenticated to limiting what an authenticated agent can still do after the first tool call. That is why short-lived credentials, context-aware policy checks, and isolated execution environments need to be treated as one control set, not separate projects.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs, agent programmes inherit a structural exposure problem before they even reach production. Teams should assume every cache, transcript, and error report is part of the credential lifecycle.

Enterprises should also align agent controls with the NIST AI Risk Management Framework and OWASP Agentic AI Top 10, because the decision surface is now behavioural as much as it is technical. The practical signal is simple: if policy cannot explain a tool call after the fact, governance is already behind the agent.

For practitioners

• Issue separate agent principals Register each agent or deployment as its own service identity, then use delegation flows when it acts for a user so the audit trail preserves both principals.
• Narrow scopes to task-level capabilities Replace broad roles with verbs tied to specific resources, and put a policy-enforcing proxy in front of APIs that cannot express that granularity natively.
• Move approval out of the agent context Route destructive or irreversible actions through a channel the agent cannot forge, such as a separate authenticated UI or signed approval workflow.
• Sandbox every tool with its own boundary Isolate code execution, browsing, and file editing in sandboxes with separate identities, restricted egress, and no shared secrets with the orchestrator.
• Test revocation before deployment Exercise deprovisioning, token revocation, and cache invalidation for every agent identity before the next production rollout.

Key takeaways

• AI agent access control fails when teams treat agents like ordinary applications instead of delegated principals with their own authority boundaries.
• The exposure problem is already large, with 80% of identity breaches involving compromised non-human identities and many secrets remaining valid days after notification.
• The control answer is not one mechanism but a stack of separate agent identity, narrow scopes, runtime policy, out-of-band approval, and revocation testing.

Key terms

• Agent Principal: An agent principal is a distinct identity issued to an AI agent so it can authenticate and be audited separately from the human it serves. In practice, it should have its own lifecycle, scoped credentials, and revocation path, because borrowing a human session collapses accountability and widens blast radius.
• Capability-Based Authorization: Capability-based authorization grants narrowly defined verbs on specific resources instead of broad role membership. For AI agents, that means the token should allow only the exact task steps required, because probabilistic behaviour can turn coarse permission into chained misuse.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Confused Deputy: A confused deputy is a privileged system that is tricked into using its authority on behalf of an attacker. In agent environments, the risk appears when retrieved content, prompts, or tool outputs cause the agent to perform actions that exceed the user's true permissions.

Deepen your knowledge

AI agent access control is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing governance for delegated agents, it is a practical place to pressure-test your model.

This post draws on content published by WorkOS: Best practices for AI agent access control. Read the original.