---
title: "Minimum Viable Mission-Based Authorization"
date: "2026-06-07T09:30:00-07:00"
lastmod: "2026-06-07T09:30:00-07:00"
description: "The practical adoption blueprint for the public canon: the four-piece protocol MVP, the six-step enforced deployment, the enforcement-scope decision, where it lands at common boundaries, what not to build first, and the honest claim to write when it ships."
summary: "The blueprint of the publication\u0026rsquo;s fast path. Start with the protocol MVP: issuance core, runtime enforcement, AuthZEN binding, and Status freshness. Name the enforcement scope, deploy the six-step minimal shape, place PEPs at the boundaries you actually control, skip advanced profiles until the wedge is running, and publish an honest claim with exclusions. The reasoning lives in Adopting Mission-Bound Authorization, the controls live in the Building series, and the bytes live in the wire appendix."
slug: "minimum-viable-mission-based-authorization"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "AuthZEN"
---


> 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](/notes/agents-need-a-mission-not-just-credentials/) makes the
> case, the
> [vendor test](/notes/mission-based-authorization-vendor-test/)
> evaluates claims, and
> [Adopting Mission-Bound Authorization](/notes/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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) 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](/notes/least-privilege-mcp-tool-calls-need-a-mission/)) |
| 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](/notes/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](/series/building-mission-bound-authorization/)
carries each control at wire depth. The
[wire appendix](/notes/mission-bound-authorization-on-the-wire/) shows
the running example as bytes, and the
[Reference's implementation checklist](/notes/mission-bound-authorization-reference/#the-implementation-checklist)
turns the claim into something checkable.