| Internet-Draft | Mission Architecture | July 2026 |
| McGuinness | Expires 8 January 2027 | [Page] |
A Mission is a durable, approval-backed governance object for authorization: the approved task, with a lifecycle, that authority is derived for, bound to, and gated on. It is not a new way to express authority. The Mission model spans a core issuance profile, two further bindings, and optional companion profiles, and no single document shows how the pieces fit. This document is that structural view: the roles and components, the substrate primitives the companions consume, the layers the profiles form, the deployment patterns, and the requirements the family answers. It is Informational: it defines no protocol, object, or requirement, and every mechanism it names is defined by the profile it points to.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-mission-architecture/.¶
Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization.¶
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 8 January 2027.¶
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.¶
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.¶
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.¶
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.¶
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 near-term deployment is a control plane beside an unchanged OAuth estate; the direction is delegated authority management as a layer of its own.¶
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]).¶
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.¶
The user or system on whose behalf the Mission is approved, an
(iss, sub) pair recorded immutably at approval (the core).¶
The single accountable principal who approves the Mission; equal to the Subject for self-approval (the core's Single Accountable Approver section).¶
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]).¶
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.¶
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).¶
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]).¶
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]).¶
An append-only SCITT log [RFC9943] that registers Mission evidence as Signed Statements and issues receipts verifiable offline ([I-D.draft-mcguinness-mission-audit]).¶
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 MAS: | |
| | Mission-bound | | no tokens; the | |
| | tokens gated | | PDP joins | |
| | on state | | credentials | |
| +-------+--------+ +--------+--------+ |
+---------|-------------------|----------+
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
¶
One material action splits across these roles, and the family keeps each distinct and attributable rather than collapsing them into one "agent" identity:¶
the Subject, the token sub (the core).¶
the Approver, committed at the approval event (the core).¶
the shaper, with Shaping Evidence recording what it emitted ([I-D.draft-mcguinness-mission-shaping]).¶
the Mission Issuer at issuance (the core); the PDP per action ([I-D.draft-mcguinness-mission-runtime]).¶
the OAuth client, client_id on every derived token (the core).¶
the outermost act actor (the core's Delegation section).¶
the mediating PEP under mediated custody ([I-D.draft-mcguinness-mission-runtime]).¶
the executor of the capability source binding
([I-D.draft-mcguinness-mission-authzen]).¶
the audience-scoped token and the cross-domain local subject ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶
Attribution survives because no role is inferred from another: each is carried by its own construct, and the evidence layer records them together, in runtime evidence and the Mission Receipt ([I-D.draft-mcguinness-mission-runtime]), Consent Evidence, and the audit feed.¶
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.¶
An opaque, non-reused Mission Identifier with at least 128 bits of
entropy and no semantic content, plus issuer, the issuer URL of the
approving Mission Issuer; together they name exactly one Mission.
Home: the core's Mission Record and Mission Identifier Format
sections. Consumed by every companion: enforcement decisions,
evidence, harness bindings, the state surfaces, the audit statement
subject, and the Mandate all key on it.¶
The states of Section 3, open to companion-defined states, with
the only-active rule, fail-safe unrecognized states, and a
freshness source with a stated staleness bound. Home: the state space
and the only-active rule are the core's (its Mission Lifecycle and
Gating section); the freshness mechanisms and staleness bounds are
the status and runtime profiles'; Status and Signals add the
observation surfaces. Consumed by the runtime layer (per-class
re-check, fail closed on staleness), the harness (pause, suppress,
terminate), the orchestrator (the unwind trigger), and the Mandate
(state only as of minting).¶
A committed object is hashed over an envelope domain-separated by
typ and issuer-bound by iss, canonicalized by fixed rules, and
encoded with an algorithm prefix a verifier recognizes or rejects;
the typ space is an extension point for new committed objects.
These are commitment anchors, not enforcement proofs: intent_hash
and authority_hash prove what was approved and committed, not that
the derivation was the semantically correct reading of the intent,
and a narrowed-token Resource Server enforces the authority it
receives rather than reconstructing authority from a hash of a full
set it does not hold ([I-D.draft-mcguinness-mission-security-model]).
Home: the core's Integrity Anchors and Canonicalization Rules
sections, with the extension rule in its Extensibility section.
Consumed by Consent Evidence (consent_rendering_hash), Shaping
(Shaping Evidence), the runtime layer and AuthZEN binding
(mission-policy-view), Orchestration (unwind_plan_hash), the
Mandate (the encoded digest form), and Audit Transparency (the
committed evidence types it registers).¶
"Mission-bound" is a specific claim, and three token shapes are worth distinguishing so a weak one is not read as the strong one:¶
a Mission-referenced token carries a Mission identifier only;¶
a Mission-derived token carries authority derived from an active Mission; and¶
a Mission-bound token is Mission-derived and additionally active-state gated, subset-constrained, and refresh-gated (the core's conformance rule).¶
Only the third earns the term: a mission claim alone is a reference,
not Mission-bound authorization. The family reserves "Mission-bound"
for that class.¶
A credential carrying the mission claim (id, issuer,
authority_hash) and Mission-derived authorization details, issued
only while the Mission is active. Home: the core's Mission-Bound
Access Tokens and The Mission Claim sections.¶
This is the binding-dependent primitive, and it is exactly where the
bindings split. The OAuth and AAuth bindings provide it (the AAuth
auth token carries the mission claim under per-request signature
coverage, [I-D.draft-mcguinness-mission-aauth]); the standalone
binding does not: the MAS's Mission Substrate section states that a
MAS provides every other primitive unchanged and provides neither
this credential nor issuance gating
([I-D.draft-mcguinness-mission-authority-server]). The seam is the
runtime profile's Mission binding establishment step
([I-D.draft-mcguinness-mission-runtime]): the credential carries
the Mission reference where the binding provides one, and a binding
without it supplies an externally established reference, verified
under a join the binding defines, which the MAS profiles as its
Mission Join. Offline Attenuation attenuates this credential and the
token-carriage aspects of delegation ride it, so both require it;
the companions that need a credential-to-Mission association (the
runtime layer and the harness) route through the binding
establishment step,
which is what makes the standalone binding possible.¶
The deployment-declared retention window for the Mission record and its evidence: at least the Mission's lifetime plus a declared post-terminal period. Home: the core's Mission Record section. Consumed by Consent Evidence, runtime evidence, and Audit Transparency for retention; by the MAS for record retention; and by the security model's retention analysis.¶
Five validity horizons govern reliance, each with its own setter, checker, and consequence; implementations most often err by conflating them:¶
exp:set by the issuer AS, capped by the Mission's expires_at; checked
by every consumer of the token. Past it the credential is dead and
refresh re-enters the issuance gate.¶
expires_at:set by the Mission Issuer; checked at the issuance gate, by the
PDP, and by state consumers. Off active, derivation stops and
consequential actions refuse.¶
fresh_until:set by the status responder; checked by status consumers. Past it a cached state report may not be relied on and is re-fetched.¶
set by the PDP; checked by the executing PEP. Past it the permit is void and a new decision is required.¶
set by the approval surface; checked by the PDP. Past it an action-bound approval no longer authorizes the action it named.¶
The horizons compose by minimum: reliance at any moment requires every applicable horizon to be open, and no horizon substitutes for another.¶
For a new binding this checklist is now normatively stated by Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]); this section remains the informative summary, and the three existing bindings remain authoritative for themselves.¶
Another mission-based protocol hosts the substrate-neutral profiles unchanged when it provides:¶
a unique, opaque Mission identifier with an authoritative issuer;¶
the lifecycle state space with the only-active rule, fail-safe
unrecognized states, and a freshness source with a staleness bound;¶
an Authority Set representation with a subset rule and a shared constraint vocabulary;¶
the integrity-anchor envelope and canonicalization for every object it commits;¶
an audit horizon over the record and its evidence;¶
published key material: the issuer's signing keys, resolvable by the verifiers of its signed artifacts; and¶
optionally, a Mission-bound credential carrying the mission
claim; a substrate that omits it composes as the standalone
binding does, and the credential-carriage profiles do not apply.¶
Individual profiles name further inputs in their Mission Substrate sections: the evidence types and their canonical bytes for audit transparency, and the intent submission channel for shaping. A binding also owes the substrate's approval-fidelity requirement: the approval event it runs must produce the record, anchors, and disclosure with the fidelity the substrate requirements fix ([I-D.draft-mcguinness-mission-substrate]). The per-profile Mission Substrate sections remain the authoritative per-consumer statements of this interface; this section consolidates them and adds nothing further.¶
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. Every layer below is a lever that narrows 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. The family is that set of levers; no single one closes the gap, and a deployment composes the ones its risk warrants.¶
The family organizes along a verb spine: each layer answers one question, sits on one trust boundary, and is owned by named documents.¶
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
prove Consent Evidence, Mandate, Audit
analyze Security Model (the trusted base)
¶
The question: how does a user's request become a candidate Mission Intent? The boundary: the client side; output is untrusted until the Mission Issuer validates and narrows it. Owner: Intent Shaping ([I-D.draft-mcguinness-mission-shaping]); the proposal enters via Pushed Authorization Requests [RFC9126], the MAS submission endpoint, or the AAuth Person Server's mission endpoint.¶
The question: how does a proposed task become an approved, committed Mission? The boundary: the Mission Issuer's own; the approval event is where trust is created. Owners: the three bindings ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-mission-authority-server], [I-D.draft-mcguinness-mission-aauth]), Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) committing the disclosure shown to the Approver, and Deferred Approval ([I-D.draft-mcguinness-oauth-mission-approval]), the OAuth binding's asynchronous path, with an experimental companion adding an in-review narrowing negotiation; the standalone and AAuth bindings are natively asynchronous. Where the experimental progressive authorization companion is used, the initial approval also consents an authority ceiling for later staged widening ([I-D.draft-mcguinness-oauth-mission-progressive]).¶
The question: how do consumers observe Mission state, and how does authority grow or retire mid-task? The boundary: between the issuer and every consumer relying on state. Owners: Status, the signed pull surface with a lifecycle endpoint ([I-D.draft-mcguinness-oauth-mission-status]); Signals, the push complement ([I-D.draft-mcguinness-oauth-mission-signals]); Expansion, widening only via an approved successor ([I-D.draft-mcguinness-oauth-mission-expansion]); Completion, per-entry discharge ([I-D.draft-mcguinness-oauth-mission-completion]); and Management, fleet enumeration and bulk lifecycle for operators ([I-D.draft-mcguinness-oauth-mission-management]).¶
The question: is this specific action, with these parameters, permitted under this Mission now? The boundary: the last controllable point between agent and resource. Owners: the runtime profile, the decision contract with parameter binding, custody, and fail-closed behavior ([I-D.draft-mcguinness-mission-runtime]); its AuthZEN binding, the concrete decision API and evidence objects ([I-D.draft-mcguinness-mission-authzen]).¶
The question: how does governed work start, persist, pause, and unwind when Mission state changes? The boundary: the operator's execution environment around the agent. Owners: the harness, binding session continuity to Mission state ([I-D.draft-mcguinness-mission-harness]); Orchestration, unwinding in-flight work through reversibility classes and recorded unwind plans ([I-D.draft-mcguinness-mission-orchestration]).¶
The question: how does authority reach a sub-agent without widening? The boundary: between principals acting under one approval. Owners: Child Delegation, child Missions with lineage, strict-subset authority, and cascade revocation ([I-D.draft-mcguinness-oauth-mission-child-delegation]); Offline Attenuation, narrower Mission-bound tokens minted off the issuer's hot path ([I-D.draft-mcguinness-oauth-mission-attenuation]). Offline attenuation requires the runtime enforcement layer: its kill switch is the runtime state re-check. Both build on the actor chain of the core's Delegation Within a Mission section.¶
The question: how is one Mission honored in another trust domain? The boundary: a trust boundary the origin does not control, where the verifier holds no session with the issuer. Owner: Cross-Domain Projection, a single-hop grant that carries the Mission's identifier, issuer, and authority hash into a partner domain unchanged, where a Resource AS mints a local token bounded by the projected authority ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Projection preserves authority across the boundary rather than narrowing it to a sub-actor, which is why it is a distinct verb from Delegate; downstream revocation latency is the local token lifetime.¶
The question: what can a party outside the deployment verify about what was approved and done? The boundary: across trust domains and time; the verifier holds no session with the issuer. Owners: Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); the Mandate, a signed, portable statement that authorizes nothing ([I-D.draft-mcguinness-mission-mandate]); the Mission Receipt, portable evidence of an action taken under a Mission ([I-D.draft-mcguinness-mission-runtime]); Audit Transparency, the append-only evidence log ([I-D.draft-mcguinness-mission-audit]).¶
The question: which components must be trusted, and what does each one's compromise cost? The boundary: the whole system. Owner: the Mission Security Model ([I-D.draft-mcguinness-mission-security-model]).¶
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 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.¶
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]).¶
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 reached 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. 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:¶
authority derived and committed at the approval event with the integrity anchors, issuance bounded by the subset rule, and derivation gated on Mission state (the core). 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. Proof obligations: the anchored approval and 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.¶
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 by the staleness bound plus token lifetime. 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.¶
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.¶
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.¶
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.¶
The Mission Assurance Levels (Section 7.1) 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 7.1) states it here and lists the residuals that level leaves.¶
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:¶
| Mechanism | Prevents | Detects | Does not solve |
|---|---|---|---|
| Core issuance | over-issuance beyond the approved authority; issuance after revocation or expiry | the approved authority (anchored) | action-time misuse within scope |
| Runtime enforcement | an unauthorized action on a mediated path | each PDP/PEP decision (evidence) | actions on an unmediated path |
| Consent Evidence | silent divergence between what was shown and what was committed | the rendered disclosure | whether a human perceived or understood it |
| Audit Transparency | undetectable log tampering or omission (under expected registration) | the evidence timeline | a producer logging a false record |
| Mandate | reliance on unverifiable committed facts | portable Mission facts | authority (it grants none) |
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 7.1) and the security model make a deployment state rather than assume.¶
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:¶
| Derivation mode | Portability status |
|---|---|
| Client proposes concrete authority; AS narrows | Interoperable default |
| AS derives from structured Intent fields | Profile-specific |
| AS derives from free text | Local, non-portable unless profiled |
| LLM-assisted derivation | Advisory unless a deterministic policy commits the output |
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.¶
The requirements the family answers, stated implementation-neutrally; each names its answering documents by short form (Section 12). They stand on their own: a reader evaluating another design can use them as a checklist.¶
R1: The task an agent pursues is a durable, structured, approved object (oauth-mission; mission-authority-server).¶
R2: The task and its derived authority are integrity-committed at approval, reproducible from the record alone (oauth-mission).¶
R3: Task proposals are untrusted input: fields the agent can influence never derive, widen, or gate authority (oauth-mission; mission-shaping).¶
R4: The derived authority is disclosed to the Approver before it takes effect, and the approval covers it (oauth-mission).¶
R5: A single accountable Approver is recorded immutably on the object (oauth-mission).¶
R6: What was shown at approval is committed and reconstructible by an auditor (oauth-mission-consent-evidence).¶
R7: Approval can be asynchronous, and any in-review negotiation only narrows (oauth-mission-approval; the experimental oauth-mission-approval-revision).¶
R8: Reliance is gated on task state: only active permits it,
and unrecognized states fail safe (oauth-mission).¶
R9: Revocation is independent of credential possession, and state changes propagate by pull or push (oauth-mission; oauth-mission-status; oauth-mission-signals).¶
R10: A task can be suspended and resumed without being terminated (oauth-mission-status).¶
R11: Authority widens only through a fresh approval that creates a successor (oauth-mission-expansion).¶
R12: Authority retires per entry when the work an entry served is done (oauth-mission-completion).¶
R13: Derived and delegated authority only narrows (oauth-mission; oauth-mission-attenuation).¶
R14: Sub-agents receive authority by explicit delegation with lineage, fan-out control, and cascade revocation, never by session ancestry (oauth-mission-child-delegation).¶
R15: Each consequential action is checked at the point of use, the permit bound to the concrete parameters (mission-runtime; mission-authzen).¶
R16: When a task stops, governed work stops with it and in-flight work unwinds safely (mission-harness; mission-orchestration).¶
R17: Task evidence is tamper-evident and verifiable outside the deployment (mission-audit; mission-mandate).¶
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 5 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.¶
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.¶
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.¶
This document makes no IANA request.¶
This document is part of the Mission-Bound Authorization work and maps the structure that its profiles establish individually.¶