Who Authorized This Tool Call? OpenID AuthZEN, the MCP Profile, and the Standards Race to Govern AI Agents

1. The token was valid. The tool ran.#

An MCP agent holds a perfectly ordinary OAuth 2.1 access token: correct issuer, unexpired, carrying the crm:write scope, and -- because the server did its RFC 8707 homework ^[1] -- an audience bound to exactly this MCP server and no other. The agent calls delete_customer(id="9931"); the token check passes, the tool runs, the customer record is gone. And no component anywhere in that path ever decided whether this user's agent was allowed to delete this particular customer. The token answered "is this a valid caller?" It never answered "is this action, on this resource, for this user, allowed?"

The failure is invisible precisely because nothing is broken. The call is valid, in-scope, and audience-bound, and the tool did exactly what it was asked. That is not a missing check; it is a category error.

Authentication and coarse scopes answer "is this token valid, and does the agent hold the right scope?" They structurally cannot answer "is THIS agent, acting for THIS user, allowed to perform THIS action on THIS resource in THIS context?" Four distinct layers hide inside "authorization" here: OAuth 2.1 token validity, RFC 8707 audience binding, the OAuth scope, and a per-call decision on the specific arguments. The first three are real and necessary. None of them is the fourth. Set the clock from the first screen: the OpenID AuthZEN Authorization API 1.0 is a Final Specification approved January 12, 2026 ^[2], but the MCP Tool Authorization Profile that maps tool calls to decisions is only Draft 1, dated February 13, 2026 ^[3]. Final API, draft profile -- that gap is the whole standards race.

If that sounds like a hypothetical, consider the case where the answer to "who authorized this tool call?" was, literally, "no one." On June 18, 2026, Microsoft disclosed AutoJack: AutoGen Studio's Model Context Protocol control plane, reachable over a WebSocket, that skipped authentication entirely on its /api/mcp/* surface ^[4]. This is a missing-authentication control-plane weakness (CWE-306), chained through a permissive origin check (CWE-1385) and verbatim command execution of a query parameter (CWE-78) into remote code execution on the host running the agent.

Microsoft hardened it in commit b047730 ^[5]; it never shipped in a PyPI release and carries no CVE -- a research demonstration, not mass exploitation. It is not, and this matters for later, a skill-scanner bypass. It is the limit case of a tool call with no enforcement point at all.

"The MCP WebSocket accepted connections without any authentication regardless of the auth mode configured for the rest of the app." -- Microsoft Security, on AutoJack ^[4]

Between the two scenarios sits this article's subject. In the first, every OAuth check passed and still no layer expressed the per-resource decision. In the second, there was no check to pass. Both point at the same missing thing: a component whose only job is to decide, freshly, at the moment of use, whether this call is allowed. That idea is not new. It is fifty years old. Who first insisted that every access be checked, and who first named the exact hazard that an autonomous program holding someone else's token represents?

2. Complete mediation, the confused deputy, and the birth of the decision/enforcement split#

The governing principle arrived in 1975. Jerome Saltzer and Michael Schroeder, cataloguing the design principles of secure systems, stated the one that matters most here: complete mediation -- "every access to every object must be checked for authority" ^[6]. Not once at login, not cached and reused, but freshly, at the point of use, every time. Read forward half a century, a per-call authorization decision on a tools/call is complete mediation applied to an autonomous agent. The whole history that follows is a series of attempts to honor that principle for programs that insist on holding ambient authority.

The vocabulary came a few years earlier. Butler Lampson's 1971 access matrix framed protection as subjects against objects against permitted operations ^[7] -- the same subject/object/operation substrate that Attribute-Based Access Control and, later, AuthZEN's Subject-Action-Resource model still inherit. Saltzer and Schroeder added the governing principles: complete mediation and least privilege. But real systems honored complete mediation mostly in the breach. They cached decisions and handed programs ambient authority -- authority a program carries by virtue of who it is, independent of the request it is currently serving.

Norm Hardy named the failure that follows. In The Confused Deputy (1988), he described a program that "runs with authority stemming from two sources" and gets tricked into wielding the more powerful one on an attacker's behalf ^{[8] [9]}. The concrete incident: a compiler holding a "home files license" so it could update its own statistics file was induced to overwrite the system billing file when a user named that file as the compiler's debug-output destination. Hardy dates the incident to "about eleven years ago" relative to his 1988 paper -- so roughly 1977, at Tymshare, on an operating system he says was "much like Unix" ^[8]. Two common secondary errors are worth avoiding: it was not the "early 1970s," and it was not a Burroughs B5700.

Read 2026-forward, the confused deputy is the AI agent: an autonomous program holding the user's token, one prompt-injected instruction away from a tool call the user never intended.

Containing a confused deputy requires separating the act of deciding whether an access is allowed from the act of enforcing that decision. The terminology was consolidated by the Informational RFC 3198 in 2001 -- Policy Decision Point and Policy Enforcement Point ^[10], which draws both definitions from the earlier RFC 2753 (2000) ^[11] -- and operationalized by the eXtensible Access Control Markup Language and NIST's ABAC guidance, which add a Policy Information Point for attributes and a Policy Administration Point for authoring ^{[12] [13]}. RFC 3198, "Terminology for Policy-Based Management," is an Informational glossary by Westerinen, Schnizlein, Strassner and others, published November 2001 -- it consolidates the terms rather than coining them, drawing both definitions from the earlier RFC 2753 (2000), and it predates XACML, which cites it directly for the PDP definition ^{[10] [11] [12]}.

flowchart LR
A[Agent request] --> PEP[PEP intercepts the access]
PEP -->|asks| PDP[PDP decides]
PIP[PIP supplies attributes] --> PDP
PAP[PAP authors policy] --> PDP
PDP -->|permit or deny| PEP
PEP -->|enforces| B[Tool runs or is refused]

This split is the precondition for everything that follows: you cannot standardize the interface between a decider and an enforcer until you have separated them. And yet the split was named around 2000 and had a full standard by 2003. So why, a quarter-century later, is "who authorized this tool call?" still an open question? Because the first serious attempt to answer it was too heavy to deploy, and the thing that won the world instead was too coarse to express it.

3. XACML's heavyweight PDP/PEP and OAuth's lightweight scopes#

Two standards took opposite bets on the decision/enforcement split, and both failed the per-call agent question -- one because it was too heavy to deploy, the other because it was too coarse to express it.

The first bet was to externalize everything. The eXtensible Access Control Markup Language became an OASIS Standard in February 2003, with the still-current 3.0 ratified in January 2013 ^[12]. It was the serious, interoperable externalized-authorization standard of the 2000s: a full XML policy language on top of the PDP/PEP/PIP/PAP architecture, correct in principle and auditable in the center.

Its failure was deployability, not correctness -- and the evidence is the standard's own remediation. OASIS later published a JSON Profile for XACML whose stated motivation is that "it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted" ^[14]: a primary-source admission that the XML itself was the adoption barrier.

A whole shorthand language, ALFA, exists mainly to escape the XML. To answer one yes-or-no question a team had to stand up a PDP, author XML policy sets, wire a PIP, and marshal an XML request and response -- so most teams never deployed it end to end.

The second bet was to externalize nothing. OAuth 2.0 (RFC 6749, 2012) took the opposite path: after the user authenticates, bake coarse, authorization-server-defined entitlements directly into the bearer token as scope -- per Section 3.3, "a list of space-delimited, case-sensitive strings ... defined by the authorization server" ^[15]. It won the web because it is nearly free to enforce: a local, constant-time, string-set membership check, no PDP and no round trip.

But scopes are static (frozen into the token at issuance), opaque (read:documents names no specific document), and resource-blind. They cannot express a per-call, per-resource, user-contextual constraint. The AuthZEN working-group charter names this exact pattern -- "embedding entitlements into OAuth2 bearer tokens after user authentication" -- as the problem it exists to fix ^[16]. And worse for agents: a bearer token is ambient authority, which is precisely Hardy's confused-deputy hazard wearing a modern uniform.

Make the failure executable. A crm:write scope check happily returns true for delete_customer(id="9931") -- and there is no way to widen it into "only customers in this user's own tenant," because the tenant relationship is not in the token and cannot be.

// A scope is a static string, frozen into the token at issuance time.
const token = { sub: "user-42", scope: "crm:read crm:write", aud: "urn:crm-api" };

function hasScope(token, needed) {
return token.scope.split(" ").includes(needed);
}

// The check the tool call actually performs before running delete_customer:
console.log("hasScope crm:write ->", hasScope(token, "crm:write")); // true, so the call proceeds

// The decision we actually wanted to make:
function canDeleteCustomer(user, customer) {
// Needs the customer's tenant AND the user's tenant.
// Neither value is present in the token, and a static scope cannot carry them.
return customer.tenantId === user.tenantId;
}

const customer = { id: "9931", tenantId: "tenant-A" };
const user     = { id: "user-42", tenantId: "tenant-B" };

console.log("canDeleteCustomer ->", canDeleteCustomer(user, customer)); // false
console.log("The scope check already said yes. The token could never carry customer.tenantId.");

Two dead ends, opposite in every way, frame the same gap: externalize the decision and it is too heavy to deploy; bake it into the token and it is too coarse to express. The obvious repair -- keep externalization but make the engine lightweight and developer-friendly -- is exactly what a whole generation built next. So why did that fail too?

4. Five generations, each forced by the last one's failure#

The genealogy of externalized authorization is not a list of options; it is a forcing function. Each generation was pushed into existence by a specific failure of the one before, and the interesting content is precisely what each failure motivated next.

Generation 1 -- XACML PDP/PEP (2003 to 3.0 in 2013). It solved interoperable policy expression and failed on deployability, for the reasons Section 3 gave: the XML was too heavy, and the architecture survived while the language was routed around ^{[12] [14]}.

Generation 2 -- OAuth 2.0 scopes (2012). It solved lightweight, ubiquitous, coarse authorization and failed on granularity and dynamism: scopes are static, baked in, and resource-blind ^[15]. The charter that eventually answered this names the pattern outright ^[16].

Generation 3 -- policy-as-code engines (OPA in 2016, Zanzibar in 2019, Cedar in 2023, alongside Topaz and Cerbos). This generation technically succeeded. Open Policy Agent evaluates Rego against input JSON and graduated from the CNCF in February 2021 ^{[17] [18]}.

Google's Zanzibar answers relationship checks at a scale nothing else has published: it "scales to trillions of access control lists and millions of authorization requests per second," and "has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years" (lead author Ruoming Pang) ^{[19] [20]}. AWS Cedar, open-sourced in May 2023, trades raw expressiveness for a deliberately analyzable language ^{[21] [22]}. Vendor authorizers -- Aserto's Topaz, Cerbos -- sit here too ^{[23] [24]}.

And yet the generation failed on interoperability: every engine spoke its own PDP wire API. Capability everywhere, interoperability nowhere. This is the SAML-before-OIDC moment for authorization, and the AuthZEN charter names the fragmentation directly. Throughout the base MCP authorization work, OAuth 2.1 is cited as an IETF draft -- draft-ietf-oauth-v2-1-13 in the base MCP spec, and draft-12 in the AuthZEN MCP profile ^{[25] [26]}. It has no RFC number, and attaching one is a common error worth not making.

"Interoperability between different architectures and between different implementations are particularly challenging." -- the OpenID AuthZEN Working Group charter, on the Generation 3 fragmentation ^[16]

Generation 4 -- the OpenID AuthZEN Authorization API 1.0. The working group formed in 2023; the specification became an OpenID Foundation Final Specification on January 12, 2026 ^[2]. It standardized the PDP-to-PEP wire protocol itself, engine-neutral -- the OIDC moment for authorization ^[27]. Section 5 unpacks exactly how.

Generation 5 (in flight) -- the AuthZEN MCP Tool Authorization Profile, "COAZ." Draft 1, dated February 13, 2026, extends that wire protocol to per-tool-call, parameter-level decisions for AI agents ^[3]. Note the maturity gap right here: a Draft profile, thirty-two days after the Final API, with no production corpus of tool mappings yet. Section 6 is its mechanics.

flowchart TD
G1["Gen 1 XACML PDP/PEP, 2003 to 2013: interoperable policy, but XML too heavy to deploy"] --> G2
G2["Gen 2 OAuth 2.0 scopes, 2012: lightweight and ubiquitous, but too coarse to express the call"] --> G3
G3["Gen 3 policy engines OPA, Zanzibar, Cedar, 2016 to 2023: fine-grained and fast, but every engine its own API"] --> G4
G4["Gen 4 AuthZEN Authorization API 1.0, Final 2026: the PDP-to-PEP interface, standardized"] --> G5
G5["Gen 5 AuthZEN MCP profile COAZ, Draft 2026: the interface, profiled to the tool call"]

Watch the human hand-off, because it is the tell. The founders of the very engines that fragmented Generation 3 are the editors and authors of the AuthZEN specifications that unify them: Omri Gazitt of Aserto, behind Topaz ^[28]; Alex Olivier of Cerbos; David Brossard, carrying the XACML and ABAC heritage; Atul Tulshibagwale of SGNL, who spans both the base API and the MCP profile ^{[27] [3]}. The people who built the silos are the ones standardizing the interface between them.

Four generations of adding more -- more policy language, more scopes, more engines -- and the interoperability gap only widened. Generation 4 closed it by doing the opposite. What is the one subtractive idea that makes AuthZEN succeed where XACML and every siloed engine did not?

5. AuthZEN 1.0 and the SARC model: standardize the interface, not the engine#

Here is the whole idea in one sentence: AuthZEN standardizes the wire protocol between the decision point and the enforcement point, and nothing else. The specification's abstract says PDPs and PEPs "communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings" ^[27]. The decisive move is subtractive. The spec explicitly places the "policy language, architecture, and state management aspects of a PDP" beyond its own scope ^[27]. That omission is not a gap in the standard. It is the standard.

Build the mechanism in three parts.

The information model. The request names a Subject, an Action, a Resource, and a free-form Context -- the model the MCP profile abbreviates SARC -- and the PDP's response adds a fifth entity, the Decision ^{[27] [3]}. The canonical example makes it concrete: Can Alice view document #123 at 16:30 on Tuesday? A PEP builds a small JSON request -- subject with a type and id, an action name, a resource with a type and id, and a context object -- and POSTs it. The PDP answers with a boolean.

The three endpoint families. Access Evaluation takes one subject, action, and resource and returns one decision. Access Evaluations batches many decisions into a single round trip -- "boxcarring." Search asks the inverse question: which resources, subjects, or actions are permissible ^[27]. The API is transport-agnostic with a normative HTTPS binding, and the PEP ships only the SARC attributes -- never the policy, never the engine's state.

Why the omission is the breakthrough. Because AuthZEN standardizes only the interface, Topaz, OPA, Cedar, Cerbos, or Axiomatics can all sit behind the same PEP, exactly as OIDC let any identity provider sit behind the same relying party -- an analogy the charter draws itself ^[16]. The PDP becomes swappable. That is the interoperability the Generation 3 engines never had, and it arrives by subtraction, not addition.

Policy Decision Points and Policy Enforcement Points "communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings." -- AuthZEN Authorization API 1.0 ^[27]

AuthZEN succeeds by standardizing less than XACML, not more. It ratifies only the PDP-to-PEP interface -- the Subject-Action-Resource-Context request and the Decision response -- and deliberately leaves the policy language, the architecture, and the state out of scope. That is precisely how OIDC beat SAML-era fragmentation for authentication: not a better identity provider, but a standard interface any identity provider could sit behind. The interoperability the fine-grained engines never had comes from the subtraction.

The milestone is what makes the next section possible. The Authorization API 1.0 became an OpenID Foundation Final Specification on January 12, 2026 -- "not subject to further revision," carried on 107 total votes ^[2]. A ratified, engine-neutral substrate is exactly what an agentic profile can now build on. Hold the maturity gap in view even at the moment of triumph: the API is Final and "not subject to further revision" as of January 12, 2026 ^[2], but the profile that maps tool calls onto it is Draft 1, dated February 13, 2026 -- thirty-two days later, and still moving ^[3].

flowchart LR
S[Subject: the user] --> REQ[AuthZEN request]
A[Action: the operation] --> REQ
R[Resource: the object] --> REQ
C[Context: agent, time, environment] --> REQ
REQ --> PDP[AuthZEN PDP, engine-neutral]
PDP --> D[Decision: permit or deny]
PDP --> EP["Endpoints: Access Evaluation, Access Evaluations, Search"]

But a ratified PDP-to-PEP protocol is, by design, generic. Hand a PEP a raw MCP tools/call -- a JSON-RPC method name and an arguments object -- and it has no standard recipe for turning those parameters and the caller's token claims into a Subject, an Action, a Resource, and a Context. Something has to specify that mapping. That something is the profile.

6. The MCP Tool Authorization Profile (COAZ), in two layers#

You now believe the idea. Here is the whole machine -- and it lives in two distinct layers that must never be run together into one. Layer 1 answers "is this token even valid for THIS server?" Layer 2 answers "is THIS subject allowed THIS action on THIS resource in THIS context?" They are different questions, anchored in different specifications, and the most common factual error in this whole area is putting a Layer 1 control into Layer 2.

Layer 1 -- base MCP authorization (revision 2025-06-18). The Model Context Protocol's own authorization specification defines the token layer: OAuth 2.1 (the IETF draft) ^[25], plus RFC 9728 Protected Resource Metadata for discovery ^[29], RFC 8414 authorization-server metadata ^[30], RFC 7591 Dynamic Client Registration ^[31], and RFC 8707 Resource Indicators ^[1].

The load-bearing requirement: the spec says MCP clients "MUST implement Resource Indicators for OAuth 2.0 as defined in [RFC 8707]," and MCP servers "MUST validate that access tokens were issued specifically for them as the intended audience" ^[26]. That is audience binding -- the anti-confused-deputy control that keeps a token minted for one server from being spent at another.

Layer 2 -- the AuthZEN MCP profile (COAZ, Draft 1). A tool advertised in tools/list marks itself with "coaz": true and carries an x-coaz-mapping object inside its inputSchema ^[3]. The mapping's fields are Common Expression Language expressions over two inputs: token.*, the complete decoded claims of the JWT access token, and params.arguments.*, the tool-call arguments ^[33]. The profile's own worked example maps resource.id = params.arguments.location and subject.id = token.sub.

At call time, a Policy Enforcement Point -- the MCP gateway or the MCP server itself -- validates the token, evaluates the CEL to construct the SARC request, and calls the AuthZEN PDP's Access Evaluation endpoint. Only on a permit Decision does the tools/call execute ^[3].

The load-bearing design choice is the Zero-Trust separation. The profile represents the human user "as the AuthZen Subject" and the AI agent "in the AuthZen Context," so policy "can independently evaluate the trust level of both the user and the agent" ^[3]. This is the wire-format resolution of the user-versus-agent attribution gap. Walk it: token.sub -- the user -- becomes the Subject; params.name becomes the Action by default; params.arguments.location becomes the Resource; the agent's own identity goes into the Context; and the PDP's answer is the Decision.

sequenceDiagram
participant C as MCP client
participant P as Gateway PEP
participant S as MCP server
participant PDP as AuthZEN PDP
C->>P: tools/call with access token
Note over P: Layer 1, validate token, check audience per RFC 8707
P->>P: evaluate x-coaz-mapping into a SARC request
P->>PDP: Access Evaluation, subject action resource context
PDP-->>P: Decision, permit or deny
alt Decision is permit
P->>S: forward tools/call
S-->>C: tool result
else Decision is deny
P-->>C: request refused
end

The second diagram shows the data transformation the first hides inside one step: how the mapping builds the four SARC entities.

flowchart TD
T["token.* decoded JWT claims"] --> CEL[CEL evaluation]
A["params.arguments.* tool-call arguments"] --> CEL
CEL --> SUB["Subject from token.sub, the user"]
CEL --> ACT["Action from params.name"]
CEL --> RES["Resource from params.arguments.location"]
CEL --> CTX["Context carrying the agent identity"]
SUB --> PDP[AuthZEN PDP]
ACT --> PDP
RES --> PDP
CTX --> PDP
PDP --> D[Decision gates the tool call]

Made runnable, the "with authorization" answer mirrors the failing scope check from Section 3 -- same inputs, now assembled into a decision the engine can make.

// An MCP tools/call: the method name and its arguments.
const params = { name: "read_weather", arguments: { location: "Seattle" } };

// The decoded, already-validated JWT access-token claims.
const token = { sub: "user-42", client_id: "agent-7", scope: "weather:read" };

// A tiny x-coaz-mapping (in the real profile these fields are CEL expressions).
const mapping = {
subject:  (p, t) => ({ type: "user", id: t.sub }),          // the user
action:   (p, t) => ({ name: p.name }),                     // default: the tool name
resource: (p, t) => ({ type: "location", id: p.arguments.location }),
context:  (p, t) => ({ agent: t.client_id })                // the agent goes here
};

// The PEP assembles the SARC request from token claims and call arguments.
const sarc = {
subject:  mapping.subject(params, token),
action:   mapping.action(params, token),
resource: mapping.resource(params, token),
context:  mapping.context(params, token)
};
console.log(JSON.stringify(sarc, null, 2));

// A mock AuthZEN PDP: this user may read weather only for Seattle.
function accessEvaluation(req) {
return { decision: req.subject.id === "user-42" && req.resource.id === "Seattle" };
}

const result = accessEvaluation(sarc);
console.log("decision ->", result.decision); // true -> the tool call is allowed to run

Here are the same three moves as the literal artifacts a server and PEP exchange, not an analogy. First, the x-coaz-mapping the server publishes inside the tool's inputSchema; every value is a CEL expression over token.* and params.arguments.*, and static types are written as single-quoted CEL string literals ^[3]:

"x-coaz-mapping": {
  "subject": [{ "type": "'user'", "id": "token.sub" }],
  "resource": [{ "type": "'location'", "id": "params.arguments.location" }],
  "context": [{ "agent": "token.client_id" }]
}

With action left unmapped it defaults to the tool name. Evaluating those expressions against the call above -- token.sub is user-42, params.arguments.location is Seattle, token.client_id is agent-7 -- the PEP sends this AuthZEN Access Evaluation request to the PDP ^[3]:

{
  "subject": { "type": "user", "id": "user-42" },
  "action": { "name": "read_weather" },
  "resource": { "type": "location", "id": "Seattle" },
  "context": { "agent": "agent-7" }
}

The PDP returns the minimal AuthZEN Decision, and only a permit lets the tool call run ^[27]:

{
  "decision": true
}

Two more properties matter for later. COAZ is opt-in and backward compatible: non-COAZ clients "will simply ignore these fields." And the deployment-coverage caveat is stated in the profile itself: "If no PEP in the request path processes the mapping, no AuthZen authorization occurs and access control falls back to whatever other mechanisms are in place" ^[3]. Hold onto that sentence; it becomes a hard ceiling in Section 8.

That is one coherent, two-layer stack. But it is not the only body standardizing agent authorization in 2026. Some want to encode more in the token; most MCP servers ship Layer 1 alone; others govern an entirely different slice. Which layer does each own, where do they collide, and which one actually answers the tool-call question?

7. The standards race to govern AI agents#

Several bodies are standardizing agent authorization at once, at different layers, and the honest framing is that most of them compose rather than collide. The genuine rivalry is narrower than the headlines suggest. My position: externalized, interoperable, per-call authorization is the architecturally correct layer for "who authorized this tool call?" -- and it is racing a deployment reality in which, by all indications, the overwhelming majority of MCP servers still authorize with scopes alone.

AuthZEN and COAZ (externalize the decision). The per-call decision lives in a policy engine reached over a standard API. It is the only approach that both expresses the runtime, per-resource question and standardizes the interface ^{[3] [27]}.

OAuth-native encoding (put more in the token). Rich Authorization Requests replace coarse scope strings with a structured authorization_details array, so a token can carry something like "may transfer up to $500 from account X"; the AuthZEN profile references RAR only informatively ^[32].

Token Exchange lets one token be swapped for another -- an agent trading its own token for a downscoped, user-delegated one -- the leading candidate answer to "where does the user identity in the token come from?" ^[34]. Both add zero hot-path round-trips, because the decision is pre-computed into the token. Both are therefore static at issuance: the token cannot reflect state that changes between issuance and the call.

Base MCP OAuth-only (the deployed baseline). The base MCP spec standardizes only scopes plus RFC 8707 audience binding and no per-call PDP ^[26] -- and, though no MCP-adoption survey exists to measure this, that baseline is almost certainly what most servers currently implement. This is the baseline the article argues is structurally insufficient for the tool-call question -- necessary, cheap, and blind to the specific resource.

Siloed engines and adjacent agentic standards. OPA, Zanzibar, and Cedar can each be the AuthZEN PDP behind a COAZ PEP -- competitors that become components the moment the interface is standardized ^{[17] [19] [22]}.

And a different slice entirely: Google's Agent Payments Protocol and the FIDO agentic-authentication work govern verifiable intent for commerce. AP2 builds trust from Mandates -- "tamper-proof, cryptographically-signed digital contracts ... signed by verifiable credentials" -- proving a human authorized a purchase ^[35]. That is not a per-tool decision; it composes with AuthZEN rather than competing with it. A companion article in this series covers the AP2 and FIDO slice in depth. Common Expression Language, the language the COAZ mapping is written in, is a Google project with evaluators in Go, C++, and Java. The article shows one expression but does not teach the grammar -- the mapping layer's tooling already exists across runtimes ^[33].

Layered or rival, every one of these leans on the same promise: that some component can decide, at the point of use, whether a call is authorized. So ask the uncomfortable question. Even with a ratified standard, fully deployed everywhere, what can that decision never buy?

8. What no standard, fully deployed, can buy#

This is the deliberate cold shower. A per-call PDP is the most faithful realization of complete mediation the field has yet produced -- it moves the check to the exact point of use. And it still cannot buy four things, true even if COAZ were Final and deployed everywhere tomorrow.

The intent gap. A PDP decides only on the attributes the PEP hands it. It cannot know the user's true intent. A call that is syntactically authorized -- correct subject, correct resource, permitted action -- but driven by a prompt-injected instruction is still authorized. No standardization closes this; it is a fundamental limit of attribute-based mediation. The whole reason agent tool calls are dangerous, prompt injection, lives in this gap, and no wire protocol reaches into it.

The confused-deputy ceiling. Hardy proved in 1988 that a deputy holding ambient authority can be induced to wield it for another principal ^[8]. Audience binding and per-call decisions contain the confused deputy -- they narrow where and whether the authority applies -- but they do not eliminate it. The PDP trusts the PEP's SARC construction, and a compromised PEP or a maliciously authored x-coaz-mapping re-opens the hole. The profile concedes exactly this in its mapping-integrity discussion ^[3].

The deployment-coverage floor. Authorization is only as strong as the weakest enforcement point. The profile states it plainly: "If no PEP in the request path processes the mapping, no AuthZen authorization occurs" ^[3]. AutoJack is the limit case where there is no enforcement point at all -- CWE-306, zero PEPs, and "who authorized this tool call?" answered "no one" ^[4]. No protocol can authorize a call that never reaches a decision point.

The static-analysis ceiling. You cannot scan your way to runtime authorization. Trail of Bits bypassed every mainstream agent-skill scanner -- ClawHub's detector, Cisco's scanner, and "all three of the scanners integrated into skills.sh" -- using tricks as blunt as prepending 100,000 newlines, and archived the working payloads publicly ^{[36] [37]}. Their conclusion is the ceiling: a scanner's "static nature gives an adversary unlimited bites at the apple." Pre-install scanning and per-call authorization are orthogonal; neither substitutes for the other.

A scanner's "static nature gives an adversary unlimited bites at the apple." -- Trail of Bits, on why scanning is not authorization ^[36]

The two "without authorization" disclosures attack different layers and must be kept apart. One is a control-plane failure; the other is a supply-chain failure. Conflating them hides that they demand different fixes.

State the gap plainly. The ideal -- every call mediated, at every enforcement point, over a standard interface, informed by verified intent and live state -- is asymptotically approachable and never reachable, because true intent is not a property the PEP can observe. Being precise about that irreducible gap is what separates a real trust layer from a marketing claim. These are the structural ceilings, true even if the specs were finished tomorrow. But the specs are not finished. What is still genuinely unsettled as of mid-2026?

9. What mid-2026 leaves unsolved#

This is a standards frontier, not a complexity-theory one, so each open problem is a precise engineering or governance question with a current partial state -- not a conjecture.

1. The maturity and adoption gap. The Authorization API is Final; the MCP profile is only Draft 1; and, as you would expect of a profile that new, effectively no production MCP server ships x-coaz-mapping yet ^[3]. The "with authorization" world is still largely aspirational, and, on the current evidence, the deployed majority still authorizes with scopes alone. The partial state is genuinely encouraging: a Final API is exactly the substrate on which a Draft profile can stabilize, and a multi-vendor interop program already shows the API is testable across engines ^[27].

2. The user-identity-in-the-token gap. OAuth issues the token to the agent, and, in the profile's own words, "there is no standard mechanism to capture the identity of the user on whose behalf the tool is being invoked" ^[3]. Yet the entire user-as-Subject separation assumes that user claim exists to map. The leading candidates are Token Exchange and identity-assertion or on-behalf-of grants ^[34], none yet profiled for MCP.

3. Mapping integrity and trust. The x-coaz-mapping is authored by the MCP server, so a malicious server can craft a mapping that misrepresents the SARC request to the PDP -- substituting a benign resource id for a sensitive one. The profile requires PEPs to validate that the mapping is well-formed, but that is a SHOULD, not signing or attestation ^[3].

4. PDP latency and availability on the hot path. Every COAZ tool call adds a synchronous PDP round-trip, making the PDP a tier-0 dependency of every action. The Access Evaluations endpoint amortizes many checks into one request, and Zanzibar demonstrates the engine layer can hold 95th-percentile latency under 10 milliseconds and availability above 99.999% ^[19] -- but there is no standardized decision-caching or time-to-live profile for MCP yet.

5. Multi-hop agent chains. When an agent calls another agent that calls a tool, how does the SARC Context -- which agent, acting on whose behalf -- propagate across hops? The profile fixes user-as-Subject and agent-as-Context for a single hop; nothing yet standardizes propagation across a chain ^[3].

6. Revocation and continuous evaluation. A decision made at call time can be stale by the next call, and a long-running agent makes thousands of calls per session. Per-call evaluation already re-checks every time -- a real advantage over decide-once-at-issuance -- but push-based revocation between the token layer and the PDP is unstandardized. This is the bridge to Continuous Access Evaluation, treated in a companion article: the revocation channel that supersedes a decision before the next call.

7. The supply-chain layer is orthogonal and unsolved. Per-call authorization does nothing about which tool code got installed. Trail of Bits showed scanning does not catch malicious skills ^{[36] [37]}, and an authorized call to a malicious tool is still harmful. Runtime authorization and supply-chain integrity are two separate unsolved problems, and solving one does not touch the other.

Seven open problems -- and yet the API spec, the profile draft, and conformant PDPs are all public today. The companion AuthZEN Access Request and Approval Profile is a separate Draft that specifies what happens on a deny: an approval workflow, so a refused call can escalate to a human rather than simply failing ^[38]. So what can an MCP server author, a gateway operator, or a platform team actually build this quarter, and what should they refuse to assume?

10. What you can build this quarter#

Concrete guidance, keyed to the layer you occupy, each item tied to a primary source.

1. Get Layer 1 right first. Implement OAuth 2.1, RFC 9728 Protected Resource Metadata discovery, and RFC 8707 Resource Indicators so your tokens are audience-bound to your server ^{[26] [29] [1]}. This is the cheapest, highest-impact step, and skipping it is how you become the confused deputy.

2. Put a PEP in every tool-call path. Never let a tool execute with no enforcement point. The AutoJack lesson is verbatim: "control planes must be authenticated, authorized, and isolated" ^[4]. A per-call PDP upstream is worthless on any path that routes around it.

3. For fine-grained needs, adopt the AuthZEN profile. Mark sensitive tools coaz: true, author an x-coaz-mapping (token claims into the Subject, tool arguments into the Resource and Context -- the literal shape is the one in Section 6), and stand up a conformant AuthZEN PDP -- Topaz, OPA, Cerbos, Cedar with Verified Permissions, or Axiomatics ^{[3] [23] [17] [24]}. The engine is swappable precisely because only the interface is standardized.

4. Separate the user from the agent. Put the human in the Subject and the agent in the Context, per the profile's Zero-Trust guidance, so policy can evaluate the trust level of both independently ^[3].

5. Validate the token before you map it. Verify signature, issuer, audience, and expiry before extracting any claims into a SARC request ^[3]. Extracting token.sub from an unverified token authorizes on a forged identity -- the mapping step assumes a token that Layer 1 already vouched for.

6. Do not treat pre-install skill scanning as authorization. Trail of Bits proves scanning is necessary but insufficient ^[36]. Pair it with runtime, per-call enforcement; the two are orthogonal controls, and neither covers the other's gap.

7. Track the Draft and expect churn. The profile is early -- dated February 13, 2026 -- and companion work is still moving, including the Access Request and Approval Profile for denials and the anticipated MCP Server Cards ^{[3] [38]}. Build against it, but pin versions and expect revisions.

Seven things to build, and a handful of misconceptions worth dismantling before you brief your team -- several are the exact confusions this article was written to prevent.

11. Frequently confused, finally separated#

Trace the argument one last time, with the evidence now in hand. Complete mediation (1975) demanded a fresh decision at every access ^[6]. The confused deputy (1988) named the exact hazard an autonomous program holding someone else's token represents ^[8]. Twenty years of PDP/PEP architecture could decide but never interoperably -- until AuthZEN's subtractive move, standardizing the interface and not the engine, finally gave "who authorized this tool call?" a runtime, interoperable answer ^[27]. COAZ profiles that answer down to the tool call, with the user as Subject and the agent as Context ^[3].

The industry is converging on this answer unevenly, under a live standards race -- a Final API beneath a Draft profile so new that almost no server ships it yet -- but it is converging on externalized, per-call authorization, not on better tokens and not on better scanners. The "without authorization" world is what its absence already costs: a control plane that authenticated no one ^[4], and a scanner that an adversary gets unlimited tries to beat ^[36].

The answer to "who authorized this tool call?" is not a better token and not a better scanner. It is an externalized, per-call authorization decision, made at the point of use, over an interface any engine can sit behind -- with the human user and the AI agent held apart on the wire, so policy can reason about both. That decision now has a standard shape. What it does not yet have, everywhere it needs to be, is a PEP to ask it.