This is the blueprint of the publication’s fast path: what to build, where it lands, and what to skip, on one page. The essay makes the case, the vendor test evaluates claims, and Adopting Mission-Bound Authorization carries the full staged path and the reasoning behind every line here.
The minimum useful deployment is four pieces, and every normative dependency is a ratified OAuth RFC or a finalized OpenID specification:
Protocol MVP = issuance core + runtime enforcement + AuthZEN binding + Status (the state freshness source)
One honesty clause governs the whole page: a mission-bound token without runtime enforcement is governance metadata, not agent safety. The issuance core alone is the crawl stage, not a place to live.
The first design decision is not which extension to adopt. It is the enforcement scope: which resources, action classes, and execution paths you can actually mediate. A deployment that cannot prevent an action on a path must not claim runtime enforcement for that path.
Deploy this minimal shape:
| The minimal enforced deployment | |
|---|---|
| 1 | The Mission Issuer records the approved task |
| 2 | Tokens carry the mission id and authority hash |
| 3 | A PEP gates each consequential action |
| 4 | The PDP checks action, parameters, actor, and current Mission state |
| 5 | Status (or issuer introspection) provides fail-closed freshness |
| 6 | Evidence joins on the mission id |
These are six deployment surfaces, not six laws. They are how the five laws become checkable in production: a durable object, derived authority, bound credentials and decisions, runtime containment, lifecycle freshness, and attributable evidence.
This is deliberately small. It does not prove every side channel is mediated, does not make the agent’s reasoning trustworthy, does not unwind completed actions, and does not give cross-domain proof by itself. Those are governed-agent and advanced controls. The wedge only does the thing the category cannot skip: it makes the approved task an object and checks consequential action against current state.
The same recipe lands at four different boundaries, and only the deployment details change:
| Where it lands | What changes | What carries the enforcement |
|---|---|---|
| An Authorization Server you can extend | The AS is the Mission Issuer and gates issuance on Mission state | Issuance gating plus the PEP fleet |
| An Authorization Server you cannot change | A standalone Mission Authority Server records and governs the Mission, and tokens stay ordinary | PEP coverage entirely, with the PDP joining each token to its Mission at the point of use |
| An MCP server | The tools/call handler is the PEP, and the AuthZEN check runs per call | The tool boundary you already own (the MCP application post) |
| The agent harness | The harness mediates local side effects and gates every resume on Mission state | The harness as the PEP for the paths no gateway sees |
The PEP has to sit at the last controllable boundary before the effect. An orchestrator check does not replace a resource PEP for a resource the agent can reach directly, and an API gateway does not cover local shell, browser, or file-system effects it never sees.
For AI agents, add Consent Evidence and the harness profile next, because an agent’s approval surface and its resume path are where the guarantees otherwise lapse.
Do not build first: Signals, Deferred Approval and Revision, the Mandate, offline attenuation, cross-domain projection, SCITT audit transparency, or the standalone Mission Authority Server unless your Authorization Server truly cannot change. Every one of them is on the roadmap for a reason, and none of them is the wedge. Build the recipe above, run it, and let deployment experience tell you which advanced control the use case actually forces.
The acceptance test is the publication’s running example, run against your own deployment. Revoke a Mission and watch the next consequential action fail closed within your published freshness bound. Then pull the mission id and reconstruct the whole story: the approval, the derived authority, the decisions including denials, and the revocation. If both work, the wedge is real.
When it ships, claim it honestly, and name what is excluded:
| Claim line | Example |
|---|---|
| Claim | Protocol MVP (enforced agent) |
| Scope | Finance, docs, and workflow APIs |
| Enforcement | PEP at MCP tools/call and at the resource APIs |
| Freshness | Mission Status within 30 seconds |
| Evidence | Decision Evidence for all consequential calls, denials included |
| Exclusions | No runtime-enforcement claim for direct shell egress |
The depth is one link away. Adopting Mission-Bound Authorization stages the whole path (crawl, walk, run) with the adoption ladder, the bundles, and the roadmap. The Building Mission-Bound Authorization series carries each control at wire depth. The wire appendix shows the running example as bytes, and the Reference’s implementation checklist turns the claim into something checkable.