The Gateway Should Not Own the Approval

In this version of part one’s refund, the enterprise lets the support agent refund up to $250 on its own, and the refund is for $480, so it needs an exception. The supervisor approves it in the agent gateway’s approval inbox, and the MCP gateway, from another vendor, then asks the supervisor to approve the same refund again in its own. The enterprise should choose which service handles an exception and who approves it, and every gateway on the path should send its exceptions there. Part one’s contract standardizes how enforcement points ask for a decision. It does not make two products agree on what a tool call means, what an approval is, which duties a permit carries, or what a token may hold. Each AuthZEN workstream supplies one of those meanings, and the refund meets them in the order it executes.

I edit two of these profiles, ARAP and AROP, and wrote MCP’s SEP-2848. Omri Gazitt wrote the OAuth issuance profiles, Alex Olivier and Atul Tulshibagwale wrote COAZ, and Alexandre Babeanu wrote the Obligations profile.

Following the Refund

A role or a scope such as refunds.write can admit the caller to the operation, but the refund decision also needs the order, the amount, the customer relationship, the refund window, and any required approval. The Blueprint’s rollout advice puts that fine-grained and relationship-based authorization in place before intent-based authorization scopes permissions down.

1. COAZ Maps the Tool Call to a Decision Request

The Blueprint’s agent gateway governs “agent actions, not just access,” denying or requiring approval for sensitive tool actions, and its monitoring layer inspects the arguments passed to tools. Every gateway vendor has to translate an MCP tool call into a policy question to do that, and today each does it privately. AgentCore makes the gateway the resource, and a PDP written for AgentCore’s requests cannot read another gateway’s.

COAZ, the working group’s framework for mapping protocol messages into decision requests, makes that translation portable. The framework defines how any protocol message becomes an AuthZEN evaluation. The MCP binding covers every client-to-server MCP request, with a default mapping per method and a deny for methods it does not know. A tool can declare its own mapping in its tools/list entry, so the gateway learns it from traffic it already proxies. In the binding’s words, “the MCP server declares how its operations are to be authorized, and the gateway enforces it.” A proposed MCP extension would bring the same mapping into MCP’s own authorization work. Here is the refund tool declaring that the order is the resource, the human user is the subject, and the agent is carried in the context:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "name": "issue_refund",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id":   { "type": "string" },
      "amount_usd": { "type": "string" }
    },
    "x-authzen-mapping": {
      "evaluation": {
        "subject": { "type": "user", "id": "$token.sub" },
        "action": {
          "name": "issue_refund",
          "properties": {
            "parameters": {
              "order_id": "$params.arguments.order_id",
              "amount_usd": "$params.arguments.amount_usd"
            }
          }
        },
        "resource": { "type": "order", "id": "$params.arguments.order_id" },
        "context": { "agent": "$token.?client_id" }
      }
    }
  }
}

Any gateway that implements the binding, from any vendor, now asks the same question about this refund in the vocabulary the tool declared, and any PDP that knows that vocabulary can answer it. The server is also the party being authorized, so the binding treats every attribute a declared mapping produces, other than the verified subject.id, as untrusted input. The mapping describes the requested operation, and the order and amount it supplies are legitimate inputs to the decision. What PDP policies “MUST NOT” do is treat a mapped attribute as authoritative for identity or privilege. Verified identity and trusted policy data establish whether the caller is entitled to perform the operation. The binding also warns that an input the mapping leaves out “is not thereby evaluated by the PDP,” so every argument authorization depends on must be mapped or enforced some other way. How far to trust a server’s mappings is left to the deployment’s threat model, and the binding defines no way for an operator to pin or override them.

2. ARAP Turns the Denial into an Approval Request

The Blueprint asks for contingent review “whenever an agent’s action crosses defined financial or operational thresholds,” for workflow-in-the-loop pauses, and for access requests that “must be strictly evaluated against static permission ceilings and require mandatory owner verification for scope expansion.” Most enforcement points today can only deny an action that needs approval.

ARAP, the Access Request and Approval Profile, gives that denial a path to approval. The $480 refund is over the agent’s limit, so the PDP denies with reason: approval_required and adds context.access_request, which marks the denial requestable. The denial is still binding: “The PEP MUST NOT permit the requested operation based only on the presence of context.access_request.” The gateway, as the PEP, submits an access request bound to that evaluation and holds its task handle while the agent waits. On the MCP side, SEP-2848 proposes holding the tool call as an MCP Task while the approval runs server-side, with ARAP as one backend. When the supervisor approves, the gateway asks again with the approval in context.approval, and the PDP makes a new decision. “Neither approval.id nor approval.state is a bearer grant by itself.” The PDP enforces the Blueprint’s permission ceiling in that new decision and treats the approval as one input to it.

The Access Request Service behind that exchange does not have to live in the gateway or in the PDP. ARAP’s stated goal is an interoperable interface “for any PEP to route denied access to a centralized governance evaluator,” and when the service is independent of the PDP, the denial carries a PDP-signed binding token so the service can verify what it is being asked to approve. One Access Request Service can serve every gateway, harness, and token endpoint in the fleet, with identity governance, ITSM, chat approval, and case management systems behind the same endpoint, and it decides how each approval is made. A policy or a risk engine can approve within limits. A person can approve each request (human in the loop), supervise automated approvals and intervene by revoking one, which the PDP checks on every re-evaluation (human on the loop), or set the limits within which policy decides alone (human out of the loop). Another agent can approve, as the specification’s list of “AI supervisors” anticipates and the Blueprint’s guardian agents could. The policy owner decides whether an action needs approval, through the PDP’s rules, and the approval owner decides who or what approves, through the service’s routing. The gateway only has to implement ARAP, not its own approval workflow, inbox, or escalation rules. ARAP has been a working group draft since June.

One approval can also serve more than one enforcement point. ARAP says an approval that grants “an entitlement, role, scope, or other persistent state causes subsequent AuthZEN Authorization API evaluations matching that state to succeed without further Access Requests.” ARAP’s portable baseline is an exact repeat of the denied request, and broader matching is deployment-defined and “not portable across policy engines.” The agent gateway and the MCP gateway may ask the enterprise PDP nearly the same question about the $480 refund. A token endpoint asks about issuing a token, with a different action and resource, and the PDP has to establish that the approved refund justifies that issuance, a projection no profile yet specifies. The commerce platform’s policy need not accept the enterprise’s approval at all. A shared service removes duplicated approval workflows, but whether an approval can be reused depends on the policies agreeing on what it covers.

3. Obligations Carry the Permit’s Duties

Section 3.3.1.3 lists what context-aware enforcement does: “allow, deny, redact, step-up approval, scope reduction, suspension, or containment.” A boolean decision covers allow and deny. The others fall into two groups, depending on who authorizes the change. An obligation tells the enforcement point what it must do under an authoritative decision, and that work can change access, since session_termination ends a subject’s active sessions. An access request asks the appropriate governance process to reconsider or establish authority, and completing that process does not itself authorize the protected operation. A gateway that treats a completed approval as its own permit has let the enforcement point grant authority.

The Obligations profile carries the first kind of work. The refund’s permit might require a notification to the ticket’s queue or a step-up of the rep’s authentication, and other decisions can require session_termination. A PDP can check which types an enforcement point supports before relying on one. “A PEP that receives obligations it cannot or does not understand MUST treat the overall response as a DENY.” A gateway that implements the profile either performs the duty or refuses the action. A gateway that implements only the 1.0 API ignores obligations, so a PDP that needs a duty performed can permit only requests that declare support for it in supported_obligations. Redaction, masking, and partial response, which the Blueprint’s purpose-aware data security requires, have no registered type yet. Registering them would let a PDP require redaction the way it requires step-up.

4. The Commerce Platform Decides for Itself

The permitted refund reaches the commerce platform’s API gateway, which the Blueprint gives “ultimate authorization authority.” That gateway asks the commerce platform’s own PDP, under the commerce platform’s own policy, and it can still refuse the refund, for example because the order is past its refund window. The enterprise’s permit does not bind the platform. Both refusals reach their enforcement points through the same interface. AuthZEN stops at the enforcement point, so MCP has to carry the refusal to the agent, and SEP-2643 proposes a structured denial the agent can act on, whichever policy owner refused. All three MCP proposals cited here are open.

When the Privilege Is a Token

The flow above is the resource-side model from the Least-Privilege MCP series. The gateway asks a PDP whether this caller may refund this order for this amount now, combining the request with current order state, relationships, and approval evidence, and its permit is a decision for that enforcement point, not a credential the agent can present elsewhere. The same refund can also be authorized on the token side. The client requests authority for this order and amount as Rich Authorization Requests authorization_details, and the authorization server issues a token that represents it. With a self-contained token the resource can check the refund against it locally, and introspection, which RFC 9396 also supports, can add freshness.

These are complementary placements. An order-scoped token can bound the authority the agent carries, while the commerce PDP checks whether that order remains refundable. A broader token can establish the caller and its permitted scope while the resource applies fine-grained policy to each invocation. In either case, the resource checks the actual call, and its own policy can refuse it. The token’s granularity, where it is validated, and where the PDP sits are separate choices, and both placements can consult the same enterprise policy service through AuthZEN.

When the commerce platform requires its own order-scoped token, the authorization server is the enforcement point. AROP, the Access Request OAuth Profile, completes the same approval by issuing that token. The wait uses Client-Initiated Backchannel Authentication, which is Final, or one of two individual drafts, Deferred Token Response and a transaction challenge that makes the resource the enforcement point, and the token’s lifetime “MUST NOT exceed the recorded approval expiry.” The result is the “ephemeral privilege scoped to that single order,” with an expiry the approval sets. AROP was merged into the working group repository on September 2. A refund under the agent’s own limit needs neither ARAP nor AROP.

Omri Gazitt’s issuance profiles address what any token may carry. Cross-app access, time-bound grants, and delegation all happen at a token endpoint, and every OAuth specification behind them treats the issuing decision as local policy. The ID-JAG draft says the IdP “evaluates administrator-defined policy.” Gazitt’s series on policy at the token endpoint traces the same gap through Token Exchange and Transaction Tokens, and his three drafts address it.

The Token Issuance profile casts “the authorization server as a PEP.” A token request becomes a set of evaluations. A gate asks whether this party may obtain this kind of token at all (an action such as issue:access_token:authorization_code), and further evaluations ask about each scope and each authorization detail. The PDP can narrow the result, cutting scopes, lifetime, or audience, but may “not broaden it, re-subject it, or re-target it.” The Token Exchange binding evaluates both parties when authority changes hands, the subject being acted for and the party requesting the exchange. That puts the Blueprint’s delegation rule, a sub-agent bounded by “the intersection of its own entitlements and the delegating agent or human’s entitlements,” at a decision point. Computing the intersection stays with the PDP’s policy. The Authorization Claims profile fills token roles and entitlements from AuthZEN search, so the Blueprint’s coarse-grained, role-based controls read the same policy the runtime enforces, under a section titled “Enrichment Is Not Authorization.” All three were merged as working group drafts on September 2. They would let a token endpoint like Okta’s and a per-call gateway from another vendor answer to one policy owner.

Reducing Consent and Approval Prompts

Fine-grained consent and approval often fail in practice because they produce too many prompts. A person asked about every call stops reading them, and an unattended agent stalls waiting for someone who is not there. The fleet raises prompts in two ways, through authority the agent discovers it needs while working and through approvals that no one routes centrally.

An open-world agent discovers tools and required authority while it works. The support agent may learn which payment processor handled the order only after reading it, and then find that its token for the commerce platform covers order lookup but not a refund. Each discovery can raise a consent screen, a step-up, or an approval, and discovering a tool does not tell the client how to obtain authority to call it. The series reference walks through the client’s side of that loop.

The Blueprint asks for human approval where “the dollar, regulatory, or reputational thresholds that trigger mandatory human-in-the-loop approval” say so. Five levers keep the other decisions away from people.

Reducing prompts does not mean approving everything automatically. ARAP requires approver eligibility checks, such as self-approval and separation of duties, but leaves the choice of evaluator to the deployment. My recommended deployment rule is that an approval-required action in the irreversible, external-commitment, or privileged-administration classes gets an independent approver however the rest is routed, and that the approvals a deployment does automate get rate limits and anomaly checks. Whether an agent can serve as that independent approver is a deployment decision. In this refund, a person approves the $480, and nobody is asked about the order lookup.

Closing the Loop: Grant, Measure, Adjust

One decision contract, one Access Request Service, and the Blueprint’s own signals turn authority from a grant made once into a loop that grants, measures, and adjusts it while the agent works, the observe, orient, decide, act cycle John Boyd called OODA. Narrowing can be initiated without a new approval. A CAEP event invalidates a cached decision, an obligation forces step-up or ends a session, and a token endpoint issues less. Widening goes through the shared Access Request Service and a fresh evaluation. Either change takes effect within the deployment’s freshness, credential, permit, and execution bounds, and a freshness bound measures how quickly a change is observed, not how quickly someone notices a problem and makes the change. The SOC owns narrowing, the approval owner owns widening, and the policy owner sets the thresholds between them.

I recommend three operating rules.

1. Automate approval for an action class only when the largest plausible consequence of a wrong automated approval is acceptable under the preventive controls, exposure limits, and response bounds that apply. How fast an approval can be withdrawn is one input to that judgment, not the test. A narrowly constrained customer notification can be automated even though it cannot be unsent.
2. Measure the approval system as well as the entitlements. Track prompts per task, approval rate, time to decision, and approvals later reversed, joined on the trace identifier part one asks enforcement points to carry.
3. Treat a high approval rate as a reason to review a class, not to automate it, since routine work and a rubber-stamp process produce the same statistic. Move a class to policy only after naming the conditions that justified approval, the exceptions that needed judgment, and the controls that bound a wrong decision. Move a class whose automated approvals keep being reversed back to a person.

Adjustment is continuous authorization, which section 3.4.1.1 describes as “dynamic, real-time re-evaluation of security contexts that instantly downgrades permissions the exact moment a risk posture changes.” SSF and CAEP carry the event, and AuthZEN is the decision that re-runs. For the change to take effect, the PDP’s inputs have to incorporate it, and affected enforcement points, whichever vendor built them, have to invalidate or recheck the decisions they reuse. A PEP that discards its cache but queries a PDP whose data has not caught up makes a fresh decision on stale facts. Permits and tokens already issued stop working through expiry, active invalidation, or re-evaluation at use, and the deployment’s stated bound has to cover enforcement, not only delivery of the event. No profile yet defines that composition, and it is a candidate for joint work between the Shared Signals and AuthZEN working groups.

These workstreams can enforce task-specific policy when a deployment supplies the relationships, for example by binding one ticket’s operations to a revocable approval. They do not standardize how independent systems identify the same approved work and coordinate its lifecycle, so that one ticket can be stopped while the same agent’s other ticket continues. Part three takes up that contract. The full gap map is in the series reference.