We standardized authentication years ago. We never did the same for authorization, and it shows. Here is why I think that has to change, and what I'd like you to do about it.
We fixed login. We never fixed access.
Twenty years ago every application had its own login page and its own user table. SAML, then OAuth and OpenID Connect, put an end to that. Today nobody builds their own login. You plug in an identity provider and move on.
Authorization never got that treatment. Open any codebase and you'll find access logic scattered across
if statements, SQL WHERE clauses, API gateway configuration and a roles table
that someone created a decade ago. Every app does it differently. Ask who can see what across the
application estate and the honest answer is usually "it depends which app you're asking about". Ask for an
audit trail and you get a spreadsheet.
That isn't a tooling problem. It's an architecture problem.
Roles were never going to be enough
Role-based access control (RBAC) works until it doesn't. Try expressing "a manager can approve expense reports for their own team, up to their approval limit, unless the expense was filed from a sanctioned country" with roles alone. You end up with role explosion: thousands of roles nobody can explain, and access reviews nobody can finish.
NIST worked this out over a decade ago. NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, published in 2014, defined attribute-based access control: decisions based on attributes of the subject, the action, the resource and the environment, evaluated against policy. It also formalized the architecture we still use: a policy enforcement point (PEP) intercepts the request and a policy decision point (PDP) makes the call. XACML had the same model. ALFA made the policies readable by humans.
So the theory has been settled for a while. What was missing was a standard way for the PEP to talk to the PDP. That is what OpenID AuthZEN fixes.
Externalize, then standardize
My position hasn't changed in years. It comes down to three things.
- Take authorization out of the code. Policies belong outside the application, where security, compliance and business owners can read them, change them and audit them without a release cycle.
- Make it fine-grained and dynamic. Decide at runtime, with the context available at that moment, not at login time with whatever was stuffed into a token.
- Standardize the interface. With AuthZEN, an application, API gateway or identity provider asks one question: can this subject perform this action on this resource in this context? Any compliant PDP answers. You can swap engines without rewriting apps. No lock-in, and yes, that includes lock-in to us.
Defense in depth, one policy
Security teams rightly insist on defense in depth: any single control eventually fails, so you layer them. For authorization, that means checking at more than one place:
- At the edge. The API gateway rejects calls that are obviously out of bounds.
- In the application or API. Is Alice allowed to approve this payment?
- At the data layer. Only return the records and documents the caller is entitled to, which is what the AuthZEN Search API is for.
The problem has always been that each layer had its own rules, in its own format, maintained by a different team. They drift. The gateway says yes, the app says no and the database never asks. With AuthZEN every layer is a PEP calling the same PDP with the same policies. You get layered enforcement with a single source of truth, and one audit log that shows every decision made at every layer.
Agentic AI makes this urgent
Everything above was true before anyone had heard of an LLM. Agents just remove the last excuses.
An AI agent is a new kind of subject. It acts on behalf of a user, chains tool calls together, decides at runtime which APIs to call and does all of it at machine speed. You cannot hard-code permissions for a path you can't predict. And you certainly shouldn't let the model decide what it is allowed to do. A prompt injection can talk an LLM into almost anything. It cannot talk a PDP out of a deny.
The good news is that the PEP/PDP model maps onto agentic architectures almost one to one:
- The agent and the user it acts for are the subject. Both matter: an agent should never be able to do more than the person who delegated to it.
- Each tool call or MCP request is an action on a resource.
- The MCP server, or the gateway in front of it, is the PEP.
- The PDP makes a deterministic, auditable decision outside the model.
- Retrieval pipelines use Search to fetch only what the user is entitled to see, before anything reaches the prompt.
The AuthZEN working group is already on it: the COAZ-MCP binding, currently a working group draft, maps MCP requests to the Authorization API.
What I'm asking you to do
- Stop writing authorization logic in application code. Every new
if (user.role == "admin")is technical debt with a security hole attached. - Read NIST SP 800-162. It will change how you think about access control.
- Ask your vendors. When you buy or build an API gateway, an IdP, an agent platform or an MCP server, ask whether it speaks AuthZEN. If it doesn't, ask when it will.
- Put a PDP behind it. Ours, someone else's or an open-source one. Thanks to AuthZEN, it's a decision you can revisit later. See the implementations.
- Come and help. The OpenID AuthZEN Working Group is open to anyone who signs the contribution agreement. We need more implementers and more real-world use cases.
David Brossard
CTO, Axiomatics · Co-chair, OpenID AuthZEN Working Group