Agents need Authorization, not just Authentication

Every major architectural shift exposes the limits of our access control models. Multi-tenant SaaS broke filesystem permissions. Microservices broke monolithic session management. Now, AI agents are breaking the authorization patterns we spent the last decade standardizing.

Agents are already operating inside enterprise infrastructure. They summarize documents, triage tickets, and manage cloud resources. Yet most authenticate using the same primitives as humans: an OAuth token, a session cookie, or a service account key. They inherit the user's full access or operate with broader privileges than any single user should possess.

The Confused Deputy problem

To understand the architectural risk, consider the "Confused Deputy" problem. In security theory, a deputy is a program with authority to act that is tricked by a lower-privileged user into misusing that authority.

Consider a Platform Engineering team that deploys a "Cluster Debug Agent" to troubleshoot Kubernetes deployments. The agent uses a service account with secrets:read access to verify configuration maps.

The trigger: A developer debugging a payment service crash needs to see production environment variables. They lack direct access to production secrets, which are restricted to SREs. They ask the agent: "Diff the production environment variables against staging so I can see what changed."

The action: The agent executes the query. It possesses the secrets:read permission, so the cluster control plane allows the request.

The result: The agent posts the diff to a shared Slack channel.

	
- STRIPE_SECRET_KEY: "sk_test_..."
+ STRIPE_SECRET_KEY: "sk_live_51M..."
  

A production API key is effectively leaked to fifty people.

No misconfiguration occurred. The agent acted within its permissions (secrets:read) and the developer acted within theirs (chat:write). The system failed because it did not check the intersection of their privileges. The agent acted as a confused deputy and bypassed the IAM controls intended to restrict the developer.

This forces every team to answer a specific question: When an agent acts on behalf of a user, whose permissions apply?

Agents are not users. They are not service accounts.

The identity industry is currently defining where agents fit in the IAM stack.

Microsoft introduced Entra Agent ID as a native identity class. NIST published a concept paper on agent identity in February 2026. The IETF is standardizing the /Agents resource in SCIM.

The consensus is that agents are a distinct identity class requiring purpose-built infrastructure. However, the industry focus remains on Authentication (proving identity). The unsolved engineering challenge is Authorization (enforcing capabilities).

The intent gap

Traditional service accounts are deterministic. A CI/CD runner has a fixed scope to pull code and push artifacts. You define the access once and it rarely changes because the runner never generates its own intent.

Agents differ in two fundamental ways.

First, they generate intent. A traditional OAuth client forwards a user's request. An agent reasons about a problem and decides which tools to invoke.

Second, their scope is non-deterministic. You cannot predict at design time what an agent will need. A coding agent might need read access to repo:backend today and write access to repo:frontend tomorrow.

Solving this with static roles forces a binary trade-off. You either block the agent from functioning or grant it broad admin access.

The two modes of agent authorization

Agent implementations typically fall into one of two patterns. Each introduces specific authorization requirements.

1. On-Behalf-Of (OBO) agents

These serve as extensions of a human user, like Claude Code or GitHub Copilot. They operate specifically within a user’s session.

The security requirement here is Scope Attenuation. The agent should access a subset of the user's permissions, never the full set. If a user asks an agent to refactor a specific file, it should not have access to sensitive configuration files in the parent directory.

Currently, most OBO agents inherit the user's full access token.

The MCP gap

The Model Context Protocol (MCP) is becoming the standard interface for these agents. However, it explicitly delegates authorization to the implementer.

MCP currently relies on OAuth 2.1 scopes like files:read. Scopes are coarse strings. files:read grants access to every file the user can see, from a README to a production .env file. The spec recommends "scope guidance" but leaves granular enforcement to the application logic.

Even as protocols adopt Rich Authorization Requests (RFC 9396) to allow structured intent like {"file": "main.rs"}, this remains a data format. It acts as an envelope for the request but provides no logic to evaluate whether the request should be granted.

The shared context trap

Scope attenuation fails in shared contexts.

Consider a "Finance Assistant" agent added to a team Slack channel. The agent authenticates with the CFO’s credentials. A junior analyst asks about Q3 budget projections.

The agent checks its own permissions, confirms the CFO has access, and posts the data. The junior analyst now sees executive compensation data they are not authorized to view.

Traditional authorization checks happen at retrieval. Shared contexts require checking authorization at output by calculating the intersection of permissions across all audience members. Traditional RBAC cannot model this graph.

2. Autonomous agents

These operate without a user loop, such as a security bot rotating keys or a billing agent reconciling invoices.

Identity is largely solved here. Microsoft Entra Agent ID allows these agents to authenticate via the client_credentials flow with a distinct Client ID. This ensures audit logs attribute actions to Agent-007 rather than a human user.

The "God Mode" problem

The authorization layer remains flawed. In a standard client_credentials flow, the resulting token often dictates broad access. To allow a billing agent to read invoices, you generally grant the Files.Read.All scope.

This results in a "God mode" agent. It can read invoices, but also employee contracts and patent drafts. You cannot easily scope a standard OAuth token to "Read only files in the Finance folder." This effectively grants root access to a probabilistic script.

Why "flat" RBAC fails the agent test

If agents require limited scope, the obvious question is: "Why not just create a specific role?" Why not create a Billing_Agent role and be done with it?

The failure lies in the geometry of the authorization model. Traditional Role-Based Access Control (RBAC) is flat. It maps a subject to a role, and a role to a set of global permissions (read:repos). This works for humans because human access usually correlates to job title, which is stable and broad.

Agent access correlates to tasks, which are transient and specific.

You do not want an agent to be an "Editor of Repositories." You want to enforce: "This agent can edit code on branch:feature-xyz in repository:api, and nothing else."

To express this in flat RBAC, you would need to create a unique role for every permutation of resource and permission:

• Role: Editor_Repo_API_Branch_XYZ
• Role: Viewer_Repo_Frontend_Branch_ABC

In an enterprise with thousands of repositories and ephemeral branches, this triggers a combinatorial explosion. You move from managing O(1) roles to O(N x M) roles. The friction of managing these static roles exceeds the velocity value of the agent itself.

The fix: FGA = RBAC + hierarchy

This is where Fine-Grained Authorization (FGA) comes in. It isn't a replacement for the concepts you know; it is a natural extension of RBAC.

To solve this, we do not need to abandon RBAC. We need to scope it. This is the definition of Fine-Grained Authorization (FGA).

FGA is not a replacement for the concepts you know; it is the application of RBAC to a resource hierarchy.

	
Organization: Acme
 └── Repository: API
       └── Branch: feature-xyz  <-- Agent Permission Starts Here
             └── Actions: [push, merge]
  

You keep the familiar mental model of roles (Editor, Viewer), but you attach them to specific nodes in the graph rather than the root.

1. Vertical inheritance: An agent assigned Editor on Branch: feature-xyz automatically inherits access to every file and action inside that branch.
2. No lateral movement: Crucially, that permission does not bleed sideways to Branch: staging or upwards to Repository: API.

In this model, the agent possesses full power where it is required and zero power everywhere else.

Scaling the graph: Structural Resources vs. Asset Data

A common concern when adopting a centralized authorization service is the overhead of state synchronization. If your application manages millions of individual assets, you might assume every single one needs to be mirrored into the FGA graph. In practice, you only sync the Structural Hierarchy, not the Asset Data.

Think of FGA as the skeleton of your permissions. You register the high-level containers that define your access boundaries: Organizations, Workspaces, and Projects. These are your Structural Resources. Your high-volume Asset Data, such as individual files within a folder or images in a project, stays in your primary application store.

When an agent requests access to a specific asset, your application logic performs a simple two-step check:

1. Application logic: Identify which container (e.g., Folder: Q3-Financials) the asset belongs to.
2. FGA: Ask check(subject=Agent, role=viewer, resource=Folder:Q3-Financials).

By checking access against the parent container rather than the individual asset, you keep the authorization graph lean and maintain sub-50ms latency. You avoid the "double-write" consistency issues that plague massive data syncs, gaining granular security without the infrastructure cost of a full database mirror.

How FGA solves the two agent modes

Once you establish a hierarchical model, the authorization problems identified earlier (Scope Attenuation and God Mode) become solvable through standard architectural patterns.

1. Solving OBO agents: The intersection check

For On-Behalf-Of agents, the goal is to prevent the "Confused Deputy" problem. Even if the user has broad access, the agent should only have access to what is relevant for the current task.

FGA solves this by calculating the Intersection of permissions. You can define a policy that requires both the user and the agent to have access before granting a request.

This transforms the authorization check from a static role lookup into a dynamic validation. When an MCP server receives a tool invocation like read_file(path="/secrets.json"), it performs a real-time check against the FGA graph:

	
Input: check(subject=Agent, role=viewer, resource=file:secrets.json)
Output: FALSE (Access Denied)
  

This allows the server to return a precise 403 Forbidden for sensitive resources dynamically. It does not require the user to restrict the agent's broad OAuth token manually.

FGA as the logic layer for MCP

‍As protocols like MCP mature to support Rich Authorization Requests (RFC 9396), agents will pass structured intent objects instead of opaque strings. For example: {"file": "main.rs", "action": "edit"}.

It is important to remember that RAR is just a data format. It acts as an envelope for the request but provides no logic to decide if the request is valid. The RAR object does not understand that /backend belongs to Team A, or that the user is an Admin of Team A.

If you rely solely on RAR, developers must still write complex logic to traverse those relationships. FGA solves this by handling the hierarchy natively. It acts as the decision engine that validates the RAR envelope against the organization's actual permission graph.

The memory leak: Securing long-term context

As agents evolve from stateless scripts to persistent collaborators, they have begun to store "memory" in vector databases. This creates a new security shadow: if an agent summarizes a sensitive document into its long-term memory, that information can be "hallucinated" back to a different user who lacks access to the original source.

To prevent context leaks, developers should treat agent memory as a protected resource and apply the same FGA policies to an agent's "recollections" as they do to the source files:

• Metadata tagging: Every embedding written to a vector store should be tagged with its source resource_id.
• Filtered retrieval: When the agent queries its memory, the application must augment the vector search with an FGA check. If the current user cannot access the source resource_id, the memory remains invisible to the agent.
• Context sharding: High-security environments should use ephemeral memory shards that are flushed when an agent moves between different FGA project nodes.

By anchoring embeddings to FGA resource IDs, you ensure that an agent’s internal context is as strictly governed as its real-time actions.

2. Solving autonomous agents: The scoped role

For autonomous agents, the goal is to prevent "God Mode" where a specific bot inadvertently gets root access to the entire tenant.

FGA acts as the constraint layer over the agent's broad identity.

1. Identity: The Identity Provider (IdP) proves the agent is the "Billing Bot.”
2. Authorization (FGA): The application asks if the Billing Bot can read file:executive_comp.pdf.
3. The check: FGA sees the agent has the Viewer role on the Project:Finance node but not on the Project:HR node. Access Denied.

In this model, the agent is its own subject. It receives roles directly on the resources it needs. When the agent is decommissioned, you simply remove its role assignment on that specific node. Access instantly disappears across the entire subtree.

The Identity Provider gives you the secure handle. WorkOS FGA gives you the grip. Without FGA, autonomous agents are effectively high-speed scripts with root access to the entire tenant.

Agent enterprise governance

In a traditional enterprise environment, access follows the employee lifecycle. When a user is onboarded via the Identity Provider (IdP), they get a set of roles. When they leave, their access is revoked.

Agents break this flow. Unlike humans who log out or change jobs, agents are persistent. Their tokens remain valid and their service accounts stay active indefinitely. Recent data shows that the average enterprise credential remains active for 47 days after it is no longer needed. When agent identities multiply, manual lifecycle management becomes impossible and creates a massive surface area for credential harvesting.

WorkOS FGA enables centralized governance over the entire agent lifecycle by bridging the gap between your IdP and your application’s internal resource hierarchy. Standard IdPs are excellent at managing groups but blind to your internal resources. FGA provides the "last mile" of authorization, ensuring agent access is governed by the same SSO and SCIM infrastructure used for human employees:

1. Provisioning: An admin creates the agent in the IdP (or via a future SCIM /Agents endpoint) and assigns it to a functional group, such as Project-X-Automations.
2. Automated onboarding: WorkOS Directory Sync detects the new identity and its group memberships instantly, provisioning the agent within your application without manual intervention.
3. Scoped governance: Your application uses that group membership to assign a resource-scoped role in FGA, such as Editor on Project: X. The agent is immediately constrained to that specific project subtree.
4. Instant de-provisioning: When the agent is removed from the group or deactivated in the IdP, its role assignment in FGA is revoked across all services simultaneously.

This architecture ensures that agent credentials never outlive their intent. By coordinating identity with hierarchical authorization, you provide the automated deprovisioning and audit trails that enterprise IT departments demand.

What comes next

We are at an inflection point. The infrastructure for agent identity is being built by Microsoft, Okta, and IETF working groups. Protocols like MCP are rethinking the interface for authorization from the ground up.

The missing piece is the authorization layer itself. It is not enough to ask if an agent can call an API. We must ask if an agent can perform a specific action on a specific resource based on the delegating user, organizational policies, and the resource hierarchy.

Several complex problems remain unsolved. These are the areas where we are investing next.

User groups as authorization subjects

Groups are becoming first-class subjects in FGA. You will be able to assign a role to an IdP group on a specific resource, such as the engineering group on workspace:platform. Every member, whether human or agent, will inherit the appropriate permissions automatically. When a principal joins or leaves a group in the IdP, their access updates in real time.

FGA role assignments

A major hurdle in enterprise governance is mapping flat IdP (ex: Okta, Entra) groups to nested resources. We are building FGA Role Assignments to bridge this gap natively. This feature allows you to define a mapping between an IdP group (e.g., "Project-X-Bots") and an FGA role on a specific resource subtree (e.g., Viewer on Folder: NA-Prospects). When a user or agent is added to that group in the IdP, SSO or Directory Sync automatically creates the corresponding role assignment in FGA. This eliminates the need for "glue code" to manage the relationship between your identity source and your resource graph.

Agent-to-agent delegation

When agents spawn sub-agents or delegate tasks, each link in the chain requires attenuated scope. A token passed to a sub-agent should carry less privilege than the original. FGA’s hierarchical model is a natural fit for this. Each delegation step constrains the sub-agent to a narrower sub-tree of resources. We are building first-class support for these delegation chains so that scope attenuation is enforced by the authorization system instead of custom application logic.

SCIM provisioning for agents

The IETF SCIM agent schema draft introduces /Agents as a resource type with ownership requirements and dormancy detection. As this standard matures, WorkOS Directory Sync will provision agents much like it provisions users today. IdP group memberships will map directly to FGA resource-scoped roles, automating the entire lifecycle.

Global low-latency authorization

Agents operate at machine speed and often across multiple regions. While we currently provide sub-50ms p95 access checks, we are moving toward edge caching and streaming updates to bring that closer to sub-10ms globally. This ensures that authorization decisions do not become a latency bottleneck for agentic performance.

The authorization complexity of agentic software is compounding quickly. If you are building software that agents will operate inside, the time to lay the foundation is now.

WorkOS FGA is available today. Get started here.

The research frontier: Beyond static authorization

The industry is at a crossroads. As of early 2026, the foundational elements of agent identity are beginning to coalesce, but several high-order authorization problems remain in the research phase. At WorkOS, we are paying close attention to these shifts. We view FGA as a living infrastructure that must evolve alongside the probabilistic nature of AI.

There are three specific domains where the gap between standard authorization and agentic reality is widest.

1. Multi-hop delegation and provenance

In advanced multi-agent systems, a primary agent often decomposes a request into sub-tasks and delegates them to specialized sub-agents. This creates a "Russian Nesting Doll" effect: each handoff crosses a trust boundary, yet cryptographic lineage is often lost by the third or fourth hop.

Current research into Authorization Provenance suggests that the "Who" is no longer a single subject, but a chain. If a Research Agent authorized for public data spawns a Code Agent authorized for private repos, the resulting access must be the intersection of every entity in that lineage. Closing this gap will require authorization engines that can verify a "chain of custody" for every tool call, ensuring that permissions aren't just checked, but traced back to their origin.

The IETF has been actively working on extending OAuth to handle exactly this kind of "Russian Nesting Doll" delegation.

2. Just-in-Time (JIT) agency

Traditional service accounts rely on "standing privileges"—access that is always active. For a machine-speed agent, standing privileges are a massive liability. If an agent has a static API key with write access, a single successful prompt injection can result in instant, irreversible data exfiltration.

The concept of Just-in-Time Agency moves toward a model of Zero Standing Privileges. In this future, an agent possesses no authority until a specific task is triggered. The authorization engine then grants a temporary, short-lived role assignment that expires automatically when the transaction completes. This reduces the attack surface to the absolute minimum required for the work at hand, moving security from a static state to a transient one.

The concept of Zero Standing Privileges (ZSP) for agents is being championed by both NIST and the OWASP Top 10 for Agentic Applications.

3. The semantic future: Intent-Based Access Control

Unlike deterministic code, agents are probabilistic. Over a long-running session, an agent’s actions can "drift" away from the original user intent. An agent that starts by summarizing emails (low risk) might gradually drift into moving files to an external drive (high risk) based on subsequent, ambiguous instructions.

Emerging strategies for Semantic Inspection suggest that authorization should be anchored to the initial task session. If an agent attempts a tool call that is semantically unrelated to its original "root" authorization, the engine should flag this drift. This represents a shift from checking what an agent can do to understanding why it is doing it—creating a layer of contextual guardrails that can trigger a "Human-in-the-Loop" approval before a high-risk action occurs.

The most significant research in this area comes from the intersection of Large Language Model (LLM) observability and "Constitutional AI.”

The ultimate goal of agent authorization is to move beyond deterministic 'Can/Cannot' checks and into the realm of Intent Alignment. We are moving toward a world where policies are defined in natural language—'Don't share customer PII with unverified third parties'—and enforced by an authorization layer that understands the reasoning behind an agent's request.

At WorkOS, we believe FGA is the necessary anchor for this probabilistic future. You cannot rely on an LLM to police itself; you need a deterministic resource graph to provide the ground truth. By linking natural language intent to a fine-grained resource hierarchy, we create the first Semantic Guardrail that can stop an agent not just because it lacks a role, but because its current action deviates from its stated mission.