--- title: "The Authority Control Plane" date: "2026-07-10T19:10:00-07:00" lastmod: "2026-07-10T19:10:00-07:00" description: "Part 2 of the handbook's concluding chapter: the layer's operational position. Two enforcement chokepoints that are strictly stronger together, the pattern space of bindings from the standalone Mission Authority Server to the portable Mandate, and the structural mapping that makes the layer the control plane for delegated authority, with the three disciplines that keep the framing honest." summary: "Issuance gating and runtime enforcement are two independent chokepoints, strictly stronger together: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer. The Mission Authority Server, the issuance grant, the Mandate, and Cross-Domain Projection extend the pattern space. And the structural reading platform engineers reach for unprompted: the layer is the control plane for delegated authority, mapped concept by concept from desired state to the fleet API, with the disciplines that keep the framing honest." slug: "the-authority-control-plane" tags: - "OAuth" - "Authorization" - "Agentic Identity" - "Mission-Bound Authorization" - "AuthZEN" - "Internet-Draft" series: - "weighing-mission-bound-authorization" --- {{< tldr >}} - **Two chokepoints.** Issuance gating at the token layer and runtime enforcement at the action layer are strictly stronger together: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer. - **The pattern space.** The standalone [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) trades the token-layer chokepoint for zero AS change, the [issuance grant](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html) restores it, and the [Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html) is portable evidence, never a credential. - **The control plane.** The layer is the [control plane for delegated authority](#the-authority-control-plane): the Mission is desired state, tokens, PEPs, and PDPs are the data plane, and the mapping runs concept by concept from the store to the fleet API, with three disciplines that keep the framing honest. - **Specs (editor's copies).** [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html), [Mission Issuance Grant](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html), [Mission Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html), [Mission Cross-Domain Projection](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-cross-domain.html). **Where this sits.** Part 2 of [the concluding chapter](/series/weighing-mission-bound-authorization/). [What Survives Without OAuth](/notes/what-survives-without-oauth/) states the model this part deploys, and [The Convergence and the Wagers](/notes/the-convergence-and-the-wagers/) closes the handbook. **Reading path.** ~6 minutes start to finish, or jump to [the mapping table](#the-authority-control-plane) for the control-plane reading at a glance. {{< /tldr >}} The model survives without OAuth, and this part is where it sits when OAuth is exactly what you have: the two chokepoints the binding stacks, the pattern space of bindings between them, and the structural reading platform engineers reach for unprompted. # Two chokepoints, and the patterns they allow The OAuth binding stacks two independent chokepoints, and the [Architecture's deployment patterns](https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html#deployment) are combinations of them. **Issuance gating** acts at the token layer. A revoked or expired Mission stops all further derivation and refresh, and short-lived tokens age out. **Runtime enforcement** acts at the action layer. Each consequential action is re-checked against current state at the point of use. Together they are strictly stronger than either alone: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer. This split is also the layer's control-plane contract, mapped in full in [the authority control plane](#the-authority-control-plane) below. Two newer documents extend the pattern space: - **The [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html)** (Standards Track: the estate control plane of the layer, and its PDP join is the family's newest mechanism) is the standalone binding. A dedicated service implements the Mission Issuer role, derives no tokens, and the PDP joins each ordinary OAuth token to its Mission at the point of use. It serves the Status and lifecycle surfaces itself and is the deployment's freshness source, and expansion and Child Mission creation ride its own submission surface with an authenticated-client binding in place of token possession. It is a peer binding with its own rationale (governance deliberately decoupled from token issuance, and one Mission Issuer can govern across many Authorization Servers) that also serves as the adoption bridge where the AS cannot yet change. The trade is explicit: Mission governance and per-action enforcement with zero AS change, at the cost of the token-layer chokepoint. Revoking a Mission in this mode stops nothing at the token layer, so enforcement rests entirely on PEP coverage, until estate Authorization Servers adopt the [issuance grant](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html) and redeem MAS-minted grants for Mission-bound, state-gated tokens, restoring the token-layer chokepoint without moving approval into the AS. - **The [Mission Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html)** (an advanced profile: its dependencies are ratified, and it is design to adopt when the cross-domain proof case arrives) answers that proof question. A Mission's committed facts live on the record at its issuer, and a party outside that domain cannot verify what was approved short of a token-exchange hop or trust in the issuer's records. The Mandate is a signed, portable, independently verifiable statement of those facts, minted by the Mission Issuer, with optional selective disclosure. The design line is the one this handbook has drawn everywhere: a Mandate is evidence, not a credential. Presenting one authorizes nothing. The two bindings, side by side. The embedded binding holds both chokepoints. The standalone binding trades the token-layer chokepoint for zero AS change, and the issuance grant is the join that restores it: ```mermaid flowchart TB subgraph EMB["Embedded binding: the AS is the Mission Issuer"] direction LR M1[("Mission record")] AS1["Authorization Server
(Mission Issuer)"] AG1([Agent]) PEP1["PEP + PDP:
the action-layer chokepoint"] AS1 --- M1 AS1 -->|"mission-bound, state-gated tokens:
the token-layer chokepoint"| AG1 AG1 -->|per action| PEP1 M1 -.->|current state| PEP1 end subgraph STA["Standalone binding: the Mission Authority Server"] direction LR M2[("Mission record")] MAS["Mission Authority Server:
approval, lifecycle, Status"] AS2["Estate Authorization Servers,
unchanged, one or many"] AG2([Agent]) PEP2["PEP + PDP:
the action-layer chokepoint"] MAS --- M2 AS2 -->|"ordinary tokens:
no token-layer chokepoint"| AG2 AG2 -->|per action| PEP2 PEP2 -.->|"joins each token to its Mission
at the point of use"| M2 MAS -.->|"issuance grant: MAS-minted grants
redeemed for Mission-bound,
state-gated tokens"| AS2 end ``` The third extension of the pattern space is [Mission Cross-Domain Projection](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-cross-domain.html), one Mission honored in another trust domain through a single-hop, audience-scoped cross-domain grant. [Mission-Bound Authority](/notes/mission-bound-authority/#crossing-authorization-domains) covers it in full, because the multi-domain agent task is the common case, not the exotic one. It sits with the advanced profiles rather than in the protocol MVP, with its dependencies tracked honestly: the identity-chaining work it profiles is approved and in the RFC Editor queue, and ID-JAG is a working-group document. # The authority control plane {#the-authority-control-plane} One more reading of the framework earns its place, because platform engineers reach for it unprompted: the layer is the **control plane for delegated authority**, with the split that vocabulary always implies. The [architecture chapter](/series/designing-mission-bound-authorization/#the-control-plane-for-delegated-authority) makes the strategic case, and the mapping here is structural, not rhetorical: | Control-plane concept | The layer's realization | | --- | --- | | Desired state | The Mission: the approved task, its authority, its lifecycle and expiry | | The store | The Mission Issuer's records and integrity anchors | | Reconcilers | Lifecycle and gating, the ceiling review, orphaned-evidence reconciliation | | Distributed configuration | Audience-scoped, versioned policy views the PDPs load | | The data plane | Tokens, PEPs, and PDPs, enforcing per action at the boundary | | The sync channel | Mission Status as the pull surface, Signals as the push complement | | Optimistic concurrency | The state version, with compare-and-set on lifecycle mutations | | Object metadata | The management profile's owner, administrative domain, and labels | | The fleet API | Enumeration and bulk lifecycle | | Observability | Decision, execution, and consent evidence, joined on the Mission | The estate view of the same mapping: desired state above, per-action enforcement below, the sync channel between them, and the evidence joining back on the Mission: ```mermaid flowchart TB AG([Agent]) subgraph CP["Control plane: the Mission Issuer"] REC["Reconcilers:
lifecycle and gating,
the ceiling review"] M[("Desired state:
the Mission record
and its integrity anchors")] FLEET["Fleet API:
enumeration,
bulk lifecycle"] REC --> M FLEET --> M end subgraph DP["Data plane: enforcing per action at the boundary"] TK["Tokens:
state-gated issuance,
the token-layer chokepoint"] PEP["PEP:
the action-layer chokepoint"] PDP[PDP] end OBS["Observability:
decision, execution, and consent evidence,
joined on the Mission"] M -->|state-gated issuance| TK M -->|"the sync channel:
Status pull, Signals push,
audience-scoped policy views"| PDP TK --> AG AG -->|action + parameters| PEP PEP -->|evaluate| PDP PDP -->|permit / deny| PEP M -.->|consent evidence| OBS PDP -.->|decision evidence| OBS PEP -.->|execution evidence| OBS ``` Three disciplines keep the framing honest. The noun is scoped: this is the control plane *for delegated authority*, never an agent control plane, because it governs what an agent may do and never how the agent runs (the harness and the orchestrator keep operations). The category is unchanged: mission-based authorization remains the claim and the [six-property litmus](/notes/mission-based-authorization-field-reference/#what-counts-the-litmus-test) remains its gate, and control plane names where the layer sits operationally, not a new name for the layer. And a control plane is only as real as its data-plane contract, which is why the enforcement adapter contract, the deployment manifest, and the evidence envelope carry the interoperability weight on [the list the community still has to standardize](/notes/adopting-mission-bound-authorization/#what-the-community-still-has-to-standardize). The model is stated, and its operational seat is named. What remains is judgment: the outside evidence for the shape, and the bets underneath it. [The Convergence and the Wagers](/notes/the-convergence-and-the-wagers/) closes the handbook with both.