OAuth issues a token. AuthZEN asks whether the action is allowed.
Why autonomous AI agents need an authorization standard, not just new OAuth scopes. Field notes from an IAM architect who runs autonomous agents inside Ariovis' own operations and helps clients govern identities, secrets, APIs and runtime decisions.
The CRM export agent and a mission that only looks simple
At Ariovis we run Autonomous AI Agents for a handful of internal operations. One of them relaunches the daily CRM export into our reporting tool. An authorised user can send it an instruction from a conversational interface such as Telegram or WhatsApp: "Relaunch the daily CRM export to the reporting tool."
The agent then has to understand the request, pick the right tool, query the CRM, select the required fields, produce the file, check its format, deliver it to the approved destination and report on the run. Secrets never flow through the messaging channel or the prompt: they live in a Secret Vault. Where the application allows it, the execution component obtains an OAuth 2.0 Access Token limited to the narrowest scopes on offer.
The security problem is not solved by that setup alone. The CRM API demands an administrator role or scope to use its export function. It does not expose any right that maps precisely to the actual mission: read a specific subset of fields from active opportunities and hand them to the approved reporting destination, once a day. The token the agent holds is technically far broader than what it should do.
That gap between the smallest available scope and the intended action is exactly why we pay attention to AuthZEN — not as a revolution, but as a missing piece between access delegation and the authorization decision itself.
OAuth and AuthZEN answer different questions
OAuth 2.0 lets a client or an agent obtain an Access Token that grants entry to an API, within the OAuth Scopes that API happens to expose. It answers a specific question: can this client present a valid token to call this API? That is a question about delegation and about presenting a capability. It is essential, and its answer is a technical fact.
AuthZEN, developed inside the OpenID Foundation, does not try to replace that question. It provides a standard interface so a Policy Enforcement Point can ask a Policy Decision Point whether a specific Action, on a specific Resource, in a specific Context, should be authorised. The question is finer: can this agent export these fields from these opportunities to this destination, in this run?
An autonomous agent architecture needs both. OAuth secures delegation and API access. AuthZEN evaluates the action actually being attempted. One does not replace the other, and framing them as rivals helps neither architects, editors nor clients who have to design the full chain.
What each component does, and where its contribution stops
Before talking about the standard, it is worth being honest about what each existing component brings to the CRM export agent today, and the precise point where its contribution ends.
- 01
Netwrix Identity Manager governs the agent's existence
Identity Governance can describe the agent as a distinct Non-Human Identity: its name, purpose, business owner, technical owner, creation date, lifetime, source and target applications, eligible roles, review process, suspension rules and audit evidence. Netwrix Identity Manager can establish that the export agent is legitimate and must access the CRM API. If the CRM insists on an administrator role, Identity Governance can govern that assignment cleanly — it cannot invent, inside the CRM, a permission the CRM does not know how to represent. Governance can legitimise the administrator right; it cannot make that right finer than the application's own authorization model.
- 02
The Secret Vault protects the means of obtaining power
Keeper or another vault protects the client secret, the refresh token, the API key, the certificate, and — as a last resort — the technical password. Secrets stay out of the prompt and out of the messaging channel. A trusted component fetches them at execution time; they can be rotated, revoked and audited. The vault does its job well. It protects the means of obtaining power; it does not define everything that can be done once the token is in hand. A perfectly protected secret can still unlock an authorization that is far too broad.
- 03
OAuth issues a bounded token, but bounded by the API's own catalogue
OAuth spares us from handing the agent a password. The token can be short-lived, revocable, tied to a specific client, targeted at a specific API and scoped to a subset of capabilities. That protection is essential. It remains bounded by the granularity the application chose to expose. A CRM might offer crm.read, crm.write and crm.admin — but not opportunities.read.selected-fields, export.once-per-day, export.to-approved-reporting-tool, deny-attachments or deny-user-administration. If the export requires crm.admin, the architecture uses the smallest scope available — which still sits far above the actual mission. The smallest available scope is not always the minimum power required.
- 04
The technical boundary is wider than the functional one
Once its token is presented, the agent holds a capability the API technically allows it to use well beyond the export. It could call an administration endpoint, a delete function, a user-management API, a broader export, a function that reaches attachments, a configuration change. This is not a portrait of a malicious agent. An Autonomous AI Agent tries to reach the goal it was given; when one endpoint fails, it reads whatever documentation it can access, tries another method, picks a more efficient path. That is precisely what makes the agent useful — and precisely why the security boundary cannot rest only on its prompt. We cannot only secure the path we expected the agent to take; we have to constrain every path its tools let it explore.
- 05
AuthZEN standardises the conversation, not the policy
AuthZEN is not a new universal policy language, not a new PBAC engine, not an OAuth replacement, not a single authorization product. Its contribution is to standardise the exchange between the component that has to enforce a decision — the Policy Enforcement Point — and the component that computes it — the Policy Decision Point. The Authorization API 1.0 lets a caller express an Access Evaluation request out of four simple pieces: Subject, Action, Resource, Context. The engine returns a decision the enforcement point can apply. The value lies less in message complexity than in the fact that this message can become common ground for applications, API Gateways, agents, policy engines and vendors.
- 06
Ask the question at the right level, by design
When an application only exposes coarse roles, the organisation has to build its controls around the product's limits — hand out an administrator role and try to monitor its use afterwards. An application with native AuthZEN support could take a different stance: while designing a sensitive action, the application team describes directly which subject acts, which action they request, on which resource, in which context, and forwards that question to an external engine through a standard interface. The level of control is no longer capped by the application's role catalogue. AuthZEN does not guarantee that the policy will be right. It stops the application from being condemned to only ever ask coarse questions.
- 07
PBAC states the rule, AuthZEN standardises the conversation
AuthZEN alone is not the engine that decides. Axiomatics can play the PDP role and evaluate PBAC policies, combining the agent's identity, its owner, its declared purpose, the action, the resource, the destination, the timing, the volume, the human requester and the data classification. The enforcement point can then allow the call, deny it, cap its parameters, filter fields, force a destination, ask for a second approval or emit an audit trace. PBAC states the rule. AuthZEN standardises the conversation needed to ask for a decision. In the same way, OAuth carries a delegated capability; AuthZEN lets us check whether that capability can actually be exercised here and now.
None of these components is redundant, and none is enough on its own. It is how they are wired together that makes — or breaks — the security of an autonomous agent.
Applying AuthZEN to the CRM agent case
To keep the discussion concrete, here is how the authorization request could be shaped for the CRM export. The CRM might still see a token carrying the crm.admin scope, but the agent would not be free to use everything that scope technically permits — because the Policy Enforcement Point would ask the PDP before every real call.
- Subject — the identity that acts
- The subject is agent-crm-daily-export, a Non-Human Identity governed by Netwrix Identity Manager. Additional properties travel with the request: business owner, technical owner, declared purpose, environment, criticality and the human requester who triggered the run. The engine does not just see a technical identifier; it sees a qualified identity with its governance context.
- Action — the operation being requested
- The action is export_opportunities. It is not the technical POST verb, nor the generic crm.admin scope. It describes the business intent of the operation. Only at this level of description can a policy reason about the export itself, independently of how the CRM chose to model its endpoints.
- Resource — the object concerned
- The resource is crm/opportunities/active-pipeline, carrying useful metadata: data type, classification, commercial scope, requested fields. Here again, the engine does not reason about a generic URL but about a business object described precisely enough for a policy to constrain it.
- Context — the conditions of execution
- The context covers the daily run, the approved destination, the expected time window, the maximum volume, the identity of the authorised requester, the production environment, the task identifier and the reporting purpose. This context lets a policy tell a legitimate export apart from a well-intentioned attempt to reuse the same technical capability for something else.
- Policy Decision Point — the decision itself
- Axiomatics, or another AuthZEN-compatible PDP, evaluates the policy. It can allow the call, deny it, cap parameters, filter fields or force a destination. For the AuthZEN profiles still being finalised, it can also signal that an approval or an additional proof is required — without turning the engine into a workflow tool, and without letting the agent route around the refusal.
- Policy Enforcement Point — actually applying the answer
- The PEP is the component that applies the decision. In the CRM agent architecture, it lives in the Tool Broker that exposes tools to the model, or in the API Gateway placed in front of the CRM, or in both at different layers. The agent never holds the administrator token directly; it goes through a component that, for each action, builds an AuthZEN request and only executes what the PDP allowed.
- What the standard changes in this chain
- AuthZEN does not add a new box; it standardises the contract between PEP and PDP. The application still has to identify the resource, action and context. The policy still has to be written. The decision still has to be enforced. What changes is that these exchanges can become interoperable across engines and enforcement points, rather than relying on one proprietary API per vendor.
The questions we ask vendors after the demo
When a vendor claims to secure AI agents with PBAC, we do not stop at the policy authoring UI. We ask whether the agent has a distinct identity, how it obtains its OAuth token, which scopes are truly on offer, which business action reaches the engine, how the resource is described, where its attributes come from, which context travels with the request, where the Policy Enforcement Point sits, and whether the agent can bypass it.
We then ask whether the product can emit or receive an AuthZEN request, whether the format is standard or proprietary, whether the decision is made once or for every call, whether evaluations can be batched, what latency to expect, which caching strategy is in place, what happens when the PDP is unreachable, and how the decision is audited. The word PBAC describes a functional intent. AuthZEN compatibility is what starts to make that intent verifiable across components.
AuthZEN does not remove the constraints of Runtime Authorization. The CRM agent may chain several calls — locate opportunities, fetch data, check fields, generate the export, deliver the result. If every call triggers a remote decision, the architecture has to know how many decisions are made, how often, how fast, how far the PDP sits, whether evaluations can be batched, which cache policy applies, how long a decision stays valid, what the degraded mode looks like and how revocations propagate. The Authorization API makes integration and testing easier; it does not remove the need to choose between a remote PDP, a local engine, a sidecar, a cached decision or a mix. A standard makes the exchange predictable; it does not make the network faster.
The concrete test we put in front of vendors is plain. The CRM agent technically holds an administrator scope. It must export six fields from active opportunities to the reporting tool, once a day. Show us the agent's identity, the token it obtained, the scopes it carries, the authorization request with subject, action, resource and context, the policy applied, the decision returned, the component that enforces it, the refusal of an administration endpoint, the refusal of an unauthorised field, the refusal of an unknown destination, the response time, the behaviour when the PDP is unavailable, and the trace linking the human requester, the agent, the token, the policy and the executed call. Then we ask: can you run that demo with a standard AuthZEN request rather than with a proprietary API? The answer separates real interoperability from a feature that only exists inside the vendor's closed ecosystem.
A standard carried by an ecosystem, tested in the field
The AuthZEN working group is hosted by the OpenID Foundation. Its founding contributors come, among others, from Axiomatics, Microsoft, Ping Identity, SailPoint, SGNL, Strata Identity, ForgeRock, Aserto and 3Edges. Interoperability testing has since brought together many engines and approaches, including Axiomatics, Aserto, Cerbos, SGNL, Open Policy Agent, Thales AuthZForce, PlainID, Permit.io and Rock Solid Knowledge. The message is not that every vendor already supports AuthZEN in every product. The message is that AuthZEN is not the proprietary format of a single vendor trying to push its own engine — it is a deliberate effort to let components designed by different players speak to each other.
David Brossard, CTO of Axiomatics, is one of AuthZEN's initiators, one of its co-chairs and one of the editors of the Authorization API. His track record in authorization standards — XACML, ALFA and more — explains the continuity of that work. In our own words, the conviction we share is this: authorization will not progress just because every vendor adds the word PBAC to its brochure. It will progress once applications know how to ask for a decision in a standard way and engines can respond without demanding a fully proprietary integration each time.
The partnership between Ariovis and Axiomatics is not just an integrator-vendor relationship. Matthieu Filizzola, Ariovis' founder, and David Brossard speak together at identity and authorization conferences, notably the Identity Days in France. Those sessions are not two brochures placed side by side: they bring the standardisation work face to face with real product capabilities, real information-system constraints, real expectations from CISOs and architects, real limits of application entitlement models and real needs raised by autonomous agents. Between conferences, the conversation continues around specific use cases. Those exchanges feed directly into the way Ariovis reviews the architectures proposed to its clients. AuthZEN is built inside an international working group, but its value shows up in very concrete conversations between the people writing the standard, the people building the products and the people integrating them into real information systems. Ariovis is a partner of Axiomatics; we do not chair or co-author AuthZEN — Axiomatics is one of the driving contributors inside the group, and we rely on that dialogue to serve our clients better.
Our position is not that AuthZEN should land in every application right now. A short script talking to a well-designed API through a read-only scope may not need it. AuthZEN becomes particularly relevant when the application exposes roles that are too broad, when the agent picks its own sequences of actions, when several engines or enforcement points must cooperate, when the client wants to avoid over-dependence on a proprietary API, when authorization has to be applied across several applications or APIs, when policies must be administered and audited consistently, or when the organisation wants to design its applications with the right level of authorization from day one. We do not recommend AuthZEN because it is a new standard. We recommend it when the absence of a standard forces the client to choose between an overly broad role and a proprietary integration that will be painful to maintain.
Back to the CRM export agent. Netwrix Identity Manager establishes that the agent legitimately exists and can receive the necessary access. Keeper protects the secret used to obtain the token. OAuth issues a short-lived token with the tightest scope the CRM knows how to offer. That scope is still technically too broad. Before every action, the proxy therefore builds an authorization request — subject: the export agent; action: export opportunities; resource: the intended data; context: the daily run to the approved destination. That request can follow the AuthZEN standard. Axiomatics then evaluates the policy. The enforcement point runs only the call that was allowed. The agent never receives the broad capability that its administrator role would technically permit. OAuth lets us hand a capability to the agent cleanly. AuthZEN lets us ask, in a standard way, whether that capability can be exercised for this precise action. That is where authorization stops being a marketing promise and becomes an architectural control.