OAuth gives you tokens. Tokens carry scopes. Scopes tell a service that an agent is allowed to “read orders” or “write files.” That’s coarse-grained authorization—and for many applications, it’s enough.
For agentic systems, it isn’t.
An AI agent acting on behalf of a user doesn’t just need to read orders—it needs to read this order, for this customer, as part of this task, in this tenant. Whether that’s permitted depends on relationships, attributes, time of day, risk signals, and policy rules that OAuth scopes were never designed to express. What’s missing is a runtime evaluation layer: something the agent can ask “is this specific action permitted?” before it acts.
That’s the gap AuthZEN fills.
What AuthZEN provides
AuthZEN (OpenID Foundation Authorization API 1.0) defines a single REST endpoint that any application, service, or agent can call to get an access decision:
POST /access/v1/evaluation
The request carries four fields: who is asking (subject), what they want to do (action), what they want to do it to (resource), and ambient conditions (context). The response carries one: a boolean decision.
{
"subject": { "type": "agent", "id": "order-agent-v2", "properties": { "tenant": "acme-corp" } },
"action": { "name": "delete" },
"resource": { "type": "order", "id": "4521", "properties": { "tenant": "beta-corp" } },
"context": { "time": "2026-04-15T09:14:00Z", "delegation_depth": 2 }
}
{
"decision": false,
"context": {
"reason_admin": "Cross-tenant delete denied. Subject tenant 'acme-corp' != resource tenant 'beta-corp'."
}
}
Representing the user in an agent request
When an agent acts on behalf of a user, the user identity doesn’t get a separate field—it goes inside the subject’s properties, alongside the agent’s own identity. The subject describes the actual caller (the agent), and its properties carry the delegation claim that tells the PDP who authorized the agent to act.
{
"subject": {
"type": "agent",
"id": "order-agent-v2",
"properties": {
"tenant": "acme-corp",
"role": "order-processor",
"acting_for": "user:[email protected]",
"user_roles": ["customer-manager"],
"user_tenant": "acme-corp"
}
},
"action": { "name": "delete" },
"resource": { "type": "order", "id": "4521" }
}
The PDP can now evaluate a compound policy: “agent order-agent-v2 is permitted to delete orders and the user it’s acting for (jsmith) holds the customer-manager role and the resource belongs to jsmith’s tenant.” All three conditions are checkable from a single request.
These claims come from your identity layer—typically the result of an OAuth token exchange (RFC 8693) that produces a composite token for “agent X acting on behalf of user Y.” The PEP extracts the relevant claims from that token and places them in the subject properties when constructing the AuthZEN request. The PDP doesn’t need to re-validate the token; the PEP handles token verification and passes only the trusted claims.
That’s the entire protocol surface. There’s no policy language to learn, no configuration format to adopt, and no proprietary SDK to integrate. The spec is a REST contract. Any Policy Enforcement Point (PEP)—an API gateway, a middleware layer, a tool-calling harness—calls it the same way, regardless of what sits behind it.
The PEP/PDP separation
AuthZEN’s central architectural concept is the split between where authorization is enforced and where it is decided.
The Policy Enforcement Point (PEP) is wherever code intercepts a request—an API gateway, a service mesh sidecar, a tool execution layer in an agentic workflow. The PEP doesn’t know the policy. It knows how to call an API and act on the response.
The Policy Decision Point (PDP) is the policy engine that evaluates the request against active rules. It knows the policy. It has no interest in request routing, transport, or application logic.
AuthZEN standardizes the interface between these two. Before AuthZEN, every PDP had its own proprietary API—OPA’s REST endpoint, Cedar’s SDK, SpiceDB’s gRPC interface. A PEP was tightly coupled to a specific policy engine. Swapping engines meant rewriting integration code across every enforcing service.
With AuthZEN, the PEP calls one standard endpoint. The PDP behind it—OPA, Cerbos, Topaz, Cedar, SpiceDB—becomes an implementation detail. You can change authorization backends without touching enforcement code.
This matters for enterprises operating multiple services with different authorization models. The agent’s tool-calling layer doesn’t need to know whether the policy engine is an OPA instance evaluating Rego or a ReBAC system checking relationship graphs. It sends an AuthZEN request and enforces the response.
Why it matters specifically for agents
Traditional web applications have well-understood authorization patterns. A user logs in, gets a session, and their permissions are encoded in that session. The authorization check at each endpoint is usually coarse: does this user have the admin role? Does their JWT contain the orders:write scope?
Agents operate differently. They act autonomously, often across multiple services, on behalf of users who aren’t present to re-authorize each step. They chain through tools that weren’t originally designed to be composed. They make thousands of decisions per session that no human would individually approve.
Static OAuth scopes break under this pressure for a few reasons:
Scope granularity. A scope like orders:write permits an agent to write any order for any customer. But the agent should only be allowed to write orders for customers it’s currently processing—and only when the order’s status is pending. Scopes can’t express this.
Cross-tenant boundaries. Enterprise agents frequently operate across tenant contexts. Whether an agent acting for tenant A can access a resource owned by tenant B is a policy question that depends on relationship data, not scope presence. OAuth has no model for this.
Dynamic context. Whether an action is permitted might depend on the time of day, the length of the delegation chain, a risk score from a fraud detection system, or a threshold the agent has already exceeded. These are runtime signals that can’t be embedded in a token issued at session start.
Tool-level granularity. In MCP-based architectures, an agent can invoke dozens of distinct tools. The subject, action, and resource fields in an AuthZEN request map naturally to tool invocations: the agent as subject, the tool operation as action, the MCP resource as resource. Every tool call becomes a policy-gated operation.
The practical architecture: the PEP wraps the agent’s tool execution layer. Before invoking any tool, it calls the AuthZEN endpoint. The agent either proceeds or receives a denial—and optionally, obligations in the response context that shape what it does next (redact PII, log the access, rate-limit the follow-up call).
What AuthZEN doesn’t provide
AuthZEN is precisely scoped by design. Understanding its boundaries prevents mismatched expectations:
It doesn’t specify policy language. How policies are written, stored, and versioned is outside the spec. That’s OPA/Rego, Cedar, YAML-based Cerbos rules, or SpiceDB relationship tuples—your choice. AuthZEN standardizes the evaluation request, not what evaluates it.
It doesn’t handle identity. AuthZEN assumes the subject has already been authenticated. Token validation, certificate verification, workload identity—those happen before the AuthZEN call. The subject identity in the request comes from your OAuth/OIDC layer or workload identity system (SPIFFE, for container workloads).
It doesn’t distribute policies. Keeping the PDP’s policy set current is a separate concern. OPAL (Open Policy Administration Layer) addresses this for OPA—GitOps-style policy updates pushed to running PDP instances. AuthZEN doesn’t care how the PDP’s policies got there.
It doesn’t define obligation enforcement. The response’s optional context field can carry obligations (“log this access”, “redact these fields”), but AuthZEN doesn’t specify how PEPs must act on them. That contract is between your policy authors and your PEP implementation.
It is not an audit log. Decision results should be logged for compliance, but the logging mechanism, retention policy, and correlation with request context are implementation concerns outside the spec.
Related protocols
AuthZEN sits at a specific layer in the authorization stack. Understanding what surrounds it prevents the common mistake of conflating it with the tools it coordinates with:
OAuth 2.0 / OIDC operate at the identity and coarse authorization layer. They establish who the agent is and issue tokens with broad permissions. AuthZEN operates one layer below, evaluating specific actions in real time. The subject in an AuthZEN request is typically enriched with claims from an OAuth token—they complement each other rather than overlap.
XACML is the OASIS predecessor to AuthZEN. It solved the same PEP/PDP separation problem but with an XML-based request format and a vastly more complex specification surface. Most teams that adopted XACML found the implementation cost prohibitive. AuthZEN covers the same conceptual ground with a REST/JSON API that takes hours to integrate rather than weeks.
Open Policy Agent (OPA) is the most widely deployed PDP for cloud-native systems. It evaluates policies written in Rego and exposes its own REST API. AuthZEN-compatible wrappers for OPA exist so that any PEP using the standard interface can route to an OPA backend without coupling to OPA’s proprietary API. OPAL handles policy synchronization to OPA instances.
Cedar (AWS) is Amazon’s open-source policy language used in Amazon Verified Permissions. It provides formally verified policy evaluation. Like OPA, Cedar implementations can sit behind an AuthZEN interface. The choice between OPA and Cedar is about policy modeling preference and language semantics—not about AuthZEN compatibility.
Zanzibar-inspired systems (SpiceDB, Permify, OpenFGA) implement relationship-based access control (ReBAC). They excel at questions like “does user X have editor access to document Y through their membership in group Z?” They’re particularly useful for hierarchical or graph-structured resource ownership. AuthZEN-compatible adapters exist, meaning the same PEP code can route to a ReBAC engine when resource relationships drive the policy.
AAuth is an emerging protocol for agent authentication—proving who the agent is. AuthZEN handles what the agent is allowed to do after identity is established. In a well-designed agentic stack, AAuth or your existing OAuth/workload identity layer handles authentication; AuthZEN handles the runtime authorization decision.
Enterprise implementation considerations
AuthZEN’s simplicity is operationally significant. The contract is small and stable—a POST with four fields, a response with one. This makes it straightforward to instrument, cache, log, and mock for testing. Policies change; the API surface doesn’t.
Attribute enrichment at the PEP. The subject field in the request should carry more than just an ID. Enrich it at the enforcement point with claims from the agent’s token: tenant, role, task context, delegation chain depth. Richer subject attributes enable richer policies without changing the API contract.
Decision caching. AuthZEN calls are synchronous and need to be fast—latency in the enforcement path adds directly to agent response times. Short-lived caches (seconds to low minutes) on recent decisions reduce PDP load significantly. Cache keys should include all four request fields; decisions are sensitive to attribute changes.
Fail-closed defaults. When the PDP is unavailable, the default decision should be deny. A policy engine that’s down is not authorization to proceed. Build circuit breakers and graceful degradation, but keep the fallback safe.
Centralized policy with distributed enforcement. AuthZEN’s architecture enables a pattern that’s particularly valuable for large agentic deployments: a small number of PDP instances running centralized policy, called by enforcement points embedded across many services. This gives operations teams a single place to update policy—no deployments required, no coordination across service teams. OPAL or equivalent policy sync tooling keeps PDP instances current.
Audit everything. Log every AuthZEN request and decision, correlated with the agent session, task ID, and delegation chain. Denies are especially valuable—they show you where agents are testing authorization boundaries, which can indicate misconfigurations, policy gaps, or probing behavior worth investigating.
The bigger picture
Authorization has been a persistent gap in enterprise AI agent deployments. OAuth tokens are routinely over-scoped because fine-grained authorization was too expensive to implement per-service. Agents get broad access because the tooling to express and enforce precise policies didn’t fit the architecture.
AuthZEN changes the economics. The interface is simple enough to add to any PEP in an afternoon. The PDP layer is swappable, so policy engine decisions don’t constrain enforcement point choices. And the model—subject, action, resource, context, decision—maps naturally onto the way agentic tool calls actually work.
The specification itself is already advancing. A multi-resource evaluation endpoint (/access/v1/evaluations) supports checking a batch of potential actions in a single call—useful for agents that need to plan across several tool invocations before executing any of them.
For enterprises building serious agentic workloads, AuthZEN is the authorization primitive that closes the gap between “this agent has an OAuth token” and “this agent is permitted to take exactly this action in this context.” That gap is where the security incidents happen.