AuthZEN Authorization API

What it is

AuthZEN is the OpenID Foundation's standard for the conversation between the place where access is enforced and the place where it is decided. The Authorization API 1.0 lets a Policy Enforcement Point (PEP), such as an application, API gateway, service mesh sidecar or MCP server, ask a Policy Decision Point (PDP) a structured question and get a decision back, "without requiring knowledge of each other's inner workings", in the specification's words. The PEP and PDP terms come from XACML and NIST SP 800-162, and the problem is old: every authorization product has its own API, so moving from one policy engine to another means rewriting every integration.

AuthZEN fixes the wire format, not the policy model. Behind the API, the PDP can evaluate RBAC, ABAC or ReBAC policy in any language. The short definition is in the AuthZEN glossary entry, and the broader category is fine-grained authorization.

Status (November 2026)

The Authorization API 1.0 is an OpenID Final Specification, published 11 January 2026. The Foundation announced approval on 12 January 2026 (81 approve, 1 object, 25 abstain). A Final Specification is not revised further. The editors are Omri Gazitt (Aserto), David Brossard (Axiomatics) and Atul Tulshibagwale (then SGNL).

Agent-focused work continues as working-group drafts, per the AuthZEN specifications page read on 5 November 2026:

• COAZ Framework 1.0 and the COAZ-MCP Binding (Draft 1, published 13 February 2026), which map arbitrary protocols, and MCP specifically, into AuthZEN requests.
• AuthZEN Access Request and Approval Profile (Draft 1; the editor's copy is dated 5 November 2026), for what happens after a "requestable" denial: submit an access request, track it, and re-evaluate after approval.

The Foundation announced both as working-group drafts on 15 June 2026. Neither is final.

How it works

The information model has five entities: Subject (user or machine principal, with type and id), Action (with name), Resource (with type and id), Context (environment, time, risk) and Decision. Each can carry properties.

A concrete check, an MCP gateway asking whether an agent may refund an order for a user:

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Authorization: Bearer <PEP credential>
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject":  { "type": "agent", "id": "support-agent-7",
                "properties": { "on_behalf_of": "ada@example.com" } },
  "action":   { "name": "refund.issue" },
  "resource": { "type": "order", "id": "A-1009",
                "properties": { "amount": 480 } },
  "context":  { "time": "2026-11-05T14:02:00Z" }
}

The PDP answers {"decision": true} or {"decision": false, "context": {...}}. The context can carry reasons for admins and users, or a hint such as a step-up requirement, and the PEP must deny when the decision is false.

Around that core:

• Access Evaluations sends many checks in one call (an evaluations array), with three semantics: execute all, deny on first denial, or permit on first permit. This is how a UI or agent planner checks twenty tools at once.
• Search APIs for subject, resource and action answer "which documents can this user read" or "what can this agent do on this record", with pagination.
• Discovery at /.well-known/authzen-configuration lists access_evaluation_endpoint and any optional endpoints, and the PDP's policy_decision_point identifier, which must match to prevent mix-up attacks.
• Transport is an HTTPS JSON binding. Authentication of the PEP to the PDP is out of scope, with OAuth 2.0 recommended.

What it solves for AI agents and SaaS

For SaaS, AuthZEN separates authorization from application code. A product can ship one PEP integration and let enterprise customers bring their own PDP, or swap from a homegrown engine to a commercial one, without touching every endpoint.

For AI agents, the problem is granularity. OAuth scopes are coarse and fixed at consent time; an agent's risk is per call ("refund 480, not 48,000"). SWI's Agent Identity Standards Map 2026 lists AuthZEN 1.0 alongside Rich Authorization Requests (RFC 9396) as the published options for per-call authorization. The pattern: the MCP server or gateway authenticates the agent with MCP authorization, then asks a PDP about each tool call using subject, action, resource and the actual arguments. COAZ-MCP standardizes that mapping, and the access request profile adds the "ask a human" step for actions that need approval, a gap the standards map scores as only drafted.

Adoption signals (verified)

• Interop, May 2024. The OpenID Foundation reported that 3Edges, Aserto, Axiomatics, Cerbos, Permit.io, Rock Solid Knowledge, SGNL, Strata Identity and Thales achieved conformance with the AuthZEN request and response protocol. That was before 1.0 Final.
• Authorship. COAZ-MCP is written by Atul Tulshibagwale (CrowdStrike) and Alex Olivier (Cerbos), per the draft.
• Certification. The working group page says a conformance certification program for the Authorization API is in development. We did not find a published list of certified PDPs on 5 November 2026.

The standards map found no verified production agent deployment of AuthZEN as of 30 October 2026, and we found none since.

How to implement or evaluate

1. Find your PEPs. API gateways, MCP servers and service middleware are the natural places. Put one AuthZEN client library in each.
2. Model actions as verbs on resources (refund.issue on order), not as API paths. That keeps policy readable and portable.
3. Pass real arguments in properties for agent tool calls, so policy can bound amounts, recipients and record counts.
4. Use batch evaluation for planning and single evaluation at execution time, so an agent's plan does not outlive the policy that approved it.
5. Ask PDP vendors which AuthZEN version they implement (pre-Final interop or 1.0 Final), whether they support the evaluations and search endpoints and the metadata document, and their p99 decision latency.
6. Fail closed. If the PDP is unreachable, deny. Cache only with short lifetimes.

Pitfalls

• Treating the API as the policy. AuthZEN moves decisions out of code; you still need good policy, review and testing.
• Trusting the subject the agent claims. The PEP must fill subject from authenticated tokens, not from model output.
• Latency per tool call. Measure it. A slow PDP pushes teams to cache decisions for too long.

Related

MCP authorization, Shared Signals Framework, ID-JAG and Cross App Access, RBAC vs ABAC vs ReBAC, the authorization tools ranking, authorization vendors, and the securing AI agent identities guide. Glossary: least privilege, scope, delegation chain.

Who wrote it

The Authorization API is edited by Omri Gazitt, David Brossard and Atul Tulshibagwale. More in the experts directory.