Overview
The Mission is the durable, approval-backed record of the task (The Mission Is the Missing Abstraction), and the chapters before this one made the argument at every altitude: the intuition, the architecture, the wire, the outside framings. This concluding chapter zooms out to the framework those chapters realize, because the model does not depend on OAuth even though the profiles do. If you want the build order first, read Adopting Mission-Bound Authorization and come back. The maturity and status claims here are as of July 2026, and the Reference carries the reconciliation date the handbook tracks.
The framework OAuth carries
OAuth earned its place as the first substrate for one reason: it is where the deployments are. The Authorization Server already exists, the token machinery already works, and the agent identity stack the AI agent auth best practices describe is OAuth-shaped. But the object this handbook built is not an OAuth feature, and OAuth is no longer its only binding. The family now carries three: the OAuth core as the flagship, the standalone Mission Authority Server as a peer binding, and an AAuth binding that hosts AAuth’s native mission concept at its Person Server, with Substrate Requirements consolidating what any further binding must provide. The Architecture document states the model on its own terms, and it is the right front door for a newcomer who wants the whole shape before any wire detail.
The coarsest map of the layer is four functions, and they survive any substrate:
| Function | What it does | Spine stage | Where |
|---|---|---|---|
| Authority compilation | Turns approved intent into bounded, integrity-anchored authority | Intent, Mission | The Mission, practice approval integrity |
| Authority projection | Carries that authority onto instances, credentials, domains, and delegates without ever exceeding it | Authority | practice delegation |
| Authority containment | Checks every consequential action against the approved purpose at the point of use | Enforcement | practice runtime enforcement |
| Authority continuity | Keeps reliance conditioned on the current state of the task, across time and across the runtime | Lifecycle and runtime | practice lifecycle and agent runtime |
These names are built to survive the Mission. If a different object wins the standards conversation, the layer still needs compilation, projection, containment, and continuity, and this handbook is a complete worked example of all four.
The finer decomposition is a verb spine. Each verb answers one question, sits on one trust boundary, and is owned by named documents:
| Verb | The question | Owned by | Where |
|---|---|---|---|
| Propose | How does a request become a candidate Mission Intent? | Intent Shaping | Approval integrity |
| Approve and record | How does a proposal become a committed, integrity-anchored Mission? | The issuance core, Consent Evidence, Deferred Approval | The Mission, approval integrity |
| Govern | How is state observed, changed, widened, and retired? | Status (carrying completion), Signals, Expansion | Lifecycle |
| Enforce each action | Is this concrete action allowed under the current Mission? | Runtime contract, AuthZEN binding | Runtime enforcement |
| Run and wind down | Does the runtime stop when the Mission does, and what unwinds? | Harness, Orchestration | Agent runtime |
| Delegate | How does authority narrow across actors and instances? | The core’s act chain, Child Delegation, Offline Attenuation | Delegation |
| Project | How is one Mission honored in another trust domain? | Cross-Domain Projection | Delegation |
| Prove | What can a third party verify about what was approved and done? | Consent Evidence, Mandate, Audit Transparency | Approval integrity, agent runtime, and Part 2 |
| Analyze | What must be trusted, and what breaks when each component is compromised? | Security Model | The Reference’s adversary model |
The spine the architecture follows, Intent to Mission to Authority to Enforcement, is the temporal reading of the same map: what happens first when a request arrives. The verb spine is the structural reading: which component owns which question. Both readings survive a substrate change, which is the test of a framework rather than a feature.
Fundamental versus accidental
A sharper version of that test is to ask which of this handbook’s ideas survive if OAuth disappears. The answer is nearly all of them. The missing layer and its five laws. Authority compilation, projection, containment, and continuity. The approved task with an integrity-anchored record and a lifecycle. Approval evidence. Runtime containment at the point of use. Session continuity that is never authority. Those are architectural commitments, not OAuth features.
What is accidental is the realization: PAR as the submission channel, RAR as the Authority Set serialization, the mission claim’s name, the JWS envelopes, Security Event Tokens for signals, the AuthZEN wire shape. Any of those could be swapped without touching a law. The AAuth binding is the existence proof: the same object, laws, and lifecycle carried onto a non-OAuth substrate by swapping exactly those accidents, and the closing part carries what AAuth itself did with the object. That division is why the Architecture document states the model on its own terms and the bindings realize it, and it is the standard to hold any competing proposal to. An alternative that replaces the accidents is a realization. An alternative that drops a law is a gap.
Where the model sits operationally is the next part: The Authority Control Plane, the two chokepoints, the three bindings, and the structural mapping platform engineers reach for unprompted.