FGA is not enough for your agent authorization

The WorkOS team released an article discussing agent authorization, presenting a fine-grained authorization (FGA) solution that’s effectively structured hierarchy atop traditional role-based access control (RBAC) methods. This approach is misguided.

We are aligned with WorkOS’s diagnosis of the problem. One of the biggest security issues facing AI is agent authorization. Standard RBAC falls flat for agents. However, hierarchy-based FGA just throws structures at the problem. It lacks the context awareness and rule evaluation needed to protect against modern day attack vectors.

Instead, a policy-based access control (PBAC) strategy is better. PBAC is bounded by rules, not hierarchies, an approach that better protects systems, agents, and data.

Why PBAC beats FGA for agent authorization

Runlayer’s PBAC strategy allows both agent accounts and users to own policies that define what actions they can perform. The PBAC algorithm follows a simple structure: (i) at least one allow with zero denies, (ii) default deny. For any given subject (user or agent), the engine fetches applicable policies, checks scope and principal match, evaluates conditions against full context, then applies “deny-overrides-allow”. If at least one allow policy activates and no deny activates, access is granted. If any deny policy activates, access is denied, regardless. If nothing matches, the algorithm denies by default.

PBAC outperforms other agent authorization flows in three critical ways.

1. PBAC is robust

PBAC policies evaluate against the full request context at runtime, including tool arguments, request metadata, subject attributes, network origin. Runlayer can express cross-cutting constraints that don't fit a resource hierarchy. For example: "this agent can query the database only when the table matches a pattern and the request originates from a corporate network."

In FGA, you'd need custom application logic for this. In PBAC, it's a declarative policy.

2. PBAC is simple and traceable

Runlayer’s evaluation engine is intentionally minimal. There's no role hierarchy to traverse, no graph to walk, or no inheritance chain to resolve. Instead, PBAC evaluation is flat: match policies, evaluate conditions, decide. The simplicity also makes it auditable (every decision can be traced to specific policy IDs logged in the audit trail) and predictable (no surprising inherited permissions from a parent node in a resource tree).

The complexity lives in what policies are written, not in how the engine resolves them.

3. PBAC exhibits Asymmetric Access Control

For on-behalf-of (OBO) agents, the engine evaluates agent policies and user policies independently in sequence. Both must allow for access to be granted. Accordingly, you can write policies that are asymmetric: stricter for delegated agents than for the user. Organizations can grant users broad access while surgically limiting what agents can do with that access.

FGA's intersection check treats both sides symmetrically: it can't express "users can, but agents acting as them can't."

Production-ready agent identities & token architecture

The WorkOS article positions agent identity as a new frontier with custom infrastructure being built by Microsoft, Okta, and IETF working groups.

Runlayer already implements unique agent identities using existing, interoperable standards. Each agent is treated as a first-class OAuth client with its own Client ID and Client Secret, allowing any OAuth-compatible client to participate in the delegation flow without proprietary SDKs. The agent token system is built on top of the following established OAuth RFCs:

• RFC 8693 (Token Exchange): OBO tokens are obtained via standard urn:ietf:params:oauth:grant-type:token-exchange. The agent presents its M2M token as subject_token, the delegating user's identity as actor_token. The resulting JWT carries the RFC 8693 act claim ({"sub": agent_client_id, "act": {"sub": delegator_user_id}}) making the delegation chain machine-readable and standards-compliant.
• RFC 7591 (Dynamic Client Registration): MCP clients can register dynamically.
• RFC 8707 (Resource Indicators): Token requests include a resource parameter binding the token to a specific server.
• RFC 7009 (Token Revocation): Standard revocation endpoint with idempotent behavior.

By using existing OAuth RFCs, Runlayer enables agents to exist as a distinct identity class with their own M2M credentials. Each agent has their own principal type in the policy engine, their own policies separate from users, and their own audit trail. Runlayer’s policy engine can establish dedicated evaluation paths for standalone agents vs agents acting on behalf of users.

Open questions in WorkOS’s approach

In WorkOS’s outlined solution, there remains a few unanswered questions around authorization logistics, end states, and application logic. In particular, the solution mentions PKCE. This opens a few questions:

• When thousands of agents dynamically spawn sub-agents, can the FGA graph absorb the resulting write burst without becoming the bottleneck?
• What happens after "access denied"? What is the agent shown and how is it guided towards resolution, if at all?
• Where does enforcement actually happen?

The WorkOS post leaves these unanswered. However, what we do know is that WorkOS requires application logic to perform a simple two-step check against FGA. Every application consuming agent tool calls must integrate FGA, build the enforcement layer, handle errors, and log decisions.

Authorization alone is insufficient

Runlayer tackles a few other problems to actually secure AI applications. These problems establish why authorization is a necessary but insufficient layer for production agent deployments.

Credential Lifecycle Management

Authorization answers "is this allowed?" but not "how does the agent actually authenticate to the upstream server?" Session resolution, token refresh, expiry detection, re-authorization prompts, and transport abstraction (SSE, streaming HTTP, stdio) are all problems that exist between the authorization decision and the actual tool call.

Content-level security

An authorized tool call can still leak credentials in arguments, return PII in outputs, or contain hidden characters designed to manipulate the agent. Authorization controls if a call happens; it says nothing about what data flows through it. Runlayer scans inputs (credential masking, PII detection) and outputs (hidden character detection, context-aware content scanning) as a separate layer.

Supply chain security for tools

MCP servers are third-party code. A compromised server can inject prompt injection attacks or exfiltration instructions into tool descriptions. Authorization trusts the resource hierarchy is honest. Runlayer runs security scanning on tool definitions during discovery, flagging and blocking malicious metadata before the agent ever sees it.

Large output management

Tool outputs can be massive. Authorization doesn't address the data plane: what happens when a 5MB database dump flows through an authorized call and overflows the agent's context window? Runlayer detects oversized outputs, offloads them, and provides filtered retrieval.

Closing Thought: PBAC wins

PBAC gives you context-aware, auditable, asymmetric access control without the complexity of graph traversal. Agent authorization matters, but it's one layer of a production stack. Get the policy model right, then solve everything around it.

‍