The Two Questions Behind Every Agent Authorization Standard
This post is Part 1 of a two-part series that explores how identity arrives and where the decision is made for agentic workflows. In this article, we'll walkthrough why these are two independent questions, and how sorting out which authorization standard answers which question makes the choice in front of you much simpler.
Enterprises turned on AI agents this year and gave them OAuth access tokens. The access token proves who the employee is. It does not constrain what the agent does with it.
An agent holding a valid employee access token can generally call every tool on every MCP server it can reach. Ask afterward what it did, on whose behalf, and whether it should have been allowed, and in most deployments there is no answer.
Meanwhile four names have arrived in the space of a year: enterprise-managed authorization, ID-JAG, Cross App Access, AuthZEN, each with vendors explaining why theirs is the one that matters. They sort out more easily than the noise around them suggests.
These standards are not competing. They answer two different questions, and most of the confusion comes from treating them as one sequence.
The first question is how identity arrives. The second is where the decision is made. They move independently. You can be sophisticated on one and primitive on the other, and plenty of organizations are.
If you'd prefer to dive right into a real world example of this architectural distinction, see Part 2: Six Ways Traefik Hub Enforces One Agentic Refund.
The First Question: How Identity Arrives
Today most organizations put entitlements in a token. Your identity provider issues a JWT, you add some custom claims describing what this person may do, and something downstream reads them. It is unglamorous, and it works.
Enterprise-managed authorization replaces the bespoke part with a standard one. Rather than each user completing an OAuth consent for each connector, the agent presents a signed assertion from your identity provider and receives an access token in a single back-channel exchange. Underneath it is ID-JAG, an identity assertion exchanged for a grant the target application will accept.
The usual diagram draws ID-JAG as step two on a path toward finer control. That is where it falls apart.
Moving to ID-JAG does not give you finer control. It may give you less.
A hand-built JWT carries any claim shape you invent. ID-JAG carries structured authorization details, but the specification defines no vocabulary for them, no types for tools, no semantics for limits, and the application on the other end decides what it honors. If you are at custom claims today and someone sells you ID-JAG as a granularity upgrade, that is not what arrives.
What does arrive is worth having. Your agents reach third-party SaaS servers that would never accept a token you invented. You stop minting long-lived credentials and handing out API keys. Revocation runs through ordinary deprovisioning rather than a spreadsheet. Real problems, solved. None of them is the authorization problem.
The Second Question: Where the Decision is Made
Whatever form the credential takes, something has to decide whether a particular call should proceed. There are three answers, and these do sit on a progression.
You can decide in the token, which is what claims-based entitlements are. You can decide locally at the point of enforcement, evaluating the claims against the actual request. Or you can ask a policy engine at the moment of the call.
By policy engine, I mean a separate system holding the rules and the relationship data: Cerbos, Axiomatics, PlainID, OpenFGA. The gateway evaluates policy too, so the useful split is enforcement against decision. The gateway sits in the path and enforces whatever answer comes back; the policy engine owns the answer and never touches traffic. AuthZEN is the API between them rather than the thing deciding, which is what lets you swap one policy engine for another without touching the gateway.
An identity provider knows who you are, how you authenticated, and which groups you belong to. Take the example this post and the next one keep returning to: a support agent issuing a refund against an invoice. What the identity provider cannot know, at the moment it issues a credential, is that this refund is the second one against the same order, that the customer was flagged for fraud eleven minutes ago, or that the department has already spent ninety four percent of its quarter. A token can name a specific invoice and carry a condition on it. It cannot, however, refresh when the facts move.
Three further things a credential cannot do. It cannot grow to hold high-cardinality entitlements, because tokens ship on every request and headers have limits. It cannot go stale gracefully, because the entitlements inside it freeze at issuance and the assertion has no revocation story. And it cannot carry a conditional answer.
The third is the one I keep coming back to. For agent traffic the right answer is frequently neither yes nor no. It is yes with the compensation field removed, or yes once the account owner approves. A decision expresses that. A claim cannot, because a claim is not a decision.
The Map, and Where You Actually Are
[Diagram: a two by three grid. Columns are how identity arrives, custom JWT claims and ID-JAG grant. PLACEHOLDER]
Set the acronyms aside and describe the objectives instead. Four of them come up repeatedly.
I need to stop internal agents having unlimited reach, and I need it this quarter. You do not need a new standard for this. You need something in the path that reads the claims you already issue and evaluates them against the actual call. Start here regardless of what else you plan. The rest of the map is easier to navigate once something is enforcing.
I need agents to reach third-party SaaS without handing out API keys. This is the ID-JAG and enterprise-managed authorization case, and it is the right tool for it. Expect it to solve credential sprawl and onboarding friction completely, and to leave the question of what the agent may do once connected exactly where it was.
I need decisions that reflect what is true now, not what was true at login. This is AuthZEN, independent of the credential question. You can adopt it with the tokens you issue today and never touch ID-JAG. One caution: the shift here is not about who writes the policy, which in most organizations stays with the same team. It is about whether business facts get copied into a credential or resolved from the system that owns them at the moment of the decision.
I already have an identity provider and a policy engine, and I need them to meet. Then you are not choosing between these standards at all. You need something in the path that speaks to both, so the grant establishes who is acting and the policy engine answers whether this specific call proceeds.
What Each Position Actually Produces
Take the refund from earlier, with credentials that are valid in every case. The approver's ceiling is five hundred. The payment has one hundred left to refund.
| The Request | Decided in the Token (Scope checked, nothing else) | Decided at the Enforcement Point (Claims vs. the real arguments) | Decided by a Policy Engine (Asked per call) |
|---|---|---|---|
| Seventy five, within the ceiling | Admitted | Admitted | Allowed, then admitted |
| Nine hundred, over the ceiling | Admitted. No amount check is configured | Denied | Denied |
| Assignment revoked after the token was issued | Still admitted. The token is still valid | Still admitted. The claims have not changed | Denied, once the change is visible to the evaluation |
| Two separate refunds of seventy five against one hundred remaining | Both admitted | Both admitted | Both allowed |
Two things in that table matter more than the rest. Admitted never means the money moved, which a later section deals with. And the columns of the map, how identity arrives, change none of these outcomes. A federated credential and a hand-built one produce identical rows, which is about as plainly as the two questions can separate themselves.
What I Would Not Do, and What I Have Left Out
I would not tell you to reach the bottom right corner for every call, and I would be a little suspicious of anyone who does.
For static, low-cardinality entitlements, an approval ceiling or a department scope or a tool allowlist, evaluating claims locally is the correct permanent answer. Adding a policy engine round trip to those calls buys nothing. Local does not mean hardcoded, either. In Hub's task-based access control (TBAC) the ceiling is a variable filled from the claim your identity provider issued, not a number typed into the gateway. A $500 ceiling and a $5000 ceiling run through one policy, and the number changes in the identity provider without a gateway change. One limit to know before you federate: a third-party authorization server will publish a scope, but it will not carry your spending ceiling, so a rule that reads the claim survives only while you control the issuer. What works is local evaluation for the ordinary majority and a decision call for the consequential minority. Any vendor whose story requires routing everything through their preferred component is describing their business model, not your architecture.
Two limits no amount of protocol solves. Obligations and human approval are the parts of AuthZEN I find most interesting, and both remain early working group drafts rather than something to build a compliance program on this year. And a gateway can refuse a call it cannot narrow: where the downstream API offers read everything or nothing, that ceiling holds and standards do not lift it.
A third question sits behind these two, and I have left it out. How does a decision get revisited after it has been made? A grant is valid when issued, a decision correct when taken, and then the employee leaves, the risk score moves, or the session turns out to be compromised. Continuous evaluation and the shared signals work address that, and the transaction token drafts handle a related version of it inside a single request. Neither fits the map above. Both are real, and they need their own piece.
Authorization is Not the Last Line
A decision at the gateway grants permission to attempt an operation. It does not promise the operation completes safely.
Take the refund from the table above. The approver's ceiling is five hundred, and the payment has one hundred of refundable balance left. Two requests for seventy five each pass the per-request check, correctly, because each one is genuinely under the ceiling. Together they exceed what is left to refund. Stopping the second means reserving or consuming that balance atomically, and an allow response does not reserve anything. That responsibility belongs to whatever owns the balance, which might be the application, the payment processor, or a dedicated budget service.
So the work divides. Each layer establishes something real and leaves something for the next.
| Layer | Establishes | Does not Establish Alone |
|---|---|---|
| Validated access token (often a JWT) | The issuer, the intended audience, the validity window, who the subject is, and which scopes were granted. | Anything about current state. JWT is a format rather than a security layer; the protection comes from the token profile, the issuance rules, and correct validation. |
| ID-JAG exchange (cross-domain delegation) | A trusted delegation the resource authorization server evaluates under its own policy before issuing an access token of its own. | Permission for every business operation that follows. The resource server keeps its own policy authority, and the grant is not an instruction to approve what comes next. |
| Gateway and policy engine (the decision) | Whether policy permits this request, given the identity, the tool, the arguments, the target, and whatever context the decision service can see. | Transactional safety, or anything resting on facts that were not among the decision inputs. |
| Application and transaction system (the commit) | Actual resource ownership, valid business state, cumulative limits, idempotency, and safe execution when two requests arrive at once. | That the operation was a sound business decision. Only that it was a permitted and consistent one. |
A fresh decision is only as current as its inputs, and it does not reserve the state it checked. That is not a flaw in the decision. It is what a decision is.
Backend enforcement does not mean copying your policy into application code. The application can be an enforcement point too, calling the same policy service with facts only it holds. What it cannot delegate is the commit.
If a vendor tells you their layer removes the need for the others, that is a sales position rather than an architecture.
The Part That Does Not Change
One constraint holds on every path, and it is why we have spent most of the last year on this.
The decision has to be made somewhere in the path. You cannot rely on the MCP servers for it, because you run dozens or hundreds of them and most are third party and hosted elsewhere, and you will not get every vendor to adopt your enterprise's policy. Servers can and should enforce their own authorization; what they cannot give you is one uniform control. It cannot live in the client, and the specification work says so directly, since the client is not trusted by the server to check itself. It cannot live in the identity provider, which sees the connection and never sees the call.
The only thing left is the enforcement point. And an enforcement point only helps you if it stays neutral about both questions.
That is the position we have taken with Traefik Hub. It reads the claims you issue today, accepts ID-JAG where you have adopted it, and asks whichever policy engine you already run, through AuthZEN, when the decision belongs there. Changing how the credential arrives does not require changing how you make runtime decisions. Moving the decision into a policy engine does move the rule, which is what that axis is for. Which is the practical version of independence: adopting a federated credential next year does not disturb the enforcement you put in place this quarter, and deciding to consult a policy engine does not oblige you to change how identity arrives.
The configurations that produce these outcomes, with the policy definitions, the AuthZEN request and response, and the same refund walked through each of them, are in the implementation walkthrough.
Connection is Not Authorization
The industry solved the easier half of this problem and has been quietly calling it done. Knowing which agent may connect to which application is real progress and it was worth standardizing. It tells you nothing about whether this call, with these arguments, against this record, should have run. That question is still open, and it is the one your auditors will ask about first.
Which is where the argument stops being conceptual. The map has six positions a real deployment can sit in, and the difference between them is not a diagram. It is the policy someone has to write, the system that holds the number inside it, and what breaks when the credential changes shape underneath it.
The second post, Six Ways Traefik Hub Enforces One Refund, puts a single operation through the four positions where something enforces, six configurations in all: a support agent issuing $75 against one invoice, against a $500 ceiling and a $100 remaining balance.
Every policy in full, every block labeled with the system that owns it, and the same question asked six times: where does the ceiling actually live? The answer moves in each one, and where it lands is the whole decision this post has been circling.
We built Traefik Hub to sit in that path and stay neutral about both questions, because we would rather be the thing that still works after you change your mind. If you are working through these choices, we would like to compare notes.
Ready to see all this in action? Read Part 2: Six Ways Traefik Hub Enforces One Agentic Refund.
