The least-privilege MCP series ends on a gap: token-side and resource-side authorization both work per call, and neither names the task the user approved. This essay applies Mission-Bound Authorization at the MCP boundary. The Mission is the durable approved task, tokens and PDP decisions are projections of it, tool discovery and invocation and approval line up against it, expansion routes through a fresh approval, and audit joins on one identifier. A denial is traced end to end to show the whole spine working.
Least privilege scopes what an agent may do, one tool call at a time. But a perfectly authorized agent can still be compromised by what it is allowed to see. Least exposure is the broader control: task-scoped minimal disclosure for prompt context, retrieved documents, tool schemas, secrets, business rules, approval context, memory, and downstream responses. Because the model is untrusted reasoning, every input is attack surface. A Mission should therefore bound both halves: the actions the agent may take and the working set it may reason over.
Authorization looks the way it does because each generation solved the question its era made urgent, and deferred one question that someone else was always carrying: what approved work is this, and is it still on? Purpose was not absent. A second stack of tickets, purchase orders, workflows, and approval systems held it locally, and people carried it between systems. UMA decoupled protected-resource access from synchronous resource-owner interaction, and workload identity made software actors attributable without making their credentials task-specific. What never became a standard cross-boundary object was the approved undertaking itself, with authority derived from it and a lifecycle independent of any credential. Usage control identified ongoing authorization two decades ago. Unattended work now removes the human carrier and makes shared task state an operational requirement. This is the history that makes the Mission a legible next step rather than an idea from nowhere.
A handbook that ends on its own argument has not concluded, it has just stopped. This chapter is the conclusion: what survives if OAuth disappears (nearly everything: the layer, the laws, the vocabulary, the object), where the layer sits operationally (the control plane for delegated authority, mapped concept by concept with the disciplines that keep the framing honest), and the judgment a reader deciding how hard to bet actually needs: AAuth’s adoption of the Mission concept as the outside evidence, weighed for what adoption proves, and the six wagers, each with its falsifier.
An architecture that only answers its own questions is untested. This chapter runs the handbook against five outside framings: Simon Willison’s lethal trifecta, the threat model that defines what makes agents dangerous. Patrick Parker’s Seven Laws of AIdentity, mapped law by law with coverage and caveats stated rather than claimed whole. OWASP’s agentic threat taxonomy and LLM Top 10, where every threat gets a verdict of contained, bounded, or delegated. The governance frameworks, NIST AI RMF, the EU AI Act, and ISO/IEC 42001, whose show-me demands the enforcement artifacts answer as a by-product. And the OAuth community’s agent authorization gap catalog, its gaps answered line by line with the machinery that existed before the catalog was published. Each post names what the handbook answers with existing machinery, and what it honestly does not.
Designing Mission-Bound Authorization establishes the architecture: the object, the laws, the framework, and the staged adoption path. This chapter is the build. Five parts carry the five controls at implementation depth: the approval that creates a Mission, the authority that binds it to agent instances and delegates, the per-action enforcement that polices it, the lifecycle that governs it over time, and the runtime and audit story that make it survive a real agent. The wire appendix shows the actual bytes, and the MCP application post applies the model at the tool boundary.
The AI agent auth best-practices draft names the Mission and declares its translation into authorization out of scope. This chapter is that translation, at architecture depth: the problem in one screen, the vocabulary, the missing layer, the five laws, the reference security architecture, and the canonical picture. Part 1 is the joint between the card model and the protocol. Part 2 defines the Mission. Part 3 stages the adoption: crawl, walk, run. The Field Reference rides alongside as the appendix, and the concluding chapter weighs the model beyond its bindings.
Enterprises already run a mature delegated-authority architecture. It is called expense governance, and payments spent fifty years hardening it: purpose-issued instruments, approvals bound to what the approver was shown, delegation that only narrows, a network that authorizes every transaction, and cancellations, disputes, and statements that close the loop. This chapter walks that world one control at a time and maps each onto what AI agents are missing, honestly, breaks included.
Re-subjecting across a SaaS boundary is a mint, not an attenuation, so the IdP must issue each onward grant. ID-JAG covers the first hop, where an application holds the user’s ID Token or SAML assertion to exchange. Subsequent hops hold no end-user credential, which leaves a gap: the intermediate has nothing to present to the IdP to continue the chain. The Identity Continuation Assertion fills it. It is a short-lived, sender-constrained JWT, issued by a Chain Authority the IdP trusts, that carries opaque evidence of the in-flight delegation and is presented as the Token Exchange subject token to request an onward ID-JAG. It is evidence, not authority: it carries no subject and grants no access, the IdP resolves the target audience’s subject and re-decides at every hop, and the continuation handle never reaches a Resource Server.
Identity Assertion Trust Framework and Domain-Authorized Issuer Trust Method
Self-service agent sign-up exposes a first-contact trust problem: a Resource Authorization Server can verify a perfectly valid JWT and still not know whether the issuer is allowed to assert identities for the user’s domain. That is two questions, not one. Federation proves the issuer is authentic, but not that the namespace owner authorized it, and static allowlists do not scale to onboarding unknown domains at runtime. The Identity Assertion Trust Framework lets a Resource AS publish the evidence it requires. The Domain-Authorized Issuer Trust Method lets a domain owner publish which issuers may assert identities in its namespace, fail-closed, the way mail and the web already pushed authority into DNS. Both compose with ID-JAG and the JWT-bearer grant without changing the grant surface.