Most authorization systems still treat denial as the end of the interaction.

1

{ "decision": false }

That model worked reasonably well in closed-world systems. Resources were known ahead of time. Applications were pre-integrated. Trust relationships were static. Permissions were provisioned before execution. Workflows were predictable enough that a denial usually meant the request was simply over.

Modern systems increasingly do not work that way.

Agents discover tools dynamically. Sub-agents delegate work downstream. Workflows cross trust boundaries. Resources appear at runtime. Missions evolve after they start. A request that is not authorized right now may still be legitimate if the right governance event occurs.

In that environment, a deny is often not a full stop. It is the beginning of an escalation process.

A support agent acting on behalf of an engineer may be authorized to investigate a tenant’s billing issue, then discover that the cause sits in a restricted payment-provider log outside its current mandate. Reauthenticating the engineer does not answer the real question. The question is whether this mission should expand to include that tenant, that log, that operation, and that time window. A requestable denial lets the policy decision point (PDP) pause the workflow, bind the denial to the original evaluation, obtain a scoped governance decision, and reevaluate before access continues.

That is the missing primitive: not an approval flow, but a requestable denial.

The protocol move is a standardized way for a PDP to say: deny, but escalate.

That realization is what led me to start working on what is now the AuthZEN Access Request and Approval Profile, an extension profile to the OpenID AuthZEN Authorization API for representing requestable denials, submitting access requests, and reevaluating authorization after a governance workflow completes.

But the more I worked on it, the more I realized this is not really about “access requests.” It is about something larger: authorization escalation interoperability.

That framing has now been validated externally. In May 2026, the OpenID AuthZEN Working Group adopted this work as a working group draft. Adoption is the working group signaling that requestable denials and authorization escalation are a real, in-charter gap worth standardizing, not a vendor-specific concern. The AuthZEN charter exists to make authorization interoperable across policy decision points and enforcement points through the Authorization API. Denial is part of that decision surface, so a standardized way to say “deny, but escalate” is a direct extension of what AuthZEN already standardizes rather than a departure from it.

Open-World Systems Break Static Authorization

Traditional authorization systems assume the authority envelope can be determined upfront: which resources will be accessed, which operations will occur, which delegation paths will exist, and which trust domains will participate.

That assumption breaks down quickly once agents enter the picture.

As discussed in OAuth for Open-World Ecosystems, modern agents increasingly discover APIs dynamically, interact with previously unknown systems, expand workflows during execution, delegate tasks downstream, and cross organizational trust boundaries. An agent may begin with a valid authorization scope and still encounter new runtime conditions: a newly discovered mailbox, a downstream SaaS API, a stronger operation, a higher-risk dataset, a new tenant boundary, or a delegated execution path.

The system now needs to answer a much harder question than “Is this token valid?”

It must answer “Should authority continue under these newly discovered runtime conditions?”

That is not authentication. It is runtime governance: deciding whether authority should change, not checking rights the agent already holds.

The Missing Layer Between Denial and Governance

Most authorization systems today have a structural gap. A decision point can say a few things: allow, allow with obligations the enforcement point must satisfy, or deny. What it cannot say in a standard way is:

“Access is currently denied, but governance escalation is available.”

That last shape is a distinct decision, not a fuzzy one. A requestable denial is still a denial: the answer right now is no, and access does not proceed. It is not indeterminate, not “try again,” and not “need more information.” What separates it from a hard denial is a bound, explicit escalation path. A hard denial offers nothing to ask for. A requestable denial names where to ask and binds the request to the exact evaluation that was denied.

That missing layer becomes important when authorization is no longer a single synchronous yes-or-no event. Agents, delegated execution, runtime discovery, mission expansion, and continuous governance all need a way to pause, ask for additional authority, and later return to the policy decision point with evidence that the governance event occurred.

Today, that escalation is usually proprietary: custom approval APIs, ticketing integrations, internal workflow systems, ad hoc polling mechanisms, and vendor-specific governance models. In practice it is often less structured than that. An agent hits a wall, a human gets paged in Slack, someone glances at the request and clicks approve, and the agent is waved through by flipping a flag or widening an allowlist. The approval is a message in a channel. It is not bound to the denial, it is not re-checked when the agent actually proceeds, and it quietly becomes a standing exception nobody revisits. Every platform invents its own version of this, and the result is fragmented governance interoperability.

The AARM control plane (Autonomous Action Runtime Management) intercepts every agent action before execution and resolves it to one of five decisions: allow, deny, modify, step-up, or defer. The last two are where a denial stops being the end of the story: step-up requires human approval before the action proceeds, and defer holds it pending more context. A requestable denial frames the other side of that boundary at the authorization layer: how the policy decision signals that escalation is available, how it is bound to the original evaluation, and how the result returns for reevaluation.

AARM decides that an action should pause. This draft standardizes how that pause is expressed and resolved.

What the Draft Actually Does

The goal of the AuthZEN Access Request and Approval Profile is not to standardize workflow engines or approval systems. It standardizes the interoperability layer around authorization escalation.

Walk it through with the support agent from earlier. It is investigating the billing issue and tries to read the restricted payment-provider log. The PDP returns a bare denial:

1

{ "decision": false }

Nothing in that response separates “never” from “not yet.” The profile turns it into a requestable denial that states the reason, names the escalation endpoint, and binds the request to this exact evaluation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "decision": false,
  "context": {
    "evaluation_id": "eval_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "reason": "approval_required",
    "access_request": {
      "endpoint": "https://pdp.example.com/access/v1/requests",
      "template": "payment_log_access",
      "expires_in": 600,
      "request_context": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC0xIn0..."
    }
  }
}

The authorization system is no longer returning only “No.” It is returning “No, but governance escalation is available.”

The policy enforcement point (PEP) submits an access request to that endpoint, echoing evaluation_id and request_context so the request is tied back to the denial. It receives a Task Handle and polls until the task is terminal. When the engineer’s manager approves the scoped expansion, the result carries an approval reference such as apr_01J9F30RBX.

Then comes the step that matters. The PEP does not proceed on the strength of the approval. It issues a new AuthZEN evaluation for the same access, carrying the approval as an input:

1
2
3
4
5
6

{
  "subject":  { "type": "agent", "id": "support-agent-7" },
  "resource": { "type": "log", "id": "payment-provider/tenant-42" },
  "action":   { "name": "read" },
  "context":  { "approval": "apr_01J9F30RBX" }
}

The PDP reevaluates against current policy, current subject state, and current risk, and only then returns:

1

{ "decision": true }

If the mission had ended, the risk posture had shifted, or the approval had expired in the meantime, that same reevaluation returns false again. The approval bought a fresh decision, not a standing key.

The base profile defines exactly one completion mode: reevaluate. The PDP remains authoritative end to end. An approval is not an access grant, and it is not a capability token: it does not travel forward as bearer authority to be replayed later. It is an input that current policy can choose to honor or reject at the moment of access.

That is a deliberate defense against the time-of-check to time-of-use (TOCTOU) gap. The dominant failure in ticket-based access is exactly this gap: an approval granted at one moment becomes a standing entitlement still usable hours or days later, after the risk posture, the revocation state, or the mission that justified it has changed. Reevaluation forces the decision to be made again, against current state, every time the approval is presented. The obvious objection is cost. Reevaluation is another policy decision, but it runs once per escalation rather than once per request, on a PDP that is already in the path for the original deny. Paying for that fresh decision is the point.

That changes denial from a terminal state into a governable lifecycle transition without changing what a denial means.

This Is Not Workflow Standardization

One of the most important constraints of the draft is what it intentionally does not standardize. The draft does not define workflow engines, business process management (BPM) orchestration, approver routing, entitlement provisioning, governance policy languages, UI semantics, or human interaction models. Those remain implementation-specific.

What the draft standardizes is narrower:

• the shape of a requestable denial in an AuthZEN decision response
• how an access request is submitted, with denial binding and idempotency
• the Task Handle, lifecycle states, and polling semantics
• terminal-state completion semantics, including reevaluation against current policy

That separation matters. An enterprise may implement approvals using ServiceNow, SailPoint, Okta workflows, a custom governance system, a risk engine, an AI supervisor, a delegated approver, or a chain of policy evaluators. The interoperability problem exists independently of the workflow engine behind it.

The draft keeps catalog references outside the form schema so the schema remains a pure description of data shape. It also does not define a UI rendering vocabulary or an agent protocol surface. The handoff is the surface area. Everything else stays local.

Why CIBA Is Not the Solution

Whenever asynchronous approval flows come up, someone eventually asks, “Why not just use Client-Initiated Backchannel Authentication (CIBA)?”

At first glance, CIBA appears close. Asynchronous interaction. Delayed completion. Polling semantics. Out-of-band approval. But CIBA solves a fundamentally different problem.

CIBA is asynchronous authentication and consent for OAuth grant issuance. The successful terminal state is a token. The user proves they are present and consenting, and the authorization server issues a credential.

Authorization escalation governance is different. The modern problem is often not “authenticate the user again.” The harder problem is “should authority continue under newly discovered runtime conditions?”

In this situation the agent already holds valid tokens and operates under an approved mission. Re-running an authentication flow changes none of that. The missing input is governance state: whether authority should expand now that boundaries, delegation paths, or risk have shifted.

The draft intentionally avoids coupling approval directly to grant issuance. The lifecycle is:

1. authorization denied
2. escalation initiated against the denial binding
3. governance workflow executes
4. authorization context changes
5. authorization reevaluated under current policy

That distinction preserves continuous evaluation, revocation, runtime policy, dynamic governance, and mission-bound authority. Approval alone does not create durable authority. The authorization system remains authoritative at evaluation time. That keeps the policy engine in charge of the access decision rather than the workflow engine.

CIBA still has its place. When the missing input really is fresh user authentication or consent for a grant, CIBA is the right tool. When the missing input is governance state, it is not.

Sessions Are Not Missions, and Approvals Are Not Authority

An approval answers whether a governance event occurred. A mission answers whether that event still justifies authority right now. The reevaluation step in the draft keeps those two questions separate. The approval is an input to policy. Policy decides whether the input still holds.

This is the same shape as the argument in Sessions Are Not Missions. Modern agent runtimes increasingly support durable execution: resumable sessions, background jobs, distributed orchestration, asynchronous continuation, and sub-agent execution. Runtime durability is not governance durability. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working.

An agent may remain authenticated, maintain valid sessions, and preserve runtime continuity while still requiring governance escalation because new resources were discovered, stronger operations emerged, downstream delegation occurred, trust boundaries changed, or mission scope expanded. Authentication continuity is not governance continuity. An approval signed an hour ago is not a substitute for evaluating against current state.

This is also why the Task Handle in the draft is opaque and portable. It survives PEP restart and can be passed between systems. A long-running agent that gets denied, escalates, hands work off to a sub-agent, and resumes on a different node should not need to rebuild the request from scratch. The handle is a runtime artifact for tracking the escalation. The mission, the approval, and the reevaluated decision are the governance artifacts that decide whether work continues.

Authorization Escalation as a Runtime Primitive

The deeper pattern emerging across modern systems is this: authority increasingly outlives the moment that originally justified it.

A static authorization decision made at one point in time becomes insufficient once execution continues for hours or days, resources are discovered dynamically, delegation chains evolve, risk posture changes, organizational state changes, or mission scope expands.

This is the same gap From Passports to Power of Attorney names from the credential side and Governing the Stay, Not Just the Entry names from the control-plane side. The badge is not the work order. The token is not the mandate. The session is not the mission.

A standardized escalation handoff lets each of those layers stay honest. The PDP can say “deny, but escalate” without inventing its own approval API. The mandate service (Power of Attorney series) can be the system of record for whether the mission still holds. The workflow engine can remain the system of record for how an approval was reached. The agent runtime can carry a Task Handle without becoming the source of truth for authority.

What this layer needs to be:

• A protocol surface, not a workflow language. Approval routing, escalation policy, and approver selection stay implementation-specific.
• Policy-authoritative on completion. The PDP reevaluates against current state. An approval is an input, not a verdict.
• Lifecycle-explicit. Pending, approved, denied, expired, cancelled, failed, partial. Unknown states are not approval.
• Bindable to the denial. Either a verifiable evaluation identifier or a signed request context, never a floating approval against an unbound denial.
• Portable. Handles survive runtime churn and cross process boundaries, because the agents that need this most are the ones that do not stay on one node.

None of those properties are workflow features. They are interoperability properties.

What This Is Converging Toward

The traditional model:

1

{ "decision": false }

is becoming insufficient for agents, runtime delegation, dynamic resource discovery, mission expansion, and continuous governance.

The future increasingly looks more like:

1
2
3
4
5
6
7

{
  "decision": false,
  "context": {
    "reason": "approval_required",
    "access_request": { "endpoint": "...", "template": "..." }
  }
}

followed later by a reevaluation against the resulting approval. Current policy decides whether the approval still holds.

That is the direction this work is converging toward: not “access requests” as a workflow primitive, and not “approval flows” as a vendor feature, but a standardized interoperability layer for authorization escalation, runtime governance, and mission continuity.

The protocol surface is small on purpose. The hard work of deciding who approves what, under which policy, against which mission, with which evidence, stays exactly where it belongs: not in the authorization API, not in the workflow engine, but in the layer that owns mission authority.

This is a working group draft for a reason. The edges still need to be battle-tested. Whether you are building agent runtimes, high-throughput API gateways, or access-request and approval products, I want to know where this handoff breaks down. Join the conversation in the OpenID AuthZEN Working Group, or open an issue on GitHub.

Denial is no longer always the end of the interaction. It is becoming a state in a governable lifecycle. The protocol needs to recognize that, and only that. The rest of the stack can then stop reinventing it.