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 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, 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: start narrow, hit a requestable denial, request, approve, expand as a successor Mission, with Progressive Authorization (experimental) for ceiling-and-drawdown | Answered |
| No standardized interactive channel | A way to pause a task and ask the user mid-flight | Deferred Approval makes the approval asynchronous and pollable, ARAP carries the mid-task ask, action-bound approval 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, Child Missions with their own lifecycle and lineage, and 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 reaches the delegation tree, Mission Management carries enumerate-and-bulk-revoke with dry-run first, and the revocation matrix prices the latency | Answered |
| Group authorization | One grant for a coordinated group, members bound late, lifecycle atomic | A parent Mission with Child Missions: 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 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, 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 and the AI Agent Instance Profile’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 (experimental) for cumulative budgets and call caps | Answered |
| The OS permission bridge | Cloud-level intent connected to fine-grained local OS permissions | The harness 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 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 over consumer resources, and the category does not care that they are not enterprise. 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. The DNS maintenance agent is the standing agent again, cycling authority under a charter. Managed services across organizations are cross-domain projection. And automated incident response is Mission Management’s 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 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, 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 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 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 and the five laws 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.