According to the IBM Cost of a Data Breach Report 2024, the average cost of a data breach reached $4.88 million, the highest figure in the study's 19-year history. A significant share of those breaches trace back to compromised credentials and overprivileged identities. Now add AI agents to the mix: autonomous, API-calling programs that act on behalf of users and organizations, often across multiple systems simultaneously. Your existing IAM model was designed for humans. It won't hold.
AI agent identity and access control is the discipline of assigning verifiable identities to autonomous software agents, defining what those agents are permitted to do (and under what conditions), enforcing those policies at runtime, and producing an auditable record of every action taken. It extends classical IAM concepts like least privilege, token scoping, and role assignment to non-human principals that spawn dynamically, delegate sub-tasks to other agents, and operate across multi-tenant enterprise environments.
This article gives you a principled framework for thinking through the problem: what agent identity actually means, why RBAC breaks down at scale, when to reach for ABAC or FGA, how to handle multi-agent delegation safely, and what a production-ready reference architecture looks like.
Key Takeaways
NIST SP 800-207 defines Zero Trust Architecture on the principle that no principal, human or machine, is implicitly trusted; every access decision must be evaluated per-request.
Google's Zanzibar paper (2019) introduced the relation-tuple model that powers OpenFGA and underpins fine-grained authorization at Google scale (trillions of ACL entries, low-millisecond latency).
OWASP LLM Top 10 (2025) ranks LLM01 Prompt Injection and LLM02 Insecure Output Handling as the top two risks for LLM-based agents, both exploitable when agents lack tight permission scopes.
Multi-agent delegation (Agent A spawning Agent B) requires explicit scope downscoping: the child agent must never receive more privilege than the parent, per the principle of least privilege.
OpenFGA, Permify, and SpiceDB are the three most widely adopted open-source implementations of Zanzibar-style FGA as of 2025.
Disclosure: Research completed May 2026. Hands-on experience: partial (familiar with IAM patterns, OAuth 2.0, RBAC/ABAC from enterprise auth implementations; FGA reviewed from OpenFGA documentation and the Google Zanzibar paper). AI assistance: drafting-reviewed. Conflicts of interest: none. Sponsorship: none.
Why Does Human IAM Break Down for Agents?
Traditional IAM is built around a mental model of a human at a keyboard: one person logs in, gets a session token, takes some actions, logs out. Sessions are short-lived, scope is broad (the user gets access to their whole account), and anomaly detection is calibrated to human typing speeds and working hours.
Agents violate every assumption in that model.
An AI agent might call 200 API endpoints in 30 seconds. It acts without a session timeout. It can be instantiated hundreds of times in parallel for different tenant contexts. It receives instructions at runtime from other agents, orchestration frameworks, or LLM completions that could contain adversarial content. According to OWASP's LLM Top 10 for 2025, LLM01 Prompt Injection is the highest-ranked risk: an attacker-controlled input convinces an agent to act outside its intended authorization boundary.
Four properties make agents fundamentally different principals:
Non-interactive: Agents don't authenticate through a browser. They need machine-to-machine credentials (client credentials, signed JWTs, API keys) that don't require human interaction.
Ephemeral and parallel: A pipeline might spawn 50 agent instances; each needs its own identity scope, and tokens can't be shared across instances.
Delegated authority: An agent acts for a human or organization. The permission it holds is borrowed, not owned. When that human's access is revoked, the agent's access must be revoked too.
Composable: Agents spawn sub-agents. Permissions must compose correctly without silently escalating.
To build identity for agents correctly, you need to define four attributes per agent type: an agent ID (a stable, durable identifier for the agent class), an owner (the human or organization on whose behalf it acts), a capability set (the explicit list of actions it's permitted to take), and a trust level (how much the system trusts claims made by or about this agent). These four attributes are the foundation of every access control pattern covered below.
For a primer on how enterprise SSO tokens flow in B2B contexts, see Enterprise SSO Implementation for B2B SaaS: Best Practices and Case Studies.
What Are the Three Access Control Models for Agents?
Not every agent needs the same authorization model. The right choice depends on the complexity of your permission space, the rate of policy change, and the performance constraints of your system.
RBAC: Simple, Coarse-Grained, Fast
Role-Based Access Control assigns permissions to roles and assigns roles to principals. For agents, this means creating roles like agent:read-only, agent:data-pipeline, or agent:admin-assistant and assigning them to agent IDs at provisioning time.
RBAC is fast (role lookup is O(1)), easy to audit (roles are explicit), and well-supported by every major identity provider. It's the right starting point for most teams.
The failure mode for RBAC with agents is over-privilege creep. Because roles are coarse-grained, you end up granting the entire data-pipeline role when the agent only needs read access to one specific data source for one tenant. According to NIST SP 800-207, Zero Trust Architecture requires per-request access evaluation, not just initial authentication. RBAC alone doesn't give you that granularity.
RBAC works for simple SaaS agents that interact with a narrow, fixed set of resources on behalf of the operator (not individual end users).
ABAC: Context-Aware, Dynamic, Flexible
Attribute-Based Access Control evaluates access policies against attributes of the principal (agent ID, trust level, owning organization), the resource (tenant ID, classification, sensitivity), and the environment (time of day, request rate, IP reputation).
An ABAC policy might read: "allow this agent to read customer records if the record's tenant_id matches the agent's owner_tenant_id and the request originates from an approved datacenter IP range."
This is meaningfully more powerful than RBAC because the same agent can behave differently across tenants and contexts without needing a separate role per combination. The tradeoff is policy complexity: ABAC policies expressed in XACML or Cedar can become difficult to reason about, test, and debug at scale. AWS Cedar, which powers Amazon Verified Permissions, is a modern ABAC policy language designed to be more auditable than XACML.
ABAC is well-suited for multi-tenant enterprise agents where the same agent class serves dozens of organizations but each organization gets contextually isolated access.
FGA: Fine-Grained, Relationship-Based, Zanzibar-Inspired
Fine-Grained Authorization (FGA), specifically Relationship-Based Access Control (ReBAC), encodes permissions as first-class relationships between principals and resources. Rather than a flat role or a set of attributes, the authorization engine evaluates a graph of relationships.
Google published the Zanzibar paper in 2019, describing how they handle authorization for Google Drive, YouTube, and Calendar at a scale of trillions of ACL entries with p99 check latency under 10 milliseconds. Zanzibar introduced the concept of relation tuples: (object, relation, subject) triples like (document:budget-2025, viewer, agent:pipeline-456).
OpenFGA is the CNCF-hosted open-source implementation of Zanzibar. You define an authorization model (a schema of object types and relations), write tuples to a store, and query it: "does agent:pipeline-456 have the read relation on document:budget-2025?" OpenFGA handles transitive relations: if the agent is a member of group:finance and group:finance has viewer on the document, the check resolves correctly through the graph.
For agents, this matters enormously. Agent A can be delegated viewer on a specific document by User X, and that delegation is a tuple in the store: explicit, revocable, and scoped to exactly that resource. When User X's access is revoked, you delete the tuple, and the agent's access disappears without touching any role definition.
OpenFGA, Permify, and SpiceDB are the three dominant open-source Zanzibar implementations in production use. Auth0's FGA product (now Okta FGA) is the managed commercial equivalent.
For teams building complex multi-tenant platforms, FGA is the right end state. Getting there incrementally from RBAC is possible: start with coarse roles, layer ABAC for tenant isolation, and migrate resource-level permissions to FGA tuples as the permission space grows.
For related context on how user authentication best practices intersect with machine identity, the overlap is tighter than most teams expect.
How Should Multi-Agent Delegation Work?
This is the hardest unsolved problem in agentic IAM today. When Agent A (an orchestrator) spawns Agent B (a sub-agent), what permissions should Agent B receive?
The naive answer is "the same permissions as Agent A." That's wrong, for the same reason you don't give a contractor the same system access as the CTO who hired them.
The correct model is scope downscoping with explicit delegation tokens. Agent A, when spawning Agent B, issues a delegation token that is:
Bounded by Agent A's own scope. Agent B cannot receive permissions that Agent A doesn't hold. This is the containment property.
Further restricted to the sub-task. If Agent A has read/write on the full document store but Agent B only needs to read three specific files to summarize them, the delegation token scopes Agent B to exactly those three files.
Time-bounded. Delegation tokens should expire when the sub-task is expected to complete. An orphaned sub-agent with a long-lived token is a privilege escalation vector.
Linked in the audit trail. The delegation chain (User X delegated to Agent A; Agent A delegated to Agent B for sub-task Y) must be recorded so that a full causality chain exists for every action.
In OAuth 2.0 terms, this maps to Token Exchange (RFC 8693): Agent A presents its access token to an authorization server and requests a new token (for Agent B) with a restricted scope. The authorization server enforces containment and issues a downscoped token. This is the current industry-standard mechanism for machine-to-machine delegation chains.
For the FGA layer, multi-agent delegation means writing a temporary relation tuple: (task:summarize-q1-report, executor, agent:sub-agent-B) with a TTL. When the task completes or the TTL expires, the tuple is deleted.
One more risk to call out: OWASP LLM Top 10 (2025) flags LLM02 Insecure Output Handling as a top-tier concern. If Agent A passes LLM-generated instructions to Agent B without sanitization, an attacker who influenced Agent A's output can effectively inject arbitrary instructions into Agent B's execution context, bypassing the IAM layer entirely at the semantic level. Your access control model must be paired with output validation at every agent boundary.
What Do Audit Trail Requirements Look Like for Regulated Industries?
Access control is only as useful as your ability to prove what happened after the fact. For teams operating in regulated industries (healthcare, finance, government), the audit trail for AI agents is not optional: it's a compliance requirement.
A production audit trail for agents needs six fields per event:
Field
|
Description
|
Example
agent_id
|
Stable identifier for the agent class
|
agent:pipeline-v2
|
|
instance_id
|
Per-invocation identifier
|
inv-8a7f3c
|
|
owner
|
Human or org on whose behalf the agent acted
|
org:acme-corp / user:jane@acme.com
|
|
action
|
Specific operation performed
|
documents.read
|
|
resource
|
Resource accessed, at the finest granularity available
|
document:budget-2025-q1
|
|
delegation_chain
|
Full chain of delegation if applicable
|
user:jane -> agent:orchestrator -> agent:summarizer
|
Beyond the six required fields, you need tamper-evident storage (append-only logs, preferably with cryptographic chaining), real-time anomaly detection (an agent making 10x its normal request rate is a signal), and automated compliance reporting for SOC 2 Type II and HIPAA audit cycles.
For FGA systems, OpenFGA provides a built-in read API that returns all relationship tuples for a given object. This is useful for post-incident forensics: given a breach, you can reconstruct exactly which agents had access to which resources at any point in time, if you snapshot tuple state on change.
NIST SP 800-63B establishes authenticator assurance levels; for agents operating on behalf of individuals in regulated contexts, you should match the agent's credential assurance to the sensitivity of the resources it accesses. A clinical data pipeline agent accessing PHI should use a hardware-backed credential or a signed JWT with a short expiry, not a long-lived API key.
For teams integrating directory sync to manage agent lifecycle (provisioning and deprovisioning agents as organizations onboard and offboard), Directory Sync for B2B SaaS covers the SCIM-based patterns that apply equally to human and non-human principals.
Reference Architecture: Agent Types Mapped to IAM Patterns
The right IAM pattern depends on the agent type. Here's a decision table:
Agent Type
|
Description
|
Recommended IAM Pattern
|
Suggested OAuth Flow
|
FGA Needed?
Simple SaaS Agent
|
Single-tenant, narrow API scope (e.g., a Slack bot)
|
RBAC with coarse roles
|
Client Credentials (RFC 6749)
|
No
|
|
Autonomous Pipeline Agent
|
Multi-step, multi-resource workflows; runs unattended
|
RBAC + ABAC for resource isolation
|
Client Credentials + Token Exchange (RFC 8693) for sub-tasks
|
Optional
|
|
User-Delegated Agent
|
Acts on behalf of a specific user (e.g., an email assistant)
|
ABAC with user-context attributes
|
Authorization Code + Token Exchange
|
Yes, for per-resource delegation
|
|
Multi-Tenant Enterprise Agent
|
Same agent class, many orgs, sensitive data
|
ABAC + FGA (Zanzibar-style tuples)
|
JWT with tenant claims + Token Exchange
|
Yes, required
|
A few implementation notes for each:
Simple SaaS Agent: Use your existing identity provider's machine-to-machine application type. Generate a client ID and secret, configure a minimal scope, rotate secrets every 90 days. This is a solved problem.
Autonomous Pipeline Agent: The key discipline here is ensuring the pipeline's orchestrator requests only the scopes it needs per step, not a superscope at startup. Use Token Exchange to mint step-specific tokens. Log every token exchange event.
User-Delegated Agent: The user's consent must be captured at OAuth authorization time and recorded. If the user revokes consent (deauthorizes the agent), all outstanding tokens derived from that consent must be invalidated. This requires a token revocation lookup on every request; build it into your middleware.
Multi-Tenant Enterprise Agent: This is where OpenFGA earns its complexity cost. Write tuples per tenant onboarding, use FGA to enforce data isolation at the resource level, and build an automated tuple cleanup job that runs on tenant offboarding. For teams deploying enterprise SSO as part of this stack, SSOJet's enterprise-ready SSO infrastructure handles the human-side identity layer, giving agent identity a reliable principal hierarchy to anchor to.
What Should Your Agent Identity Provisioning Lifecycle Look Like?
Agents need a defined identity lifecycle, just like human employees. Skipping this leads to orphaned credentials — a known vector per the Verizon Data Breach Investigations Report 2024, which identified 80% of breaches involving web applications using some form of stolen or orphaned credential.
The agent lifecycle has four stages:
1. Provisioning: Issue a unique agent_id, register the agent with your authorization server, assign initial roles or write initial FGA tuples. Generate short-lived credentials (JWTs with a 1-hour TTL for most agents; 24 hours maximum for batch pipelines).
2. Active: Monitor request rates, scope usage, and error patterns. Any agent consistently using only 10% of its assigned scope is over-privileged — trim the scope. This is automated least-privilege enforcement.
3. Rotation: Rotate agent credentials on a schedule. For sensitive agents, rotation should be automatic via your secrets manager (HashiCorp Vault, AWS Secrets Manager). Never hard-code agent credentials in application code.
4. Deprovisioning: When an agent is retired, immediately revoke all tokens, delete FGA tuples, and archive the audit trail. Automated deprovisioning triggered by CI/CD pipeline events (deploying a new agent version should retire the old one) is the standard practice.
This lifecycle maps cleanly onto how SAML and OAuth 2.0 handle session state for human sessions — the concepts transfer directly, with automated triggers replacing human logout events.
Frequently Asked Questions
What is the difference between RBAC and FGA for AI agents?
RBAC assigns permissions through coarse-grained roles (e.g., agent:read-only), which are fast and simple but grant broader access than an agent often needs. FGA (Fine-Grained Authorization) encodes permissions as explicit relationship tuples between agents and individual resources (e.g., document:budget-q1, viewer, agent:pipeline-456), enabling per-resource access decisions that are individually revocable. For agents operating across multi-tenant data, FGA provides the precision RBAC cannot.
How should OAuth 2.0 Token Exchange (RFC 8693) be used for multi-agent delegation?
When an orchestrator agent (Agent A) needs to spawn a sub-agent (Agent B), Agent A presents its access token to the authorization server and requests a new token for Agent B with a restricted scope (downscoped to only what the sub-task requires). RFC 8693 defines the exact protocol for this exchange. The resulting token is bounded by Agent A's permissions, time-limited to the sub-task's expected duration, and linked to Agent A's token in the audit trail for full causality tracking.
What is Google Zanzibar and why does it matter for AI agent authorization?
Google Zanzibar is Google's internal authorization system, described in a 2019 research paper, that handles access control for Google Drive, YouTube, and Calendar at trillions of ACL entries with sub-10-millisecond check latency. It introduced the relation-tuple model (object, relation, subject), which makes per-resource, per-principal authorization decisions highly scalable. OpenFGA, Permify, and SpiceDB are open-source implementations of the same model, making Zanzibar-style FGA accessible to teams outside Google.
What audit trail fields are required for AI agents in regulated industries?
At minimum, every agent action should record: agent ID (stable class identifier), instance ID (per-invocation), owner (the human or org on whose behalf the agent acted), action performed, resource accessed at the finest available granularity, and the full delegation chain if the agent was spawned by another agent. Logs should be stored in tamper-evident, append-only storage. For HIPAA and SOC 2 compliance, real-time anomaly detection on agent request rates and automated compliance reporting are also expected.
How does agent identity interact with enterprise SSO?
Enterprise SSO handles authentication and session management for human users. Agent identity anchors to that same identity infrastructure: the organization's IdP (SAML or OIDC) establishes the principal hierarchy (which organizations and users exist), and agent identities are provisioned as machine clients within that hierarchy. When a user is deprovisioned from the IdP, cascading deprovisioning should revoke all agent credentials that were issued under that user's delegated authority. SSOJet's SSO for B2B SaaS provides this infrastructure layer for teams that need enterprise SSO without building it from scratch.
Final Thoughts
Agent identity isn't a future problem. If you're deploying LLM-based features to enterprise customers today, you're already creating non-human principals that need proper identity hygiene. Starting with RBAC is fine. The mistake is staying there as agents become more complex, more numerous, and more deeply integrated into sensitive workflows.
The progression is straightforward: RBAC for simple agents, ABAC for multi-tenant isolation, FGA for fine-grained per-resource delegation, and Token Exchange (RFC 8693) for safe multi-agent delegation chains. Layer in tamper-evident audit logs from day one, because retrofitting observability into an agent fleet after a security incident is expensive and slow.
Your human IAM investment doesn't go to waste here. The identity provider, the token infrastructure, the audit pipeline, the SSO layer — all of it extends to agents. What you're adding is a principled framework for non-human principals, not a parallel system.
