Wiki · Concept · Last reviewed June 25, 2026

AuthZEN Authorization API

The AuthZEN Authorization API is an OpenID Foundation standard for asking authorization questions across systems. For AI agents, it names the interface between the place where an action is intercepted and the policy service that decides whether the action should proceed.

Category: Concept Updated: June 25, 2026 Tags: AuthZEN, authorization, PDP, PEP, access control, AI agents

Definition

Authorization API 1.0 is an OpenID Foundation Final specification from the OpenID AuthZEN Working Group, published on January 11, 2026. It defines an API by which a Policy Enforcement Point, or PEP, asks a Policy Decision Point, or PDP, for authorization decisions without needing to know the PDP's internal policy language or architecture.

The standard is commonly associated with AuthZEN, the OpenID working group focused on authorization interoperability. It is not an identity protocol, OAuth grant type, policy language, or access-control model. It is a communication interface for authorization decisions and related search operations.

The PDP/PEP terms predate AuthZEN. XACML and NIST's attribute-based access-control guidance both describe architectures where enforcement and decision making can be separated. AuthZEN gives that older pattern a modern JSON API surface for applications and services that need a common authorization exchange.

How It Works

The core request model has four pieces: subject, resource, action, and context. The subject is the user or machine principal. The resource is the thing being accessed. The action is what the subject wants to do. The context carries situational attributes such as time, device, tenant, risk signal, session state, or other facts the policy may need.

The Access Evaluation API returns a specific access decision. The Access Evaluations API supports multiple decisions in one request. Search APIs can discover which subjects, resources, or actions are permissible. The specification also defines Policy Decision Point metadata, a well-known URI for obtaining metadata, and a normative HTTPS JSON binding.

Authorization API 1.0 is versioned. The specification says future revisions may augment the API but must not change the API described for version 1.0. Endpoints for this version should include v1 in their path, such as an /access/v1/ endpoint.

Agent Context

Agent systems generate authorization questions faster than human interfaces do. A tool gateway may need to ask whether a coding agent can write a file, whether a research agent can retrieve restricted documents, whether a finance connector can initiate payment preparation, or whether a service agent can act on behalf of a user in a tenant.

AuthZEN is useful because it keeps the enforcement point close to the action while allowing policy to live elsewhere. That fits agent architectures where prompts, tools, credentials, sandboxes, browsers, APIs, and enterprise policies are separate systems. A PEP can block an action at the tool boundary while a PDP evaluates richer policy.

This belongs beside Cedar Authorization Policy Language, Capability-Based Security, Confused Deputy Problem, and AI Agent Identity. Cedar is a policy language and engine. Capability security is an authority model. AuthZEN is a standard exchange between enforcement and decision components.

Governance Risks

The first risk is false centralization. Moving decisions into a PDP can make policy more reviewable, but only if the PDP is governed, tested, and logged. A badly scoped central policy can deny too much, allow too much, or make every service dependent on one fragile authority.

The second risk is context laundering. If a PEP sends incomplete or misleading attributes, the PDP can return a clean-looking decision based on a dirty picture of the request. Agent systems should record what context was supplied, which context was omitted, and how stale or sensitive those attributes were.

The third risk is confusing authorization with consent or safety. A PDP decision can say whether policy permits a requested action. It does not prove that a user understood the action, that a model chose wisely, that downstream effects are harmless, or that the organization should have built the workflow.

Governance Pattern

Source Discipline

Use the OpenID Foundation Authorization API 1.0 specification for the current API, endpoints, information model, versioning, metadata, transport, and security considerations. Use the OpenID final-specification notice for status. Use NIST SP 800-162 and OASIS XACML only for the older access-control vocabulary that the AuthZEN specification references.

Do not say that AuthZEN makes an agent safe, compliant, or authorized in general. It standardizes the authorization question sent from a PEP to a PDP. The quality of the result still depends on policy design, attributes, authentication, logging, review, appeal, and incident response.

Spiralist Reading

Spiralism reads AuthZEN as a grammar for refusal.

The agent asks to act. The tool boundary asks a smaller question: who, doing what, to which resource, under what context? A serious institution does not let that answer disappear into a log swamp. It preserves the question, the decision, and the policy that made the decision possible.

Open Questions

Sources

Return to Wiki