An Architecture for Mission-Bound Authorization

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

A Mission is a durable governance object created by an explicit approval event: the approved task, with a lifecycle. Authority for the task is derived for the Mission, bound to it, and gated on its state. The Mission is not a new way to express authority: Rich Authorization Requests [RFC9396] and kindred mechanisms express authority, and the Mission is the approved task that authority serves.¶

The model is deliberately decomposed: a core profile (the "issuance profile", [I-D.draft-mcguinness-oauth-mission], here "the core") defines the object and its OAuth 2.0 [RFC6749] binding, a standalone binding hosts the same object without changing an existing Authorization Server ([I-D.draft-mcguinness-mission-authority-server]), an AAuth binding gives that protocol's native mission concept the model's structure and lifecycle ([I-D.draft-mcguinness-mission-aauth]), and optional companions layer approval, lifecycle, enforcement, runtime, delegation, and proof capabilities on top. The decomposition keeps each interface small but spreads the structure across many documents and three bindings; this document is the single structural view.¶

Read as one system, the family defines a delegated-authority layer, with OAuth 2.0, the standalone Mission Authority Server, and AAuth as peer bindings into it (Section 3).¶

It defines no protocol, no object, and no requirement. It is a map, not the territory: every mechanism named points at the profile that normatively defines it, and where this document and a profile appear to differ, the profile governs.¶

2. Status: An Informational Architecture

This document is Informational. It establishes no conformance class and defines no new mechanism, claim, or wire format. Where it uses words like "must" or "should," they carry their ordinary English meaning and describe what a referenced profile establishes, not a requirement this document places. Terms are the core's; Policy Enforcement Point (PEP), Policy Decision Point (PDP), and consequential action are the runtime profile's ([I-D.draft-mcguinness-mission-runtime]); Mission Authority Server (MAS) is defined by [I-D.draft-mcguinness-mission-authority-server]; the AAuth binding is defined by [I-D.draft-mcguinness-mission-aauth].¶

Its boundary with the Mission Security Model ([I-D.draft-mcguinness-mission-security-model]) is deliberate: this document describes components, interfaces, and data flows; the security model describes the trusted base and how each component's compromise degrades the guarantees. Each profile's own Security Considerations remain normative over both.¶

3. The Mission

OAuth 2.0 issues access tokens for individual resource requests; it has no durable, approved artifact for the larger task a client pursues on a user's behalf. That matters for AI agents: given a mission (book the trip, reconcile the ledger), an agent takes many actions across many resources over a long time, spawning sub-agents and surviving restarts, and independently issued tokens cannot express the approved task, its boundary, or its end (the core's Introduction).¶

The family separates the task from the authority. The Mission is the approved task, with a lifecycle; the Authority Set is the concrete authority (resources, actions, constraints) derived for it. A Mission is not another authorization_details type: it is the durable, approval-backed object an Authority Set is derived for and gated by (the core's Why a New Object section).¶

A client proposes a Mission Intent; the Mission Issuer derives an Authority Set for it; an approval event commits both and creates the Mission. The commitment is two integrity anchors, intent_hash over the approved Mission Intent and authority_hash over the consented Authority Set, each computed over a domain-separated, issuer-bound envelope with fixed canonicalization, so an auditor can reproduce either digest from the record alone (the core's Mission Approval, Integrity Anchors, and Canonicalization Rules sections). The record is immutable except for its state (the Mission Record section).¶

The core lifecycle states are active, revoked, and expired, and only active permits issuance or continued reliance. Companions add states (suspended, completed, superseded, cascaded), and one rule keeps that safe without a registry: a consumer treats every state other than the exact value active, including one it does not recognize, as non-active, so an unrecognized state fails safe (the core's Mission Lifecycle and Gating section).¶

The Mission model is the beginning of a distinct layer. Authentication and token issuance answer who is acting and what a single credential carries; governance of standing entitlements answers what access a principal should hold over time. Neither governs the approved task a delegate or agent performs on a principal's behalf: its bounded authority, its lifecycle, the per-action check that execution stays inside that boundary, and the evidence that binds back to it. That is the delegated-authority layer this family defines, and it composes with the layers below rather than replacing them. The Mission Authority Server ([I-D.draft-mcguinness-mission-authority-server]) is that layer's binding-independent control plane: it holds the approved task, its lifecycle, and its authority across an estate of Authorization Servers, resources, and tools, whichever of them issues a given token. The layer's operational surface is already named: the Mission record and its anchors, the lifecycle and its status, authority distribution to the points of enforcement (the Authority Set and its policy views), decision evidence, the portable proof (the Mission Mandate, [I-D.draft-mcguinness-mission-mandate]), and the management plane for fleet-scale operation ([I-D.draft-mcguinness-oauth-mission-management]). The near-term deployment is a control plane beside an unchanged OAuth estate; the direction is delegated authority management as a layer of its own.¶

4. Non-Goals

The model's boundary is deliberate. The family does not define:¶

• A new authority format. Rich Authorization Requests [RFC9396] and kindred mechanisms express authority; the Mission is the approved task that authority serves (Section 3).¶

• A policy language. The PDP evaluates the Mission's Authority Set, constraints, and state; how a deployment authors policy beyond them is local ([I-D.draft-mcguinness-mission-runtime]).¶

• Entitlement governance. What standing access a principal should hold over time belongs to existing governance layers; the delegated-authority layer composes with them (Section 3).¶

• An agent framework. The harness constrains the execution environment's relationship to Mission state; it does not say how an agent plans, reasons, or calls tools ([I-D.draft-mcguinness-mission-harness]).¶

• Semantic derivation. Whether a derived Authority Set is the right reading of the task is committed and auditable, not standardized (Section 10).¶

• Agent trustworthiness. The family bounds what a compromised or injected agent can do; it does not make the agent trustworthy ([I-D.draft-mcguinness-mission-security-model]).¶

5. The Capability Envelope

One tension organizes the whole family. A Mission commits its authority and intent once, at approval, but an agent's work is open-ended: the actions a task will take are not known when it is approved. "Reconcile Q3 invoices" must authorize reading any invoice and posting any adjustment under the cap, because the specific ones cannot be enumerated in advance. So the Authority Set an Approver consents to is a capability envelope, not a task specification, and the gap between that envelope and what a given run actually does is where agent risk lives.¶

The family's mechanisms are levers that narrow that gap: constraint-bounding and the subset rule shrink the envelope at issuance; runtime enforcement checks each action against it at the point of use; action-bound approval re-consents the highest-consequence actions with their concrete parameters; progressive authorization trades many increment approvals for one bounded ceiling; metering caps cumulative consumption; and completion retires authority as the task finishes. No single lever closes the gap; a deployment composes the ones its risk warrants (Section 13), and the verbs of Section 11 organize the levers by the question each answers.¶

The levers share one strategy: they convert semantic risk into structural signals. A policy decision point is never asked to judge whether content is harmful; provenance (the harness taint context), composition (the quarantine pattern), egress enumeration and volume bounds, separation of duty, and re-consent turn that question into facts a decision can gate on. A content evaluator a deployment adds composes as Resource policy at the decision point and only ever narrows.¶

The envelope meets its hardest case in the open world. The family inherits OAuth's ontology: authority is client-proposed and enumerated at approval, which presumes the resources a task touches are knowable when it is approved. An agent that discovers resources at encounter time breaks that premise, and some substrates invert the ontology outright: the resource declares its own operations, meaning, and consequences, and that declaration, not the client's proposal, is the semantic material an approver or a policy needs (the AAuth binding composes one such substrate, [I-D.draft-mcguinness-mission-aauth]). The family routes the encounter through its existing levers: a resource within a pre-consented ceiling binds by policy drawdown ([I-D.draft-mcguinness-oauth-mission-progressive]); a tool from a catalog binds through the capability-source binding ([I-D.draft-mcguinness-mission-authzen]); a resource in a partner domain binds through projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]); anything else requires a fresh approval ([I-D.draft-mcguinness-oauth-mission-expansion]). Where the resource self-declares, the declaration's digest is committed with the binding evidence, a third commitment beside intent_hash (what the client asked) and authority_hash (what was consented): what the resource claimed to be at the moment authority bound to it.¶

6. A Mission's Life

The structure is easiest to see by following one Mission end to end under the OAuth binding: an operator gives an agent the task "reconcile Q3 invoices."¶

1. Propose. The client shapes the request into a structured Mission Intent, untrusted by construction, and submits it in a Pushed Authorization Request [RFC9126] ([I-D.draft-mcguinness-mission-shaping]; the core).¶

2. Approve and record. The Authorization Server derives an Authority Set (read invoices, post adjustments under a cap), discloses it, and the Approver approves. The approval event commits intent_hash and authority_hash and creates the Mission, active with an expiry; Consent Evidence commits what was shown ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

3. Issue. Tokens are derived under the subset rule, carry the mission claim, and derivation and refresh are refused once the Mission leaves active (the core).¶

4. Enforce. Before each consequential action (posting an adjustment), the PEP obtains a PDP permit bound to the action's concrete parameters and to current Mission state ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authzen]).¶

5. Delegate. A sub-agent that verifies ledger entries receives a child Mission with strictly narrower authority and lineage ([I-D.draft-mcguinness-oauth-mission-child-delegation]).¶

6. Govern. Consumers observe state through Status and Signals; growth requires an approved successor ([I-D.draft-mcguinness-oauth-mission-expansion]), and entries retire as their work completes ([I-D.draft-mcguinness-oauth-mission-completion]).¶

7. Stop. Revocation or expiry turns every gate at once: issuance refuses, the PDP denies, the harness pauses bound sessions and queues, and the orchestrator unwinds in-flight work ([I-D.draft-mcguinness-mission-harness], [I-D.draft-mcguinness-mission-orchestration]).¶

8. Prove. The record, anchors, evidence, and receipts let an auditor reconstruct what was approved, shown, decided, and done, and a Mandate carries the committed facts to parties outside the deployment ([I-D.draft-mcguinness-mission-mandate], [I-D.draft-mcguinness-mission-audit]).¶

The approval-to-permit path in sequence:¶

 Approver     Agent              AS          PEP/PDP        RS
    |           |                 |             |            |
    |           | 1 Mission       |             |            |
    |           |   Intent (PAR)  |             |            |
    |           |---------------->|             |            |
    | 2 disclose and approve      |             |            |
    |<--------------------------->|             |            |
    |           |  Mission active:|             |            |
    |           |  intent_hash,   |             |            |
    |           |  authority_hash |             |            |
    |           | 3 Mission-bound |             |            |
    |           |   token         |             |            |
    |           |<----------------|             |            |
    |           | 4 action, token, parameters   |            |
    |           |------------------------------>|            |
    |           |                 | 5 state and |            |
    |           |                 |   authority |            |
    |           |                 |<----------->|            |
    |           |                 |             | 6 permit,  |
    |           |                 |             |   evidence |
    |           | 7 permitted action executes   |----------->|

Under the standalone binding the same life runs with ordinary tokens and the Mission Join in place of step 3's claim carriage (Section 12); under the AAuth binding the Person Server plays the AS role for its native missions.¶

7. Mission Invariants

Seven invariants hold across every profile and binding; each is stated normatively by its home document and consumed everywhere else. A change that would break one is a change to the model, not to a profile.¶

Authority serves an approved task:

No Mission-bound authority exists except by derivation for a Mission, and a Mission is created only by an explicit approval event that commits intent_hash and authority_hash (the core). Fields an agent can influence shape authority only through the pre-approval derivation the Approver consents to; once the Mission is approved they are inert and never derive, widen, or gate authority.¶

Only active permits:

Issuance, refresh, and reliance require the exact state active; every other state, including an unrecognized one, fails safe (the core's Mission Lifecycle and Gating section).¶

Authority only narrows:

Derived tokens, delegated child Missions, attenuated tokens, and cross-domain projections carry subsets; widening exists only as an approved successor: a fresh approval ([I-D.draft-mcguinness-oauth-mission-expansion]), or policy drawdown within a ceiling a human pre-consented ([I-D.draft-mcguinness-oauth-mission-progressive]).¶

Revocation is possession-independent:

A Mission ends by a state change at its issuer, not by finding and destroying credentials; outstanding credentials meet the issuance gate, the runtime re-check, or their own expiry, whichever comes first (Section 9.8).¶

Attribution is carried, never inferred:

Each role in the actor chain travels in its own construct, and the evidence layer records them together; no role is derived from another (Section 8.1).¶

Enforcement fails closed; inert surfaces fail safe:

A PDP that cannot establish state or authority within the published staleness bound denies, and a consumer that cannot refresh state treats its cache as unreliable rather than as permission ([I-D.draft-mcguinness-mission-runtime]).¶

Anchors commit; they do not prove semantics:

The integrity anchors prove what was approved and committed, not that the derivation was the right reading of the task (Section 10).¶

8. Mission Roles and Components

For each component: what it does, what it holds, and which document specifies it. What its compromise costs is the security model's subject ([I-D.draft-mcguinness-mission-security-model]).¶

Agent (client):

Proposes the Mission Intent and executes the task; in the OAuth binding it holds derived Mission-bound tokens; outside the trusted base and assumed compromisable ([I-D.draft-mcguinness-oauth-mission]). A deployment may authenticate concrete agent instances under the client-instance-assertion profile and its AI-agent profile ([I-D.draft-mcguinness-oauth-client-instance-assertion], [I-D.draft-mcguinness-oauth-ai-agent-instance]), which sharpens delegation chains, joins, and evidence attribution to instance granularity without touching the Mission model.¶

Subject:

The user or system on whose behalf the Mission is approved, an (iss, sub) pair recorded immutably at approval (the core).¶

Approver:

The single accountable principal who approves the Mission; equal to the Subject for self-approval (the core's Single Accountable Approver section).¶

Mission Issuer:

Validates the Mission Intent, runs the approval event, records the Mission, and owns its state. Three bindings. OAuth Authorization Server: every derived token carries the mission claim, and issuance and refresh are gated on Mission state ([I-D.draft-mcguinness-oauth-mission]). Mission Authority Server: the same record, anchors, and lifecycle without issuing tokens; the PDP joins ordinary credentials to the Mission at the point of use ([I-D.draft-mcguinness-mission-authority-server]). AAuth Person Server: the mission blob carries the record under AAuth's s256 commitment, and the Person Server issues or gates every auth token, so issuance gating holds ([I-D.draft-mcguinness-mission-aauth]). Under every binding the Issuer also serves audience-scoped policy views, the authority-distribution artifact the runtime and MAS profiles define ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authority-server]).¶

Resource Server:

The protected resource. In the OAuth binding it enforces statelessly from the token and can check the mission claim (the core's Resource Server Enforcement section); in the standalone binding the token carries no Mission signal, and Mission properties reach it only through the enforcement path.¶

PEP and PDP:

The PEP sits at the last controllable boundary before an action and obtains a permit for each consequential action; under mediated custody it, not the agent, holds the sender-constraint key. The PDP evaluates the action against the Mission's authority, constraints, actor chain, and current state, and fails closed ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authzen]); in the standalone binding it also verifies the subject and client join (the MAS's Mission Join section).¶

Agent harness:

Hosts the agent; binds sessions, task graphs, queues, cached tool connections, and sub-agent handles to Mission state; establishes the environment with no unmediated path to mediated actions ([I-D.draft-mcguinness-mission-harness]).¶

Orchestrator:

Assigns each workflow step a reversibility class, records an unwind plan before dispatch, and compensates in-flight work when a Mission stops ([I-D.draft-mcguinness-mission-orchestration]).¶

Transparency Service:

An append-only SCITT log [RFC9943] that registers Mission evidence as Signed Statements and issues receipts verifiable offline ([I-D.draft-mcguinness-mission-audit]).¶

Verifiers:

Parties outside the deployment that check Mission facts without a token exchange: Mandate verifiers confirm what was approved ([I-D.draft-mcguinness-mission-mandate]); evidence consumers check consent, decision, and execution evidence against the anchors and receipts ([I-D.draft-mcguinness-oauth-mission-consent-evidence], [I-D.draft-mcguinness-mission-authzen]).¶

The bindings converge on one object, and enforcement draws on it regardless of binding:¶

      Subject        Approver
          \             |
           \      approval event
            \           |
  +----------------------------------------------------+
  |                   Mission Issuer                   |
  | +--------------+ +--------------+ +--------------+ |
  | | OAuth AS:    | | Standalone   | | AAuth PS:    | |
  | | Mission-     | | MAS: no      | | native       | |
  | | bound tokens | | tokens; the  | | missions;    | |
  | | gated on     | | PDP joins    | | auth tokens  | |
  | | state        | | credentials  | | gated        | |
  | +------+-------+ +------+-------+ +------+-------+ |
  +--------|----------------|----------------|---------+
           v                v                v
          the Mission: intent_hash,
       authority_hash, lifecycle state
                     |
                     | state and authority (claim,
                     | introspection, Status, Signals)
                     v
     Agent ------> PEP ----------> PDP
     (harness,      |  <- permit -
     orchestrator)  v
             Resource Server

Grouped as planes rather than parts, the same components form the delegated-authority layer of Section 3, with the evidence surface crossing all of them:¶

 control       Mission Issuer (OAuth AS | MAS | AAuth PS):
               record, anchors, lifecycle, status,
               authority distribution, management
                    |                       ^
                    | state, authority      | evidence
                    v                       |
 enforcement   PEP and PDP: a permit per consequential
               action, parameter binding, custody
                    |                       ^
                    | mediated actions      | outcomes
                    v                       |
 execution     harness, agent, orchestrator: sessions,
               sub-agents, queues, unwinding

 evidence      Consent Evidence, decision and execution
 (crossing)    evidence, Mission Receipts, the Mandate,
               audit transparency

9. The Mission Substrate

The companion profiles named without "oauth" are defined against the Mission model's substrate primitives rather than against OAuth mechanics; each names what it consumes in a Mission Substrate section of its own. This section consolidates that interface: six primitives, each with its normative home and its consumers. Every sentence mirrors a rule the named profile states normatively.¶

10. The Authority Derivation Boundary

Deriving the Authority Set from the Mission Intent is the semantic heart of the model and the one step the family deliberately does not standardize. The consequence is a trust boundary worth stating plainly: interoperability begins at the committed result, not at the Intent. A Mission Intent has no portable semantics; two conforming Authorization Servers MAY derive different Authority Sets from the same Intent, and audit can establish what was derived (against intent_hash and policy_version), never whether it was the right reading of the task. A deployment whose partners must reason about its derivations SHOULD publish a derivation policy identifier and test fixtures that pin Intent-to-Authority-Set outcomes, so the local policy becomes reviewable even though it does not travel. Narrowing mode ([I-D.draft-mcguinness-oauth-mission]) is the checkable path: where the client supplies candidate authority, derivation is a subset of it and reproducible, which is the closest the family comes to portable derivation.¶

The derivation modes rank by how portable their result is:¶

A deployment seeking interoperable authority uses the first; free-text and model-assisted derivation are local policy unless a profile pins them with a published policy identifier, version, and test fixtures.¶

11. The Mission Verbs

The family organizes along a verb spine: each verb answers one question, sits on one trust boundary, and is owned by named documents. Together the verbs are the levers that narrow the capability-envelope gap (Section 5).¶

 propose      Intent Shaping (client side, untrusted)
                        |
 approve      Mission Issuer: the OAuth AS, Mission
 and record   Authority Server, or AAuth Person Server
              binding (+ Consent Evidence, Deferred
              Approval)
                        |
              the Mission: intent_hash,
              authority_hash, lifecycle state
                        |
 govern       Status (pull), Signals (push),
              Expansion (widen), Completion (retire)
                        |
 enforce      Runtime contract -> AuthZEN binding:
 each action  a PDP permit before every consequential action
                        |
 run and      Harness (continuity is not authority),
 wind down    Orchestration (unwind in-flight work)

 delegate     Child Delegation, Offline Attenuation

 project      Cross-Domain Projection (a Mission honored
              in another trust domain)

 prove        Consent Evidence, Mandate, Audit

 analyze      Security Model (the trusted base)

12. Mission Deployment Patterns

The OAuth binding stacks two independent chokepoints. 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. Issuance gating plus runtime enforcement is 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. The AAuth binding composes the same two chokepoints: the Person Server issues or gates every auth token, so issuance gating holds at the PS, and per-action enforcement runs under the runtime composition the AAuth profile defines ([I-D.draft-mcguinness-mission-aauth]). Per-action enforcement is budgeted, not blanket: only consequential actions are gated, the common-case decision is a local evaluation against a materialized policy view whose network cost is paid per freshness window, and only the high-consequence classes must hold a synchronous gate (the runtime profile's deployment considerations, [I-D.draft-mcguinness-mission-runtime]).¶

The standalone mode trades the token-layer kill switch for zero Authorization Server changes. A MAS creates, approves, and serves Missions while tokens remain ordinary; the PDP joins credentials to Missions, and the MAS is the freshness source. The cost is structural: no mission claim travels, revoking a Mission stops nothing at the token layer, and enforcement rests entirely on PEP coverage, so a token exercised outside that coverage is ungoverned (the MAS's Limitations section). The upgrade path is the issuance profile; the record, anchors, and lifecycle carry over unchanged. Between the two sits the issuance join ([I-D.draft-mcguinness-oauth-mission-issuance-grant]): the MAS remains the Mission Issuer while estate Authorization Servers redeem Mission Issuance Grants for Mission-bound, state-gated tokens, restoring the token-layer chokepoint without moving approval.¶

In sequence, the standalone mode runs submit, poll, approve, join, permit:¶

 Client               MAS                Approver     PEP/PDP
   |                    |                  |            |
   | 1 submit Intent    |                  |            |
   |------------------->|                  |            |
   | 2 202 pending      |                  |            |
   |<-------------------|                  |            |
   |                    | 3 disclose       |            |
   |                    |----------------->|            |
   |                    | 4 approve        |            |
   |                    |<-----------------|            |
   |                    | Mission active   |            |
   | 5 poll             |                  |            |
   |------------------->|                  |            |
   | 6 approved,        |                  |            |
   |   mission_id       |                  |            |
   |<-------------------|                  |            |
   | 7 action, token,   |                  |            |
   |   Mission ref      |                  |            |
   |--------------------------------------------------->|
   |                    | 8 signed status: |            |
   |                    |   active         |            |
   |                    |<------------------------------|
   |                    |------------------------------>|
   |                    |                  | 9 join;    |
   |                    |                  |   evaluate |
   | 10 permit          |                  |            |
   |<---------------------------------------------------|

The token in step 7 is an ordinary OAuth token from the unchanged AS; steps 8 through 10 are the Mission Join and the runtime decision (the MAS's Mission Join section), and the MAS's staged walkthrough of the same flow is its end-to-end appendix ([I-D.draft-mcguinness-mission-authority-server]).¶

The quarantine pattern removes a leg of the injection-to-exfiltration chain instead of gating it. Work that ingests untrusted content (web pages, inbound mail, third-party documents) runs under a Mission whose Authority Set carries no external-communication or external-commitment authority; work that communicates externally runs under a separate Mission whose inputs are the quarantined product, under the harness taint policy ([I-D.draft-mcguinness-mission-harness]) and, where claimed, the runtime profile's trifecta containment ([I-D.draft-mcguinness-mission-runtime]). Per-task Missions already shrink blast radius; this composition uses them so that no single Mission ever holds untrusted input and an egress path at once. Named concretely: a quarantined ingestion Mission may read untrusted content but carries no external-communication authority; a clean output Mission may communicate but only over reviewed or derived artifacts, not the raw ingested content; and a bridge, a human review or a deterministic transformation between them, is recorded as evidence so the boundary crossing is auditable. Where a deployment wants the separation enforced within one Mission rather than across two, the metering profile's exclusivity control ([I-D.draft-mcguinness-mission-metering]) latches read-and-egress apart under a single approval. This turns the no-information-flow-control limit into a deployment architecture rather than an unmitigated gap.¶

13. Mission Assurance Levels

Two questions get asked of a Mission deployment: what to deploy for a goal, and what guarantee it has earned. They share one progression, so this document states a single set of levels, each carrying both facets, the document set and the proof obligations, and names them so a deployment, a procurement, or a review can cite one level. The levels are guidance, not a conformance class; every companion is optional and states its own scoped conformance. Because the family's strongest properties are deployment properties, not protocol properties (complete PEP placement, a trusted freshness source, and credential custody are things a deployment does, not things a token proves), a level is a claim, verifiable in the sense the runtime profile fixes ([I-D.draft-mcguinness-mission-runtime]), not a label: a deployment states the highest level it has earned in its Enforcement Scope Statement, and a consumer treats an unstated or unproven level as not claimed. The levels build on one another: a deployment adopts recording and governing the approved task (Baseline Issuance), then per-action enforcement (Runtime-Enforced, the Protocol MVP), then full agent safety (Governed and High-Assurance Agent), advancing to the level its risk warrants and stopping there.¶

The levels are one axis; the binding is an orthogonal one. Every level is reachable under any of the three Mission Issuer bindings, the OAuth Authorization Server, the standalone Mission Authority Server, or the AAuth Person Server, and a deployment names its binding separately from its level; what a level grants varies with what the binding provides. The standalone MAS binding is the case that matters most: it provides the Mission record, lifecycle, and authority but no Mission-bound credential and no issuance gating, so under it the kill switch is the runtime layer alone, not the token gate, and a deployment states that. Binding is not a level.¶

The levels, cumulative:¶

Baseline Issuance:

the approved, anchored Mission record and its lifecycle: authority derived and committed at the approval event with the integrity anchors (the core). Where the binding issues credentials, issuance is bounded by the subset rule and gated on Mission state, which grants task-bound, auditable authority and a possession-independent kill switch at the issuance gate; it grants no per-action control, and outstanding tokens run to their own expiry. Under a partial-provision binding (the standalone MAS), Baseline grants governance and audit; no kill switch of any kind exists until a freshness surface (the half-step) and runtime enforcement (the next level) arrive, and a deployment states that; the issuance join ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) restores gated issuance at each consuming Authorization Server, and Baseline with it. Proof obligations: the anchored approval and, where credentials are issued, the subset rule. A deployment that adds only a freshness surface, Mission Status or introspection with a published staleness bound ([I-D.draft-mcguinness-oauth-mission-status]), gains state-aware reliance, a revocation cutoff within that bound, without per-action enforcement: a half-step into the next level, not a level of its own.¶

Runtime-Enforced (the Protocol MVP):

adds a PEP/PDP decision on every consequential action, a trusted state source with a published staleness bound, parameter binding, and runtime evidence ([I-D.draft-mcguinness-mission-runtime] and its AuthZEN binding). Grants per-action enforcement and revocation bounded, for gated classes, by the staleness bound plus the permit window plus the class's execution bound, and by token lifetime for ungated paths. This is the family's adoption wedge, the Protocol MVP: the smallest deployment that makes a Mission-bound token more than governance metadata, and every normative dependency it needs is ratified. Proof obligations: PEP-placement completeness and the declared freshness source and bound. Documents: Baseline plus runtime, its AuthZEN binding, and a freshness source.¶

Governed Agent (recommended for AI agents):

adds Consent Evidence and the harness, growing with Child Delegation, Expansion, and Orchestration as needed. Grants consent-rendering evidence and session-continuity discipline. Documents: Runtime- Enforced plus consent-evidence and the harness.¶

High-Assurance Agent:

adds the guarantees that resist a compromised agent. Two named claims live at this level, each with proof obligations the runtime profile fixes. Agent-compromise-resistant enforcement: mediated credential custody, no unmediated path, action-bound approval for the high-consequence classes, and an active-freshness state source, so a compromised agent cannot unilaterally take a high-consequence action for which it does not hold a mediated credential. Trifecta containment: least exposure, the harness taint rule enforced as a MUST, and full mediation of the external-communication and external-commitment classes with the egress-channel enumeration, so an injected agent cannot egress on the strength of untrusted content alone. These are named high bars, never implied by basic adoption; a deployment MAY bind its Enforcement Scope Statement to execution-environment attestation so a claim is technical rather than organizational ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-harness]).¶

Every level above Baseline Issuance also carries the cross-cutting obligations its mechanisms imply: operation-profile normalization where duration or parameter digests are metered ([I-D.draft-mcguinness-mission-metering], [I-D.draft-mcguinness-mission-authzen]), evidence retention for the audit horizon, and a registration schedule where audit transparency is run ([I-D.draft-mcguinness-mission-audit]). The evidence levels are accountability, not prevention: they make what was recorded tamper-evident, not what was perceived true or what was never recorded present.¶

14. The Mission Deployment Profile

The Mission Assurance Levels (Section 13) name both what to deploy and what may be claimed, but a claim is only checkable if a deployment states, concretely, what it enforces and what it leaves outside the boundary. The Mission Deployment Profile is that system-level artifact: a single publishable manifest that composes the per-layer scope statements (the runtime profile's Enforcement Scope Statement, the harness execution-environment scope statement, the MAS mapping contract where used) into one object an auditor, a procurement, or a security review can read. It is non-normative in shape here; a profile or deployment fixes the exact serialization.¶

Its distinguishing field is residual_risks: the profile is not credible unless it states, in the same object as its guarantees, what it does not cover. An illustrative shape:¶

{
  "profile": "mission-governed-agent-runtime",
  "assurance_level": "high-assurance-agent",
  "mission_issuer": "https://mas.example.com",
  "state_sources": [
    { "type": "status_endpoint", "max_staleness_seconds": 30 }
  ],
  "issuance": {
    "binding": "oauth-core",
    "mission_claim_required": true,
    "refresh_gated_on_active_state": true
  },
  "runtime": {
    "pdp": "authzen",
    "pep_locations": ["tool-gateway", "browser-action-proxy"],
    "mediated_action_classes": [
      "irreversible_action", "external_commitment"
    ],
    "unmediated_exclusions": [
      "internal_reasoning", "local_cache_read"
    ]
  },
  "credential_custody": {
    "held_by": "pep",
    "sender_constrained": true,
    "agent_receives_bearer_token": false
  },
  "harness": {
    "subagent_inheritance": "explicit_delegation_only",
    "resume_requires_active_state": true,
    "cached_credentials_revalidated": true,
    "secondary_egress_enumerated": true
  },
  "evidence": {
    "decision_evidence": true,
    "execution_evidence": true,
    "retention_days": 365
  },
  "residual_risks": [
    "unmediated local reasoning is outside enforcement",
    "revocation latency up to 30 seconds",
    "PEP compromise is not prevented"
  ]
}

Two deployments that both "support Mission" but publish different Deployment Profiles provide different security properties, and the profile is what makes that difference legible. A deployment claiming a level (Section 13) states it here and lists the residuals that level leaves.¶

15. Prevention, Detection, and Residue

Each layer earns a specific property and leaves a specific residue. Stated as a table so a claim cannot be read as more than it is:¶

The pattern is uniform: the family commits and checks what a party was shown, decided, or did; it does not make the human attentive, the producer honest, or the unmediated path disappear. Those are the residues the Mission Assurance Levels (Section 13) and the security model make a deployment state rather than assume.¶

16. Mission Requirements

The requirements the family answers, stated implementation-neutrally; each names its answering documents by short form (Section 17). They stand on their own: a reader evaluating another design can use them as a checklist. As a litmus, a design is Mission-based in this family's sense only when all of the following hold: the task is a durable, explicitly approved object rather than a session or a token; the approved intent and authority are integrity-committed at approval; authority is derived from the object and gated on its state; derived and delegated authority only narrows; consequential actions are checkable against the object at the point of use; and what was approved, shown, decided, and done is reconstructible from evidence. A design that relaxes one of these provides a different, weaker guarantee; the requirements below unpack them.¶

17. Mission Document Map

One line per document, grouped as the family groups them; the short form drops the draft-mcguinness- prefix. The naming encodes a boundary: profiles extending the Authorization Server's own surfaces keep "oauth" in their names; profiles defined against the substrate of Section 9 are named without it. This document is named without it because the architecture is substrate-neutral by construction.¶

Maturity is a dependency boundary. A Standards-Track profile never depends normatively on an experimental one: the experimental profiles (tagged below) extend the stable interface only through its declared seams, the controls extension of the core and the coordinated-extension rules of the evidence objects, and a Standards-Track document cites them informatively at most. An experimental profile that stabilizes crosses the boundary by reclassification, not by a stable document absorbing a dependency.¶

The model and its bindings:¶

oauth-mission:

The core issuance profile: the Mission, the approval event and anchors, the mission claim, the subset rule, state-gated issuance.¶

mission-authority-server:

The standalone Mission Issuer and the PDP join of ordinary credentials to Missions.¶

oauth-mission-issuance-grant:

The issuance join: MAS-minted grants an estate Authorization Server redeems at its token endpoint for Mission-bound, state-gated tokens.¶

mission-aauth:

The AAuth binding: the Person Server as Mission Issuer, the mission blob as the record under AAuth's s256 commitment, issuance gating at the token endpoint.¶

mission-substrate:

Normative requirements on any further binding of the model; the existing bindings and the core are unchanged by it.¶

Approval time:¶

mission-shaping:

Client-side shaping of a user's request into a candidate Mission Intent, as untrusted proposal.¶

oauth-mission-consent-evidence:

The consent_rendering_hash anchor and signed evidence of what the Approver was shown.¶

oauth-mission-approval:

Asynchronous approval over the deferred substrate.¶

oauth-mission-approval-revision:

Experimental: in-review narrowing revision of a deferred proposal.¶

Lifecycle:¶

oauth-mission-status:

The signed pull surface and the lifecycle endpoint, with suspended and completed.¶

oauth-mission-signals:

Experimental: a signed event per lifecycle transition, push or poll.¶

oauth-mission-expansion:

Widening through an approved successor Mission.¶

oauth-mission-progressive:

Experimental: policy-adjudicated expansion within a pre-consented ceiling.¶

oauth-mission-management:

Fleet enumeration and bulk lifecycle operations for operators and incident response; dry-run-first, per-Mission semantics.¶

oauth-mission-completion:

Per-entry discharge via the terminal_when constraint.¶

oauth-mission-cross-domain:

Single-hop projection of a Mission to another trust domain via the cross-domain grant.¶

Runtime enforcement:¶

mission-runtime:

The per-action decision contract: parameter binding, custody, fail-closed behavior.¶

mission-authzen:

The concrete decision-API binding and its Decision and Execution Evidence objects.¶

mission-metering:

Experimental: cumulative consumption bounds and the metering that enforces them.¶

Agent runtime:¶

mission-harness:

Binding sessions, queues, and sub-agent handles to Mission state; the mediated environment.¶

mission-orchestration:

Experimental: reversibility classes, unwind plans, and compensation after a stop.¶

Sub-agents:¶

oauth-mission-child-delegation:

Child Missions with lineage, strict-subset authority, cascade revocation.¶

oauth-mission-attenuation:

Experimental: narrower Mission-bound tokens minted offline; the kill switch preserved by runtime re-check.¶

Proof and portability:¶

mission-mandate:

A signed, portable statement of a Mission's committed facts; evidence, not a credential.¶

mission-audit:

Registration of Mission evidence in a SCITT Transparency Service; receipts verifiable offline.¶

Security model:¶

mission-security-model:

The trusted base in one view: what each component must achieve and what its compromise costs.¶

18. Security Considerations

This document introduces no mechanism and therefore no new security considerations. The consolidated trusted base and compromise analysis are the Mission Security Model's ([I-D.draft-mcguinness-mission-security-model]), and each profile's own Security Considerations remain normative.¶

19. IANA Considerations

This document makes no IANA request.¶

20. Informative References

[I-D.draft-mcguinness-mission-aauth]

McGuinness, K., "Mission-Bound Authorization for AAuth", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth.html>.

[I-D.draft-mcguinness-mission-audit]

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.

[I-D.draft-mcguinness-mission-authzen]

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-harness]

McGuinness, K., "Mission-Aware Agent Harnesses", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.

[I-D.draft-mcguinness-mission-mandate]

McGuinness, K., "Mission Mandate", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html>.

[I-D.draft-mcguinness-mission-metering]

McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.

[I-D.draft-mcguinness-mission-orchestration]

McGuinness, K., "Mission Orchestration and Unwinding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-orchestration.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-mission-security-model]

McGuinness, K., "Mission Security Model", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-security-model.html>.

[I-D.draft-mcguinness-mission-shaping]

McGuinness, K., "Mission Intent Shaping", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html>.

[I-D.draft-mcguinness-mission-substrate]

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

[I-D.draft-mcguinness-oauth-ai-agent-instance]

McGuinness, K., "OAuth 2.0 AI Agent Instance Profile", Work in Progress, Internet-Draft, draft-mcguinness-oauth-ai-agent-instance-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-ai-agent-instance-00>.

[I-D.draft-mcguinness-oauth-client-instance-assertion]

McGuinness, K., "OAuth 2.0 Client Instance Assertion", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-assertion-01, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-assertion-01>.

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[I-D.draft-mcguinness-oauth-mission-approval]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[I-D.draft-mcguinness-oauth-mission-attenuation]

McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-attenuation.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-completion]

McGuinness, K., "Mission Completion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-completion.html>.

[I-D.draft-mcguinness-oauth-mission-consent-evidence]

McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html>.

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-mcguinness-oauth-mission-expansion]

McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.

[I-D.draft-mcguinness-oauth-mission-issuance-grant]

McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-issuance-grant.html>.

[I-D.draft-mcguinness-oauth-mission-management]

McGuinness, K., "Mission Management for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-management.html>.

[I-D.draft-mcguinness-oauth-mission-progressive]

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

Acknowledgments

This document is part of the Mission-Bound Authorization work and maps the structure that its profiles establish individually.¶

Author's Address