---
title: "Closing the Agent Authorization Gaps"
date: "2026-07-10T23:00:00-07:00"
lastmod: "2026-07-10T23:00:00-07:00"
description: "An individual Internet-Draft in the OAuth working group's orbit catalogs nine agent use cases and ten gaps in OAuth 2.0, from the pre-approval paradigm mismatch to task-level revocation. This part runs Mission-Bound Authorization against all ten: seven answered with named machinery, two partial with the nuance stated, one largely delegated."
summary: "The standards community is converging on a problem statement: agents break OAuth\u0026rsquo;s pre-approval paradigm, tokens cannot represent delegation chains, revocation cannot reach a task, and consent screens cannot survive a thousand scopes. The agent authorization use-case catalog names nine scenarios and ten gaps, and this part answers the catalog line by line with machinery that existed before it was published: task-level revocation is the Mission kill switch, bulk revocation is Mission Management, multi-hop chains are act chains and Child Missions, scope explosion dies at Mission-grain consent, and the paradigm mismatch is the discovery loop. Two answers are partial and one is delegated, and the tally is stated rather than smoothed."
slug: "closing-the-agent-authorization-gaps"
tags:
  - "Agentic Identity"
  - "Authorization"
  - "Mission-Bound Authorization"
  - "OAuth"
  - "Internet-Draft"
series:
  - "proving-mission-bound-authorization"
---


{{< tldr >}}

- **The framing.** [Agent Authorization Use Cases and Gap Analysis](https://datatracker.ietf.org/doc/draft-chen-oauth-agent-authz-use-cases/), an individual Internet-Draft by authors from China Mobile, CNNIC, and Huawei: nine agent use cases from the personal assistant to automated incident response, and ten named gaps in OAuth 2.0. It is the closest thing the standards conversation has to an agreed problem statement.
- **The claim.** The family answers the catalog line by line, with machinery that existed before the catalog was published: seven gaps answered with named drafts, two partial with the nuance stated, one largely delegated. The convergence is the point, because a problem statement and a solution proposal written independently should meet if the missing layer is real.
- **What lives in this part.** [The ten gaps in one table](#the-ten-gaps-answered), [the nine use cases in one paragraph](#the-nine-use-cases), [three gaps worth a closer look](#three-gaps-worth-a-closer-look), and [the honest remainders](#the-honest-remainders).
- **The laws.** [All five](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority): the catalog's gaps are the laws experienced as missing machinery, gap by gap.
- **Specs (editor's copies).** [Mission Management](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-management.html), [Child Delegation](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-child-delegation.html), [Deferred Approval](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval.html), and the [AuthZEN profile](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authzen.html).

**Reading path.** ~10 minutes in order, or jump to [the table](#the-ten-gaps-answered) for every verdict at a glance.

{{< /tldr >}}

# Overview

The first four proofs held the model against a threat model, a
requirements framework, a threat taxonomy, and the governance
frameworks. This one holds it against the framing that matters most
for the venue conversation: the standards community's own problem
statement.
[Agent Authorization Use Cases and Gap Analysis](https://datatracker.ietf.org/doc/draft-chen-oauth-agent-authz-use-cases/)
is an active individual draft in the OAuth working group's orbit,
written by authors from China Mobile, CNNIC, and Huawei. It catalogs
nine agent scenarios, performs a gap analysis against OAuth 2.0 and
its common extensions, and derives the requirements the gaps imply.
It proposes no solution, which is exactly what makes it the right
test: a catalog of what is missing, written without this family in
mind.

The verdicts here are simpler than the
[OWASP post's](/notes/containing-the-owasp-agentic-threats/), because
gaps are not threats. **Answered** means the gap lands on named
machinery with a draft behind it, maturity labeled. **Partial** means
the machinery covers most of the ask and the remainder is stated.
**Delegated** means the gap belongs to a layer the family composes
with rather than supplies. And one caution rides along, the same one
the whole chapter carries: the catalog is outside, the mapping is
ours, and every row cites the machinery so the reading can be re-run.

# The ten gaps, answered

| The gap | What it asks for | The family's answer | Verdict |
| --- | --- | --- | --- |
| Pre-approval versus dynamic authorization | Permissions granted just-in-time as tasks emerge, not all upfront | The admission model plus the [discovery loop](/notes/adopting-mission-bound-authorization/#composing-with-the-ecosystem): start narrow, hit a requestable denial, request, approve, expand as a [successor Mission](/notes/mission-lifecycle-and-change/#grow-expansion-creates-a-successor), with [Progressive Authorization](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-progressive.html) (experimental) for ceiling-and-drawdown | Answered |
| No standardized interactive channel | A way to pause a task and ask the user mid-flight | [Deferred Approval](/notes/from-a-request-to-an-approved-mission/) makes the approval asynchronous and pollable, ARAP carries the mid-task ask, [action-bound approval](/notes/mission-bound-runtime-enforcement/#the-high-assurance-level) puts a human on the highest classes, and `suspended` is the pause | Answered |
| Multi-hop delegation chains | Tokens that represent User to Agent A to Agent B verifiably | The RFC 8693 `act` chain via the [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/), [Child Missions](/notes/mission-bound-authority/) with their own lifecycle and lineage, and [offline attenuation](/notes/mission-bound-authority/#mechanism-2-offline-attenuation) whose chains prove their own narrowing | Answered |
| Task-level and bulk revocation | Revoke one task without touching others, and everything at once in an incident | The bullseye: revocation by `mission_id` *is* task-level revocation, [cascade](/notes/mission-bound-authority/) reaches the delegation tree, [Mission Management](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-management.html) carries enumerate-and-bulk-revoke with dry-run first, and the [revocation matrix](/notes/mission-based-authorization-field-reference/#when-revocation-bites) prices the latency | Answered |
| Group authorization | One grant for a coordinated group, members bound late, lifecycle atomic | A parent Mission with [Child Missions](/notes/mission-bound-authority/#mechanism-1-the-child-mission): members bind late under the parent grant, fan-out is bounded explicitly, and cascade makes the group's ending atomic. What the family deliberately does not define is a group-native grant where members share one identity, because per-member attribution is Law 2 | Partial |
| Scope explosion | Consent that survives a thousand granular scopes | Consent moves to task grain: the approver consents to one Mission's derived authority, rendered legibly, instead of a thousand scopes, and the [fatigue budget](/notes/from-a-request-to-an-approved-mission/#the-fatigue-budget) is managed rather than wished away | Answered |
| Conditional policy enforcement | Conditions like time windows expressed and enforced, not custom-coded | Per-entry `constraints` evaluated on every action by the PDP through the [AuthZEN binding](/notes/mission-bound-runtime-enforcement/), with an unknown constraint refusing rather than passing, and resource policy staying authoritative | Answered |
| Agent-user differentiation | A standard way to know an agent is calling, not a human | The identity substrate the family composes with: the [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) and the [AI Agent Instance Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/)'s attested instance identity and provenance, with the `mission` claim adding what the agent is acting *for* | Answered |
| Constraint expression | Rate limits, data caps, and time bounds, not binary scopes | Structured `constraints` that only tighten, expiry capped by the Mission's clock, and [Consumption Metering](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-metering.html) (experimental) for cumulative budgets and call caps | Answered |
| The OS permission bridge | Cloud-level intent connected to fine-grained local OS permissions | The [harness](/notes/the-agent-runtime-and-audit/) is the PEP for the local paths no gateway sees (files, shell, spawn, resume), which is the slice the family supplies. Bridging Missions into OS-native permission systems is a substrate nobody has built | Delegated |

Seven answered, two partial or delegated with the remainder stated,
and none waved away. The striking thing about the tally is the
direction of fit: the catalog was written as a problem statement with
no solution in mind, and its requirement list reads like this family's
table of contents. The [bridge post](/notes/from-the-card-to-the-architecture/)
made the same observation about the card chapter's build lists. Two
independent catalogs of what is missing, one from expense governance
and one from the standards community, keep enumerating the same
architecture.

# The nine use cases

The catalog's scenarios each land on a named pattern rather than a
new one. The personal assistant and the smart home are Missions with
[standing charters](/notes/mission-lifecycle-and-change/#the-standing-agent-at-scale)
over consumer resources, and the
[category does not care that they are not enterprise](/notes/mission-based-authorization-field-reference/#mission-based-authorization-as-a-category).
The third-party SaaS proxy is the issuance core's home game. The OS
resources case is the harness's local-PEP slice, with the honest
remainder in the table above. Business process automation and the
coordinated task group are a parent Mission fanning out through
[Child Missions](/notes/mission-bound-authority/). The DNS
maintenance agent is the standing agent again, cycling authority under
a charter. Managed services across organizations are
[cross-domain projection](/notes/mission-bound-authority/#crossing-authorization-domains).
And automated incident response is
[Mission Management's](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-management.html)
reason to exist: enumerate a compromised principal's active Missions
and bulk-revoke, dry-run first, with the kill switch reaching
issuance, permits, harnesses, and sub-agents.

# Three gaps worth a closer look

**Task-level revocation is the gap the Mission was born for.** The
catalog calls the lack of it "a major operational and security failure
point," and the diagnosis is exact: OAuth can revoke a token, and a
task is not a token. Revoking a task today means finding every token,
cached connection, and sub-agent that serves it, which is the
archaeology the handbook's whole first chapter dramatizes. The family's
answer is the object itself: the task has an identifier, revocation
targets it, and every projection (tokens, permits, sessions, children)
dies with it within a published bound. Where the catalog asks for an
API, the family answers with an object, because task-level revocation
is only coherent if the task exists.

**The paradigm mismatch is the admission model, seen from the other
side.** The catalog's first gap says agents need a "continuous
dialogue" of just-in-time permissions rather than upfront grants, and
read carelessly, that sounds like the runtime intent inference this
handbook rejects. Read carefully, it is the
[discovery loop](/notes/adopting-mission-bound-authorization/#composing-with-the-ecosystem)
specified as a requirement: start narrow, discover the need, ask
through a governed channel, and land the widening as a fresh
approval. The dialogue the catalog wants is real, and every turn of it
is an admission decision, never the agent granting itself scope
mid-flight. The difference between those two readings is the
difference between the category and a loophole.

**Scope explosion is a consent-grain problem, not a scope-count
problem.** The catalog's smart-home scenario generates thousands of
per-device scopes and an unusable consent screen, and the instinct is
to fix the screen. The family's answer moves the grain instead: the
human approves one Mission whose Authority Set the issuer derives, and
the thousand fine-grained entries live inside the derivation, rendered
as a legible disclosure rather than a scope list. The consent screen
failed because it asked a human to compile authority by hand. The
approval event succeeds because the compilation is the
[issuer's job](/notes/from-a-request-to-an-approved-mission/), and the human
judges the result.

# The honest remainders

- **The group grant is deliberately not native.** A coordinated group
  in this family is a parent and its children, each attributable,
  because collapsing members into one shared grant identity would
  trade Law 2 for convenience. A deployment that truly needs
  group-shared identity is asking for the thing the
  [contractor post](/notes/the-contractor-gets-their-own-card/) warns
  about, at fleet scale.
- **The OS bridge is real and unbuilt.** The harness mediates local
  side effects, and nothing in the family translates a Mission into
  OS-native entitlements or sandbox profiles. That is a substrate the
  ecosystem has not standardized, and the family composes with
  whatever emerges rather than pretending to supply it.
- **The catalog and the family are both individual drafts.** The
  convergence argues that the problem statement and this solution
  shape belong in the same venue conversation. It does not make either
  one a standard, and the
  [family's own maturity labels](/notes/mission-based-authorization-field-reference/#the-draft-family-at-a-glance)
  say which answers are stable design and which are experimental.

The close is the same one every proof in this chapter reaches from a
different direction. The catalog asks what OAuth cannot say about an
agent's work: what it is, who approved it, whether it still stands,
and how to end it everywhere at once. Those are the
[six questions](/notes/mission-based-authorization-vendor-test/) and
the [five laws](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority)
in requirements clothing, and the fact that the standards community's
own gap analysis keeps arriving there is the strongest evidence yet
that the missing layer is not one proposal's opinion.