# AuthZEN Authorization API

Source: https://startwithidentity.com/standards/authzen/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## 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](https://openid.net/specs/authorization-api-1_0.html) 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](https://startwithidentity.com/glossary/abac/), 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](https://startwithidentity.com/glossary/rbac/), [ABAC](https://startwithidentity.com/glossary/abac/) or [ReBAC](https://startwithidentity.com/glossary/rebac/) policy in any language. The short definition is in the [AuthZEN glossary entry](https://startwithidentity.com/glossary/authzen/), and the broader category is [fine-grained authorization](https://startwithidentity.com/glossary/fga/).

## Status (November 2026)

The Authorization API 1.0 is an **OpenID Final Specification**, published 11 January 2026. The Foundation [announced approval](https://openid.net/authorization-api-1-0-final-specification-approved/) on 12 January 2026 (81 approve, 1 object, 25 abstain). A Final Specification is not revised further. The editors are Omri Gazitt ([Aserto](https://startwithidentity.com/vendors/authorization/aserto/)), David Brossard (Axiomatics) and [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/) (then [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/)).

Agent-focused work continues as **working-group drafts**, per the [AuthZEN specifications page](https://openid.net/wg/authzen/specifications/) read on 5 November 2026:

- **COAZ Framework 1.0** and the **[COAZ-MCP Binding](https://openid.github.io/authzen/authzen-coaz-mcp-binding-1_0.html)** (Draft 1, published 13 February 2026), which map arbitrary protocols, and MCP specifically, into AuthZEN requests.
- **[AuthZEN Access Request and Approval Profile](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html)** (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](https://openid.net/openid-foundation-advances-authorization-for-the-agent-era-with-new-authzen-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:

```http
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](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) lists AuthZEN 1.0 alongside [Rich Authorization Requests (RFC 9396)](https://startwithidentity.com/glossary/rich-authorization-requests/) as the published options for per-call authorization. The pattern: the MCP server or gateway authenticates the agent with [MCP authorization](https://startwithidentity.com/standards/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](https://openid.net/authorization-interop-results/) that 3Edges, Aserto, Axiomatics, [Cerbos](https://startwithidentity.com/vendors/authorization/cerbos/), [Permit.io](https://startwithidentity.com/vendors/authorization/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](https://startwithidentity.com/standards/mcp-authorization/), [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), the [authorization tools ranking](https://startwithidentity.com/rankings/best-authorization-tools/), [authorization vendors](https://startwithidentity.com/vendors/authorization/), and the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide. Glossary: [least privilege](https://startwithidentity.com/glossary/least-privilege/), [scope](https://startwithidentity.com/glossary/scope/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/).

## Who wrote it

The Authorization API is edited by Omri Gazitt, David Brossard and [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/). More in the [experts directory](https://startwithidentity.com/experts/).