This is the standing reference for the Mission-Bound Authorization series. It is written to be linked, quoted, and shared. The parts carry the argument. This page carries the definition, the litmus test, the landscape, and the vocabulary. The top of the page is the citation kit: the definition, the terminology, the five laws, the layer vocabulary, the protocol MVP formula, the honest deployment claim, the what-not-to-claim list, and the canonical picture, each written to be copied whole, with Mission-Bound Authorization on the Wire as the companion exhibits. The litmus test and everything deeper follow. This page tracks the draft family’s editor’s copies as of July 6, 2026.

Mission-based authorization in brief

Mission-based authorization governs the approved task, not just the credential, session, or individual request.

It is a category, not one product. Mission-Bound Authorization for OAuth 2.0, the draft family this series explains, is one concrete instance of it.

The vocabulary has a strict hierarchy:

A mission-based authorization system has a durable approved task object, derives authority from it, checks consequential actions against it, and binds audit evidence back to it.

Why existing objects are not enough: a token authorizes a request, a session preserves runtime continuity, a scope names requested authority, a task/trace ID correlates activity. None of them is the approved task with a lifecycle that authority is derived from and gated on. That object is the Mission.

The triad that makes it work:

Tokens carry authority. Missions govern purpose. PDPs enforce actions.

And the hard truth that keeps it honest:

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

The bottom line

Mission-based authorization is the missing layer between user intent and per-request authorization. It makes the approved task a first-class governance object, then binds tokens, runtime decisions, delegation, lifecycle, and audit back to that object.

And the positioning line, for the slide:

Identity says who. Credentials say what may be accessed. The Mission says what the work is, who approved it, and when it ends.

The five laws of delegated authority

The layer’s invariants, stated to be quoted. They hold on any substrate, and the series is an enforcement mechanism for all five.

1. Durability. Authority must outlive credentials.
2. Attribution. Every action must remain attributable, and the approval record commits exactly what the approver was shown.
3. Narrowing. Authority can only narrow as work fans out.
4. Termination. Revocation must end authority, not merely tokens.
5. Containment. Execution must continuously remain inside approved purpose.

The names are stable across the publication: Durability is always Law 1, Containment is always Law 5.

The layer vocabulary

Four functions any implementation of the layer must supply, whatever it names its governance object:

• Authority compilation: approved intent becomes bounded, integrity-anchored authority.
• Authority projection: that authority reaches instances, credentials, domains, and delegates without ever exceeding its source.
• Authority containment: every consequential action is checked against the approved purpose at the point of use.
• Authority continuity: reliance stays conditioned on the current state of the task, across time and across the runtime.

The protocol MVP formula

Protocol MVP = issuance core + runtime enforcement + AuthZEN binding + Status (the state freshness source)

Every dependency in the formula is a ratified OAuth RFC or a finalized OpenID specification, with one tracked exception scoped out of the wedge: the issuance core’s single Internet-Draft reference, the Actor Profile, is confined to its OPTIONAL delegation capability. Lifecycle Signals, the experimental push complement, sits outside the formula. The series hub carries the adoption-wedge argument, and Adopting Mission-Bound Authorization carries the staged build order.

The honest deployment claim

A conformance claim names its tier and its enforcement scope, and every line can be verified against the implementation checklist below:

What not to claim

The negative space of the claim, stated to be quoted:

• A mission-bound token alone is not agent safety. It is governance metadata until a PEP checks each consequential action against it.
• Status without PEP coverage is not runtime enforcement. Freshness feeds a gate. It does not replace one.
• Signals without a fail-closed state source is not revocation safety. A missed event must read as stale state, never as still active.
• Harness logs without mediated execution paths are not containment. A record of the resume is not a boundary on it.
• Audit transparency is evidence, not prevention. It makes a false record permanent and attributable. It stops nothing.

The vendor test

The test is its own page, built to be linked and pasted into an evaluation: The Mission-Based Authorization Vendor Test. Six questions, the litmus property each one probes, and what failing answers sound like. A vendor that passes all six should be able to write the honest deployment claim above, and the implementation checklist is how you verify it.

The canonical picture

One diagram for the whole model: the six stages, and the actors that own each.

Everything below is the detail behind the bottom line: what qualifies as mission-based (litmus), how it differs from what you already run (landscape), the smallest useful deployment (stages), the checkable claim (checklist), what it does not solve (non-goals), the glossary, and one worked example.

Mission-based authorization as a category

The field has converged on the same gap from several directions: agent IAM, intent-based access control, capability systems, the lethal trifecta. The shared answer is to elevate the approved task to a first-class object. That move is the category. A system is in the category whether it calls the object a Mission, a mandate, or a governed task, and whether it rides on OAuth, on a clean-slate agent protocol, or on something else.

This series is about one instance: Mission-Bound Authorization for OAuth 2.0, where the object is the Mission, authority is derived as Rich Authorization Requests, the binding is a mission token claim, and enforcement uses a PEP/PDP contract. Where this page says “mission-based,” it means the category. Where it says “the Mission” or names a draft, it means this instance.

The category does not depend on OAuth. OAuth is the substrate used here because it is the dominant deployment reality, and it already supplies the derivation, exchange, sender-constraint, and revocation machinery a Mission binds to. The family itself now demonstrates the independence: the AAuth binding hosts the same governance object at the AAuth Person Server, and Mission Substrate Requirements consolidates what any further binding must provide. The reference model is the six properties. OAuth is the flagship binding of it.

Mission-based authorization and IBAC

Intent-Based Access Control (IBAC) is the property: authorize by what the user approved, not by what an agent infers at runtime. Mission- based authorization is the mechanism that makes IBAC practical, by moving interpretation to consent time, where the user is present, and committing the result so enforcement consumes approved intent instead of reconstructing it. IBAC is the property. The Mission is the object that carries it.

What counts: the litmus test

A system is mission-based only if it has all six:

1. Approved task object: a durable record of the task a human (or authorized policy) approved. Not a prompt, trace ID, session, ticket, or token.
2. Authority derivation: credentials and decisions are derived from that approved task, not minted independently of it.
3. Narrow-only delegation: derived authority, child tasks, and sub-agents can only narrow. Exceeding the parent requires a fresh approval.
4. Runtime enforcement: consequential actions are checked against the current task state at the point of use, not just at issuance.
5. Lifecycle: the task can expire, be revoked, expand (via fresh approval), and complete. Only an active task permits reliance.
6. Evidence: decisions and lifecycle events bind back to the task, so audit can reconstruct it.

Drop any one and you have something weaker: scopes without a task, sessions without approval, a PDP without an approved object, or a claim without enforcement.

What looks like a Mission but is not

The object-level version of the same test, useful when someone points at an artifact and asks “is that the Mission?”

The Mission object model

The approved task is a typed object, not a label. It contains:

• Purpose: an optional task-class URI, not the instance.
• Mission Intent: the structured, approved task description, committed by intent_hash.
• Authority Set: the maximum grantable authority derived from the Intent, committed by authority_hash. Authority is one component of the Mission, not the whole.
• Lifecycle state: owned by the issuer. Only active permits reliance.
• Identity: id and issuer, the same pair on the record and on the mission claim that every projection carries.

Everything an agent touches is a projection of this object: a Mission-bound token, a runtime decision, a child Mission, a lifecycle signal, an evidence record. Each carries the Mission reference and derives from, never exceeds, the Authority Set.

The Mission contains the Authority Set. The Authority Set does not define the Mission. A bundle of permitted actions with no approved task, lifecycle, or evidence is just authority, which OAuth already had.

A concrete Mission record

The running example as a record. Its intent_hash and authority_hash are the ones reproduced byte-for-byte in Reproducible test vector below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

{
  "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "purpose": "urn:example:mission:board-packet",
    "resources": ["https://finance.example.com",
      "https://docs.example.com",
      "https://workflow.example.com"],
    "constraints": ["Q3 2026", "Example Corp", "confidential"],
    "expires_at": "2026-10-15T18:00:00Z"
  },
  "authority_set": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } },
    { "type": "mission_resource_access",
      "resource": "https://docs.example.com",
      "actions": ["create_doc"],
      "constraints": { "template": "board-packet" } },
    { "type": "mission_resource_access",
      "resource": "https://workflow.example.com",
      "actions": ["notify_reviewer"],
      "constraints": { "group": "audit-committee" } }
  ],
  "intent_hash":
    "sha-256:jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE",
  "authority_hash":
    "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY",
  "subject": { "iss": "https://login.example.com",
    "sub": "alice@example.com" },
  "approver": { "iss": "https://login.example.com",
    "sub": "alice@example.com" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "approval_event_id": "ape_5D8wQ1kR7mX2vT4nH6jZ",
  "created_at": "2026-09-30T17:03:00Z",
  "expires_at": "2026-10-15T18:00:00Z"
}

Derived tokens carry the record’s id and issuer in the mission claim alongside authority_hash. subject and approver are {iss, sub} pairs, authoritative for principal equality, and they may differ when an administrator approves on a user’s behalf. The record also carries its issuance context: the agent’s client_id, the policy_version the Authority Set was derived under (so a derivation can be re-checked), the approval_event_id, created_at, and a top-level expires_at mirroring the Intent’s. The consent disclosure the Approver saw is committed separately by the Consent Evidence companion (From a Request to an Approved Mission).

Lifecycle states

The issuer owns the state machine. The core defines three states. Companion profiles add more, and the one rule a consumer always applies is that only active permits reliance. Every other state, recognized or not, is treated as non-active, so the model fails safe as it evolves.

• active (core): approved. Derivation and reliance permitted.
• revoked (core): terminated by user, admin, or policy. Terminal.
• expired (core): expires_at passed. Terminal.
• suspended (Status companion): paused. Reversible to active.
• completed (Status companion): finished. Terminal. Legal from active or suspended.
• superseded (Expansion companion): replaced by an approved successor. Terminal.
• cascaded (Child Delegation companion): a child terminated because its parent reached a terminal state. Terminal, and distinct from revoked so audit can tell a cascade from a direct termination.

A consumer that has never heard of suspended, superseded, or cascaded still refuses to rely on them, because they are not active. New states are therefore safe to add. (One exception, by design: an unrecognized entry-level terminal_when discharge condition must fail closed, not be ignored. See Mission Lifecycle and Change.)

Competitive landscape

Each of these is real and useful, and none is a substitute for an approved task object. Mission-based authorization composes with them rather than replacing them.

The pattern is consistent. The credential and decision layers are well-served. The approved task is the missing object. Mission-based authorization supplies it and lets the others bind to it: RAR derives from it, the PDP decides against it, sessions and traces reference it. And the “Law it breaks alone” column is the precise sense in which the category is forced rather than preferred. Used alone, every row breaks at least one of the five laws, so an architecture that satisfies all five contains a Mission-shaped object, whatever it is called. The one row that breaks none is not an alternative but an instance.

When it is the wrong tool. If there is no durable task to govern (a single user-driven request, a machine-to-machine service credential, a short-lived consumer authorization where the credential lifetime is the task), a Mission adds cost without value. The category earns its keep only when authorization must outlive and bound a multi-step, multi-resource, possibly-delegated task. And note that AAuth Mission is itself an instance of this category on a different substrate, not a rival to it. The interesting question there is shared governance across substrates, not which one wins.

Minimum viable mission-based authorization

The smallest useful deployment, and the path up:

• Stage 0: Substrate only. Ordinary OAuth, no Mission. Fine for single-request, non-agentic flows.
• Stage 1: Mission-bound issuance. A mission claim on derived tokens, with state-gated issuance: a possession-independent kill switch for future derivation. Audit and derivation control, not action-time defense.
• Stage 2: State and revocation freshness. Status / introspection so consumers can check current Mission state.
• Stage 3: Runtime enforcement. Per-action PDP checks for consequential actions. This is the stage that turns governance metadata into agent safety.
• Stage 4: Lifecycle. Signals, expansion, and completion: prompt revocation, governed growth, and monotonic narrowing.
• Stage 5: Delegation. Child Missions and offline attenuation: strict-subset authority for sub-agents, without ambient inheritance.
• Stage 6: Operational assurance. Harness binding, safe unwinding, and audit transparency.

Most AI agents that touch private data, untrusted content, or external side effects need at least Stage 3, and Stages 5–6 for fan-out and full governance. Stages 1–2 alone are not enough for consequential autonomy.

The stages roll up into the adoption ladder’s four claimable tiers, one line each:

The implementation checklist

The claim a deployment makes should be checkable. This is the field checklist for the protocol MVP, with the deeper treatments linked.

Conformance is scoped, not global. A deployment that cannot prevent an action class on some path must not claim runtime enforcement for that class, and must name the paths it does mediate. A claim worth trusting reads like this:

This deployment claims the protocol MVP for the finance, docs, and workflow APIs, with PEP coverage at MCP tools/call and the resource APIs, Mission Status freshness within 30 seconds, push revocation for the workflow domain through the experimental Signals profile, and no runtime-enforcement claim for direct shell egress.

Every clause maps to a row above and can be verified. A claim that cannot be written in this form is not a conformance claim. It is marketing. The honest deployment claim in the citation kit is the same claim as a reusable template, and what not to claim is its negative space.

Adversary model

The non-goals below say what this does not solve. This is the complementary view: the adversaries it does constrain, the layer that constrains each, and the residual it leaves. The reasoning is developed across the parts. This table is the consolidated map, and the Mission Security Model draft (Informational) is its spec-level counterpart: the trusted base, the cross-cutting assumptions, and the consequence of each component’s compromise.

The honest reading: the strong adversary, a fully compromised agent, is contained at the boundary (custody, per-action checks, narrow-only delegation, the kill switch), never by trusting what the agent says. The residual column is the part no claim should paper over.

Threats and non-goals

Mission-based authorization is credible because it is precise about its edges. It does not:

• make an LLM’s reasoning trustworthy
• replace resource-local policy (the resource remains authoritative for its own decisions)
• provide full information-flow control
• prove that every side channel has been mediated
• eliminate the need for human step-up on high-risk actions
• make a broad, over-scoped Mission safe (breadth approved is breadth granted)
• lean on deterrence as a compensating control. Human delegation quietly does, because people fear the audit that follows. An agent has no career to protect, and its judgment can be rewritten mid-task by content it reads, so the runtime boundary must carry the weight that deterrence carries for people.

What it does:

It gives policy, credentials, lifecycle, delegation, and audit a common object (the approved task) and a runtime layer that checks each consequential action against it.

The safety properties most people assume from “Mission-bound agents” (action-time defense, prompt revocation, safe unwinding, evidence) come from the runtime and operational layers, not from the mission claim alone.

Noun distinctions

Keep these stable. Do not let “task,” “mission,” “workflow,” and “session” blur.

• Mission Intent: the proposed task (untrusted until validated).
• Mission: the approved, governed task (durable, lifecycle-owned).
• Authority Set: the derived, grantable authority the Mission bounds.
• Mission-bound token: a credential projection carrying the mission claim.
• Runtime decision: a per-action permit or deny.
• Evidence: an audit artifact (approval, consent, decision, lifecycle).
• Harness: the runtime continuity and mediation layer, not authority.

Reproducible test vector

The credibility of this model is its hashing, so here is one anchor you can reproduce byte for byte. Every integrity anchor is a SHA-256 over a domain-separated, issuer-bound envelope ({ "typ", "iss", "value" }), canonicalized with JCS (RFC 8785), encoded as sha-256: followed by base64url with no padding. For intent_hash, typ is mission-intent and value is the approved Mission Intent.

The JCS canonical bytes of the envelope, for the running example, are exactly:

1

{"iss":"https://as.example.com","typ":"mission-intent","value":{"constraints":["Q3 2026","Example Corp","confidential"],"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"]}}

Hash those bytes and you get the anchor. Reproduce it from a shell:

1
2
3

printf '%s' '{"iss":"https://as.example.com","typ":"mission-intent","value":{"constraints":["Q3 2026","Example Corp","confidential"],"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"]}}' \
  | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '='
# => jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE

So intent_hash = sha-256:jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE. The same procedure with typ = mission-authority-set and value = the Authority Set array yields authority_hash = sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY.

Two rules make this interoperable: JCS sorts object keys but preserves array order (so the Authority Set’s entry order is part of the canonical form), and the typ value domain-separates the anchors so a digest of one object can never be read as the other. A verifier reproduces the digest from the recorded object alone.

Glossary

Intent step

• Mission Shaper: a client-side component that turns a prompt or trigger into a candidate Mission Intent. Proposes only. Grants no authority.
• Mission Intent: the structured proposal: goal, resources, and expires_at (required), with optional constraints, success_criteria, purpose, and controls. Closed at the top level: unknown members are rejected, and machine-actionable extensions ride in controls. Submitted via the mission_intent parameter through PAR.
• Shaping Evidence: an optional record of how the proposal was produced. Audit material, not authority.

Mission step

• Approval event: the AS validates the Intent and derives the Authority Set, the Approver consents to the rendered Intent + derived Authority Set, and the AS commits the anchors and creates the Mission active, atomically.
• Authorization Server (Mission Issuer): holds the Mission record, derives authority, runs the approval event, gates issuance.
• mission claim: the object on every issued token: id, issuer, authority_hash.
• intent_hash: canonical hash of the approved Mission Intent.
• Consent Evidence / consent_rendering_hash: a companion artifact committing the structured disclosure the AS recorded as rendered (not the pixels, not comprehension).
• Subject / Approver: {iss, sub} principals: the user the task is for, and the principal who approved it. They may differ.

Authority step

• Authority Set: the maximum authority committed by authority_hash, as mission_resource_access entries (resource, actions, constraints, per-entry delegation), plus any other RFC 9396 types a deployment registers.
• authority_hash: canonical hash of the Authority Set.
• authorization_details: the RFC 9396 wire shape for derived authority.
• act chain: the RFC 8693 actor chain. A delegated token carries the same mission claim with subset authority.

Enforcement step

• PEP / PDP: the Policy Enforcement Point obtains a permit from the Policy Decision Point before each consequential action. The PDP evaluates against the live Mission.
• parameter_digest: binds a permit to concrete request parameters, closing the time-of-check-to-time-of-use gap.
• Decision Evidence / Execution Evidence: per-decision and per-outcome audit records.

Lifecycle, roles, delegation

• Core states active / revoked / expired. Companion states suspended / completed (Status), superseded (Expansion), and cascaded (Child Delegation). Unknown states are treated as non-active.
• Mission Status (pull, signed, mission_id-keyed) and Lifecycle Signals (SET events, delivered push or poll). Expansion widens via a fresh approval that supersedes the predecessor. Completion / terminal_when is monotonic, per-entry discharge.
• Child Mission: a strict-subset Mission a parent authorizes for a sub-agent, with cascade revocation. Offline attenuation: minting a narrower child token off the AS hot path, kept safe by the runtime re-checking Mission state.

The publication’s named artifacts

• The five laws: Durability, Attribution, Narrowing, Termination, and Containment, the layer’s substrate-neutral invariants, quoted above.
• The claim gate / litmus test: the six properties a system must have to claim mission-based authorization, expanded above.
• The vendor test: the same six properties as questions to ask a vendor, with what failing answers sound like.
• The protocol MVP: the adoption wedge, per the formula: issuance core, runtime enforcement, AuthZEN binding, and Status.
• The adoption ladder: baseline issuance, protocol MVP, governed agent, high-assurance agent, with standalone governance as the parallel lane, staged as crawl, walk, run in Adopting Mission-Bound Authorization.
• The honest deployment claim: the claim template naming tier, enforcement scope, freshness, evidence, and exclusions.

The running example, end to end

The series follows one task. This is the canonical walkthrough, each part picks up its step, and Mission-Bound Authorization on the Wire shows the same steps as actual protocol exhibits.

Scenario. Alice asks an agent: “Put together the Q3 board packet for the audit committee and let them know it’s ready.” The Mission’s Authority Set is query_financials (finance, Q3 2026), create_doc (docs, board-packet template), and notify_reviewer (workflow, audit-committee group), bounded to an expiry.

1. Derive. The AS validates and narrows the Intent and derives the Authority Set it will ask Alice to approve. (The Mission)
2. Approve. The AS renders the validated Intent + derived Authority Set. Alice consents. The AS commits intent_hash and authority_hash and creates the Mission active, atomically. (Approval integrity)
3. Issue. The agent gets a Mission-bound token carrying the mission claim. (The Mission)
4. Permit a read. The agent reads Q3 financials. The PDP permits query_financials against the live Mission. (Runtime enforcement)
5. Gate a write. Drafting the document is a write. The create_doc permit is bound to concrete parameters and checked at the point of use. (Runtime enforcement)
6. Attempt expansion. Mid-task the agent decides it “needs” CRM customer data (outside the Authority Set). It cannot widen in place. Widening requires a fresh approval (a successor Mission). (Lifecycle)
7. Deny the expansion. Policy declines the CRM expansion. The original Mission is untouched and the agent does not get CRM access. (Lifecycle)
8. Delegate, narrowed. A sub-agent gathers the financials under a Child Mission scoped to query_financials only, expiry ≤ parent, no create_doc or notify_reviewer. (Delegation)
9. Revoke. The board meeting is cancelled. An admin revokes the Mission. Status reports the new state and the experimental Signals push announces it. All further derivation stops, and the child transitions to the terminal cascaded state. (Delegation, Lifecycle)
10. Stop the work. The harness, which bound the session and queue to Mission state, halts the paused draft (session continuity is not authority), and orchestration unwinds the half-written document. (Agent runtime)
11. Reconstruct. The SCITT audit feed for this Mission shows one verifiable, append-only history (approval → consent → the permitted read → the denied CRM expansion → revocation), committed by hash so the financial contents stay out of the log. (Agent runtime)

That is the whole category in one task: an approved object, authority derived from it, every consequential action checked against it, delegation that only narrows, a lifecycle that can stop it, and evidence that reconstructs it.

What this replaces, and what it does not

Mission-based authorization adds one object. It does not displace the stack around it.

• Not OAuth. The Mission rides OAuth issuance, exchange, and sender constraint. The core is an OAuth profile, not a successor.
• Not AuthZEN or your PDP. The runtime contract binds to the AuthZEN Authorization API. The Mission is a new input to the decision, not a new decision engine.
• Not resource policy. The resource stays authoritative for its own objects. A Mission permit is an upper bound, never a command.
• Not session management. The harness keeps owning execution continuity. It consults Mission state before resuming, and that is the whole change.
• Not model alignment. Nothing here makes an LLM’s reasoning trustworthy. The Mission bounds what a drifted or injected agent can reach, and the runtime layer enforces the bound.

What it adds is the piece those layers keep routing around: the governed task object they all bind to. The objections below answer the sharper versions of “isn’t this just X.”

Common objections

The recurring pushbacks, each with the short answer and where the long one lives.

“Isn’t this just RAR?” RAR is how the Authority Set serializes, not what a Mission is. authorization_details expresses authority. It has no approval event, no lifecycle, no state a consumer can observe, and no identifier that joins records across domains. The Mission contains the Authority Set. The Authority Set does not define the Mission, and a bundle of permitted actions with no approved task, lifecycle, or evidence is what OAuth already had.

“Isn’t this just a session?” A session preserves runtime continuity and commits no authority. It can prove the runtime survived, never that the task did. Sessions Are Not Missions is the full argument, and the harness profile exists precisely because resume must be contingent on Mission state rather than the reverse.

“Isn’t this just ABAC or ReBAC?” A PDP evaluates requests against policy and attributes, one request at a time. Nothing in ABAC or ReBAC supplies the durable, approved task instance the decision should be conditioned on. Mission-based authorization does not replace the PDP. It gives the PDP the missing input, and the AuthZEN binding carries it.

“Isn’t this just PAM, or an IGA request?” Closest cousins, and the differences are the point. An IGA approval produces a standing entitlement. A PAM checkout elevates an identity for a window and records what it did. A Mission binds the elevation to the approved task: authority is derived from it, every consequential action needs a permit against its current state, delegation can only narrow, and the authority ends when the task does rather than when the clock or the session does. Deferred Approval is deliberately shaped so an existing request-and-approval workflow can drive it.

“An agent discovers tools and resources at runtime. You cannot approve what you cannot enumerate.” The Mission approves the task, not the toolset, and discovery is a proposal event, not an authority event. A runtime-discovered tool or resource acquires authority in one of two governed ways. Either it was already inside the approved bounds (the Intent’s constraints and the derivation policy govern resources the Approver bounded without enumerating), or it arrives through the discovery loop: the PDP denies with a requestable out_of_authority, ARAP turns the denial into a governed request, and the widening lands as a separately approved successor Mission through Expansion. The alternative, broad standing grants to cover the unknown, is the blank check this publication exists to retire. What a Mission cannot do is make a discovered counterparty trustworthy: whether to trust a runtime-discovered issuer, tool server, or its metadata is the substrate problem, and the Open-World OAuth series carries it.

“An agent can stay inside every parameter bound and still do damage with the content.” Correct, and the layer never claims otherwise. Parameter binding, metering, and state checks are structural enforcement: they bound the blast radius, and they cannot judge whether an in-bounds email body leaks intellectual property. The architecture’s answers to semantic risk are deliberately structural too: keep the envelope small (scope, and exposure), keep the lethal trifecta split at execution time, and escalate the classes where content is the harm to action-bound human approval under mediated custody. Content-aware controls (DLP verdicts, classifiers, an LLM judge) compose as decision inputs through the AuthZEN binding’s context, and they raise the bar without becoming a guarantee, because a judge model reading attacker-influenced content is itself injectable. The adversary model carries the residual in writing: within the approved scope, a steered agent can still misuse what was granted, which is why scope stays tight.

“Isn’t this overkill?” For a single user-driven request, a machine-to-machine service credential, or any flow where the credential lifetime is the task, yes. Skip it. The category earns its keep only when authorization must outlive and bound a multi-step, multi-resource, possibly delegated task, and the protocol MVP is deliberately the smallest surface that does that.

“Why not just short-lived tokens?” Short lifetimes bound staleness. They do not represent the task, and they make the wrong thing the clock. A revoked task keeps deriving fresh short tokens unless issuance is gated on task state, and audit still joins by timestamp. Mission-bound deployments use short-lived tokens too. They are a control inside the design, not a substitute for the object.

The draft family at a glance

Every part links its drafts inline. This table is the whole family in one place. All of these are individual Internet-Drafts published as editor’s copies and proposed for discussion. None is adopted by a working group. The names reflect the architecture: substrate-neutral profiles carry draft-mcguinness-mission-* names, while the OAuth bindings keep oauth in the name and “for OAuth 2.0” in the title.

The Maturity column follows the repository’s adoption ladder. Adopt first is the Architecture and the core. Minimum is the Enforced bundle, and together with the core it is the protocol MVP. Recommended is what AI agents add for the Governed bundle. Advanced profiles are stable design to adopt when the use case arrives. Experimental profiles are for evaluation only: each depends on an unratified substrate or defines a newer, less-exercised model, and each names a stable path to prefer where one exists.

For AI agents, the README is explicit that consent evidence and the harness are not optional extras. They are the Recommended tier, the Governed bundle.

How to cite this publication

Link the piece that matches what you are referencing:

• The category and definition: this Reference.
• The fast path (essay, test, blueprint): Agents Need a Mission, Not Just Credentials, the vendor test, and the blueprint.
• The mental model for non-specialists: What the Corporate Card Already Solved.
• The missing layer and its laws: the five laws of delegated authority above, or the series overview for the full argument.
• The argument for why the Mission is the missing object: The Mission Is the Missing Abstraction.
• The primitive’s definition, vocabulary, and name: The Mission Model.
• The safety claim (runtime is load-bearing): Mission-Bound Runtime Enforcement.
• The adoption path (crawl, walk, run): Adopting Mission-Bound Authorization.
• The OAuth wire implementation: the draft family.
• The MCP application: Least-Privilege MCP Tool Calls Need a Mission.
• The wire exhibits: Mission-Bound Authorization on the Wire.
• To discuss or object: issues on the draft repository.

One-line definition to quote:

Mission-based authorization is the layer between user intent and per-request authorization. It makes the approved task a first-class governance object, then binds credentials, runtime decisions, delegation, lifecycle, and audit back to it.

A note on requirement language

The series quotes requirement keywords such as MUST, SHOULD, and MAY with their BCP 14 meanings (RFC 2119, RFC 8174) when they appear in all capitals. Conformance applies to the profile section each requirement appears in. The drafts are the normative text.