Mission Security Model

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 22 February 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

The Mission model treats the agent as part of the attack surface: an agent may be prompt-injected or compromised, and the suite's purpose is to bound what such an agent can do, not to make it trustworthy ([I-D.draft-mcguinness-mission-runtime]). Bounding the agent means relying on other components: the Mission Issuer that derives authority and, where it also issues tokens, gates issuance (an Authorization Server, a standalone Mission Authority Server, or an AAuth Person Server), the enforcement points that evaluate each action, the harness that removes unmediated paths, and a set of optional services. Those components are the trusted base of the family's delegated-authority layer: the parts that, if compromised, degrade or void the guarantees the suite otherwise provides. Everything on the other side of that line, the agent that executes the task and the shaper that authors its proposal, is untrusted (Section 5).¶

Each profile documents the security considerations local to its own mechanism. What no single profile provides, and what a reviewer or a deploying operator needs, is the consolidated picture: the full trusted base in one place, what each component must achieve, what it assumes of the others, and what its compromise costs. This document is that picture.¶

This document defines no new mechanism, claim, or wire format. It is a model that aids review and deployment; the normative requirements live in the profiles it references.¶

2. Status: An Informational Model

This document is Informational. It does not place normative requirements on implementations; the enforcement obligations are defined by the selected binding and its companions (for the OAuth binding, [I-D.draft-mcguinness-oauth-mission]). Where this document uses words like "must," it describes an expectation the consolidated model places on a deployment that claims the suite, realized by the referenced profile, not a new conformance requirement of its own.¶

3. Conventions and Terminology

This document uses Mission, Mission Issuer (the Authorization Server in the OAuth binding; the Mission Authority Server in the standalone binding; the AAuth Person Server in the AAuth binding, [I-D.draft-mcguinness-mission-aauth]), Policy Enforcement Point (PEP), Policy Decision Point (PDP), Approver, Subject, agent, Authority Set, and Mission state as the OAuth binding ([I-D.draft-mcguinness-oauth-mission]) and the runtime profile ([I-D.draft-mcguinness-mission-runtime]) define them; each peer binding carries its equivalents per its Mission Substrate Statement. It uses Mission Shaper as defined in [I-D.draft-mcguinness-mission-shaping], Management Client as defined in [I-D.draft-mcguinness-oauth-mission-management], and Mission Assurance Levels as defined in [I-D.draft-mcguinness-mission-architecture].¶

4. Mission Substrate

This model describes the components and trust relationships of the Mission model, not of OAuth 2.0 mechanics. Its analysis rests on the substrate kernel every binding provides: the Mission reference and its controller, the state space with its only-active rule, the governance gate, and bounded reliance. Entries conditioned on optional capabilities apply where the selected binding claims them in its Mission Substrate Statement, and the selected binding's own document is the normative owner of the cited surfaces: an authority representation with a subset rule (Structured Authority), the integrity-anchor envelope, and a Mission-bound credential (Credential-Bound). A binding without that credential supplies an externally established Mission reference instead, verified under the runtime profile's Mission binding establishment step ([I-D.draft-mcguinness-mission-runtime]); a binding without a capability inherits the corresponding entries as inapplicable, not as failures. The OAuth binding [I-D.draft-mcguinness-oauth-mission] is the realization whose concrete surfaces this model's entries cite, as the family's first-authored binding; a different binding re-derives the substrate-specific entries against its own surfaces, and the model-level entries apply as written. [I-D.draft-mcguinness-mission-substrate] consolidates the primitives a further binding provides and points at where each is normatively defined; it names the seven optional capabilities the consuming profiles declare against (Lifecycle-Gated Authorization, State-Observable, Structured Authority, Monotonic Derivation, Credential-Bound, Independently Verifiable, and Portable Evidence), and as an Informational analysis rather than a substrate-neutral profile this document is not bound by the substrate's rule that a consumer declare the capabilities it consumes; each profile's own consumption declaration is authoritative.¶

5. The Untrusted Agent

The agent is not in the trusted base. The model assumes the agent can be prompt-injected, can be compromised, and can attempt any action its position allows. Every guarantee below is a bound on what such an agent can achieve, and is stated relative to a trusted base that excludes the agent. Two structural choices carry this:¶

• Authority is fixed by an approval the agent cannot move. Authority is derived by the Mission Issuer and committed at the approval event, which may be asynchronous ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-oauth-mission-approval]); the agent proposes but does not grant, and intent fields the agent can influence are inert.¶

• The credential whose misuse is unacceptable is not held by the agent. Under mediated execution ([I-D.draft-mcguinness-mission-runtime]) the PEP holds the sender-constraint key, so a compromised agent cannot present a high-consequence credential directly.¶

The agent and harness boundary assumes an isolation boundary between them: process, host, or service separation within a single operator. Without that separation, agent compromise and harness compromise are one event, and the harness-compromise degradation (Section 6) applies to a compromised agent. A deployment claiming the runtime profile's agent-compromise-resistant enforcement therefore isolates the mediating PEP and its key custody from agent-facing components; the harness profile requires this separation ([I-D.draft-mcguinness-mission-harness]).¶

The untrusted side extends to everything that authors the task. Where a Mission Shaper turns a prompt or an upstream trigger into a candidate Mission Intent ([I-D.draft-mcguinness-mission-shaping]), the shaper is client-side machinery on the agent's side of the trust boundary: its proposal reaches the Mission Issuer as untrusted input, authority is created solely by the issuer's validation and the approval event, and Shaping Evidence is inert audit material. A compromised or manipulated shaper can propose a hostile Mission; it cannot approve one, and what it proposed is what the derivation bounds and the Approver reads.¶

6. The Trusted Base

The following components are trusted to varying degrees. For each: what it must achieve, what it assumes of the others, and how its compromise degrades the guarantees. The authoritative security considerations are in the cited profile.¶

Authorization Server (Mission Issuer):

The root of trust. It derives the Authority Set, runs the approval event, commits the integrity anchors, and gates issuance on Mission state. It must derive faithfully and gate correctly; it assumes the Approver is authenticated and the agent is untrusted. Its compromise voids the model (Section 11 names the key-custody statement a deployment publishes for this assumption): a compromised issuer can mint arbitrary authority. This is the strongest trust assumption in the suite ([I-D.draft-mcguinness-oauth-mission]).¶

Resource Authorization Server (cross-domain):

When cross-domain access is used, a resource-side Authorization Server mints local Mission-bound tokens that the Mission's issuer cannot observe. It must mint only within the audience and lifetime the cross-domain grant scopes. Its compromise mints arbitrary authority within its own domain under the Mission's name; the damage is bounded by audience scoping, short grant lifetimes, and audit, not by the issuer, which never sees these tokens ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

Mission Authority Server (standalone binding):

When the standalone Mission Authority Server binding is used, a service outside the OAuth Authorization Server implements the Mission Issuer role, while the deployment's tokens remain ordinary and carry no Mission binding. It must run the approval ceremony faithfully, keep the Mission record and its anchors intact, and serve accurate Mission state. Its compromise is equivalent to Mission Issuer compromise (forged approvals, altered records, false state), with one addition. In this mode the PDP's credential-to-Mission join is the only binding between a presented credential and a Mission, so a compromised Mission Authority Server combined with the PDP's trust in it yields arbitrary attribution of authority to any credential the join accepts. Where Mission Join Assertions are used, the PDP's join trust concentrates in one MAS signature, and the MAS may hold introspection credentials at the Authorization Server, a cross-component channel whose compromise forges joins ([I-D.draft-mcguinness-mission-authority-server]). Where consuming Authorization Servers redeem its issuance grants ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), a compromised MAS additionally mints authority those servers honor, reaching token issuance across the estate.¶

AAuth Person Server (AAuth binding):

When the AAuth binding is used, the AAuth Person Server implements the Mission Issuer role for that protocol's native missions, and it also issues or gates every AAuth auth token, so issuance gating holds at the PS as it does at the AS in the OAuth binding. Its compromise is Mission Issuer compromise plus token-issuer compromise: forged approvals, altered records, false state, and freely minted or ungated auth tokens ([I-D.draft-mcguinness-mission-aauth]).¶

Policy Enforcement Point (PEP):

Sits at the last controllable boundary before an action and obtains a permit before each consequential action; under mediated execution it holds the sender-constraint key. It must be at the last boundary and must not act without a permit; it assumes the harness leaves no unmediated path. A compromised PEP can decline to consult the PDP or ignore its decision; the suite does not prevent this, and evidence makes it detectable after the fact, not in the moment. Under mediated custody the PEP also holds the sender-constraint keys for the mediated classes, so its compromise is high-consequence credential theft: the attacker gains usable keys and can take the very off-path actions mediation was meant to prevent. Per-class credentials with distinct cnf keys and a minimal custody replica topology bound how far one compromised PEP reaches ([I-D.draft-mcguinness-mission-runtime]).¶

Policy Decision Point (PDP):

Evaluates each action against the Mission and returns a permit or deny. It must evaluate faithfully and fail closed; it assumes the inputs the PEP supplies are authentic. A compromised PDP can return arbitrary decisions; as with the PEP, evidence detects this after the fact but does not prevent it ([I-D.draft-mcguinness-mission-runtime]).¶

Mission state source:

Reports current Mission state for the freshness the runtime layer requires, whether by introspection, the Status surface, pushed Signals, or a materialized policy view. It must report accurately within the staleness bound and be authenticated and integrity-protected. A compromised or spoofed state source can report active for a Mission that is revoked, defeating the kill switch; the runtime layer fails closed when state cannot be established within the bound. The materialized policy view carries authority as well as state, so a stale or tampered view feeds the PDP wrong authority; its integrity and staleness bounds are part of the trusted base ([I-D.draft-mcguinness-oauth-mission-status], [I-D.draft-mcguinness-oauth-mission-signals], [I-D.draft-mcguinness-mission-runtime]).¶

Harness:

Establishes the execution environment in which governed work has no unmediated path to the actions the PEP mediates, and binds sessions, queues, and caches to Mission state. It must ensure no unmediated egress and must re-check state. A compromised harness can hand the agent an unmediated path, which defeats mediated execution for the classes that path reaches ([I-D.draft-mcguinness-mission-harness]).¶

Orchestrator:

When multi-step unwinding is used, it drives compensation of in-flight work after a Mission stops. It must derive each step's reversibility class from a trusted source, and must compensate only under a documented authority basis: resource policy (resource_policy) or a separate remedial Mission ([I-D.draft-mcguinness-mission-orchestration]). Its compromise converts the kill switch into a channel for unauthorized remedial actions, driving compensating writes under the guise of unwinding.¶

Metering state:

When consumption metering is used, the PDP and the metering state behind it enforce the consented consumption bounds by atomic check-and-decrement, with reserve-and-commit postures and duration leases. The metering must count every governed action exactly once across the deployment's decision points, and a deployment that cannot meter a consented bound must refuse rather than render it as enforced. Its compromise voids the volume bound but not the authority bound: a drained, reset, or bypassed meter lets a Mission consume without limit inside its approved scope, and a falsely exhausted meter is a denial of service. The metering state also holds the exclusivity latch: latch state whose loss or reset silently voids a consented separation-of-duty, an exposure distinct from counter drift. Under a multi-PDP topology the published consistency bound is the honest statement of the undercounting exposure ([I-D.draft-mcguinness-mission-metering]).¶

Management Client and endpoint:

When fleet management is used, an authorized Management Client enumerates the Missions a Mission Issuer holds and applies bulk lifecycle operations through a dry-run-then-execute exchange whose bulk token pins the evaluated membership. The endpoint must authenticate and authorize the Management Client, audit every call, and never expose the surface to the agents whose Missions it manages. Its compromise cannot mint authority, but it reaches the whole fleet: bulk revoke or suspend is fleet-wide work stoppage, bulk resume re-enables suspended authority wholesale, and enumeration yields the existence knowledge the status profile's anti-oracle rules deny to ordinary consumers ([I-D.draft-mcguinness-oauth-mission-management]).¶

Consent rendering layer:

Renders the approved authority to the Approver at the approval event. It must render faithfully what is committed. A compromised renderer can display something other than the committed disclosure; the rendering assurance ladder bounds this by degree, up to an Approver authenticator signing the disclosure commitment, but no server-side commitment proves what a human perceived ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

Access-request and approval workflow:

When requestable denials are used, this workflow adjudicates an agent's request for authority it discovers it needs, integrating the AuthZEN Access Request and Approval Profile ([I-D.draft-mcguinness-mission-authzen]). It must not auto-approve a high-consequence escalation without an independent approver. A compromised approval service can grant escalations the model would otherwise route to a human, so it is in the trusted base wherever the access-request flow is enabled ([I-D.draft-mcguinness-mission-runtime]).¶

Transparency Service:

When audit transparency is used, it is an append-only, non-equivocating log that issues inclusion receipts. It must not equivocate. A single compromised service can present different histories to different auditors; registering with more than one service makes equivocation detectable, but the non-equivocation guarantee is per-service ([I-D.draft-mcguinness-mission-audit]). The structural case needs no compromise: a service operated by the producer whose records it holds returns the auditor to trusting that producer's infrastructure, so the audit profile's cross-domain claim rests on operator independence or a second, independent service.¶

Event source:

When completion or trigger-based discharge is used, it reports whether a completion event has occurred. It must report accurately and be authenticated. A compromised event source can keep a discharged entry derivable or falsely discharge one; the Authorization Server fails closed when it cannot determine the event status ([I-D.draft-mcguinness-oauth-mission-status], Completion section).¶

Instance identity is identity substrate, like agent identity generally. The instance issuer or agent attester that mints instance assertions ([I-D.draft-mcguinness-oauth-client-instance-assertion], [I-D.draft-mcguinness-oauth-ai-agent-instance]) sits outside this model's trusted base, and its compromise forges actor attribution (who executed) without forging Mission authority (what was approved). A deployment that relies on instance-grade joins or instance-attributed evidence extends its documented trust statement (Section 11) to that issuer.¶

7. Cross-Cutting Assumptions

Four assumptions hold across the whole model:¶

• Sender-constrained credentials. Where Mission-bound tokens are sender-constrained (recommended by the OAuth binding, [I-D.draft-mcguinness-oauth-mission]), a token exfiltrated without its proof-of-possession key is unusable, and the model assumes the proof-of-possession mechanism is sound and keys are protected by their holder. Where a deployment issues bearer tokens instead, an exfiltrated token is usable until it expires, and the stolen-token residual (Section 9) applies in full.¶

• Fail-closed on authority, fail-safe on inert evidence. Wherever a trusted component cannot establish an authority-relevant fact it needs (Mission state, a completion event, a verifiable decision), the relying component refuses rather than proceeds; a deployment that fails open at any such point forfeits the guarantee that point protects. The same principle governs capability gaps: a consented consumption bound the deployment cannot meter is refused, not rendered as enforced ([I-D.draft-mcguinness-mission-metering]). Unavailability of inert evidence (a consent-evidence retrieval, the transparency feed, a Mandate) is recorded and is never by itself grounds for refusal ([I-D.draft-mcguinness-mission-audit]); tampered inert evidence is an integrity failure, handled by the profile that defines the artifact.¶

• Role-scoped trust anchors. A party trusted in one role (Mission issuer, evidence producer for one evidence type, SET transmitter, Transparency Service) is not thereby trusted in any other, and issuer trust is established by local policy or metadata, never inferred from being named inside a signed artifact ([I-D.draft-mcguinness-mission-audit], [I-D.draft-mcguinness-mission-mandate], [I-D.draft-mcguinness-oauth-mission-cross-domain]). The identity-assertion trust framework and its domain-authorized-issuer method ([I-D.draft-mcguinness-oauth-id-assertion-framework], [I-D.draft-mcguinness-oauth-domain-authorized-issuer]) are concrete publication and evaluation mechanisms for such policy.¶

• Authority does not move on inert input. purpose, success_criteria, and disclosure-only audit material are inert and cannot derive, widen, or gate authority; goal shapes authority only through the pre-approval derivation whose result the Approver reads and consents to, and is inert once the Mission is approved ([I-D.draft-mcguinness-oauth-mission]).¶

8. What the Model Does and Does Not Guarantee

Given an intact trusted base, the model's guarantees are these. Each is named, names the Mission Assurance Level ([I-D.draft-mcguinness-mission-architecture]) at which it is earned, and names the components that must be intact for it to hold; Section 6 is the failure analysis of those dependencies, and Section 11 is where a deployment states which of them it claims.¶

Bounded authority (Baseline Issuance):

A compromised or injected agent cannot exceed the approved Authority Set and cannot move authority by influencing inert intent; authority grows only by a fresh approval that supersedes the prior Mission ([I-D.draft-mcguinness-oauth-mission-expansion]), not by agent action. Rests on the Mission Issuer and, where the binding issues credentials, the issuance gate that bounds each token to the subset. Under the standalone binding no token carries the Mission and no issuance gate bounds it, so at Baseline nothing enforces the Authority Set: this guarantee is not available under that binding until runtime enforcement (the Runtime-Enforced level) supplies the PEP and PDP coverage it then rests on, and the Kill switch depends on the same coverage.¶

Kill switch (Baseline Issuance for issuance; Runtime-Enforced for action):

Revoking or expiring a Mission stops further issuance at once and stops governed action within a window this model states precisely (Section 10). Rests on the Mission Issuer, the Mission state source, and, for action, the PEP and PDP.¶

Per-action enforcement (Runtime-Enforced):

Every consequential action obtains a fresh permit against current Mission state and bound parameters, so an active Mission is not ambient standing authority. Rests on the PEP, the PDP, the state source, and the harness's no-unmediated-path condition.¶

Bounded consumption (Runtime-Enforced plus consumption metering):

A Mission cannot consume beyond its consented bounds even inside its approved scope ([I-D.draft-mcguinness-mission-metering]). Rests on the PDP, its metering state, and the PEP's settlement honesty.¶

Agent-compromise-resistant enforcement (High-Assurance Agent):

A compromised agent cannot unilaterally take a high-consequence action it does not hold a mediated credential for, nor acquire a fresh usable credential for one ([I-D.draft-mcguinness-mission-runtime]). Rests on all five conditions: mediated credential custody, with the sender-constraint key generated in the PEP and never transferred from the agent; no unmediated path to the mediated actions or to fresh usable credentials for them, issuance for the mediated classes restricted to attested mediating-PEP keys; action-bound approval for the high-consequence classes; an active-freshness state source; and an approval disclosure rendered by a component isolated from the agent, never agent-composed. The agent and harness isolation boundary underlies custody and rendering alike.¶

Trifecta containment (High-Assurance Agent):

An injected agent cannot egress on the strength of untrusted content alone: least exposure and the harness taint rule are mandatory requirements of the runtime profile, and the external-communication and external-commitment classes are fully mediated ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-harness]). Rests on the harness and on PEP coverage of every egress channel.¶

Attributable action (any level, per the evidence deployed):

What was proposed, approved, decided, and executed is recorded and, where audit transparency is used, tamper-evident ([I-D.draft-mcguinness-mission-audit]); the Mission Receipt is the portable per-action artifact ([I-D.draft-mcguinness-mission-runtime]). This is accountability, not prevention. Rests on the evidence producers and, for non-equivocation, the Transparency Service.¶

The strong claims are earned, not implied. In the base profiles two of the mechanisms behind agent-compromise-resistant enforcement (mediated credential custody and action-bound approval) are recommendations, not requirements, and a third, the agent-isolated rendering of the approval disclosure, is required only by the claim itself, while active-state freshness for the high-consequence classes and the no-unmediated-path rule for mediated classes (which covers both a path to those actions and a path to fresh usable credentials for them) are already base-profile requirements; a deployment that leaves any of the five conditions unmet does not obtain the guarantee. This matches the suite's front-door framing: adopting the profiles does not by itself make a deployment resistant to a compromised agent. The model makes misuse bounded and, where evidence is produced, attributable.¶

Earned is also not provable at the wire. The High-Assurance Agent claims name conditions a deployment satisfies, not something a token or a decision response proves: the execution-environment scope statement they rest on is self-declared ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-harness]), and absent independent evidence, a relying party cannot distinguish, from the protocol artifacts alone, a deployment that built the claimed isolation from one that merely published the claim. Execution-environment attestation is what closes that gap; the runtime profile requires it for the two High-Assurance Agent claims specifically, not for base conformance ([I-D.draft-mcguinness-mission-runtime]). Retained negative-conformance evidence is the complementary recommendation: it does not prove the claim at decision time, but it lets an auditor check afterward that the deployment ran the tests the claim implies ([I-D.draft-mcguinness-mission-runtime]). Short of attestation, the trust assumption is plain: an unattested High-Assurance claim is an organizational assertion, taken on trust, not a technical one.¶

It does not make a compromised trusted component safe. The compromise of each component degrades a specific guarantee, as listed in Section 6. It does not verify the agent's reasoning or the truthfulness of its outputs; semantic and intent verification are a non-goal of the suite ([I-D.draft-mcguinness-oauth-mission]). And it inherits the threat models of the substrates the companions profile (Token Exchange, Attenuating Agent Tokens, SCITT, Deferred Token Response), which those substrates own. Section 9 gives the per-adversary-move detail: what addresses each move, and the residual it leaves.¶

"On behalf of" is not treated as a permission model. The family splits what that phrase conflates: the Mission carries the approved task the agent pursues for the Subject; a derived token presents delegated authority without identity collapse, since sub remains the Subject, client_id remains the approved agent, and the act chain names who executed; and personal sanction is carried only by approval events (the approval event, action-bound approval), never inferred from token possession. Authority derived down this chain never exceeds its source (the subset rule), so broad "acting as" standing cannot be laundered out of a narrow approval.¶

9. Adversary Model and Coverage

The trusted base (Section 6) is the component view; this is the adversary view. The adversary is assumed to control the agent and the task proposal it submits (including a shaper's output, Section 5), to reach the content and inputs the agent processes (so it can attempt prompt injection), and to capture tokens in transit. The adversary is assumed not to break the cryptographic primitives, not to forge an authenticated component's signing key, and not to compromise a trusted-base component; those last two are the residuals of Section 6, and the table's final row only restates that exclusion.¶

The following maps each adversary move to the mechanism that addresses it and to what is explicitly not stopped. The residual is the honest part: it is what a deploying party still owns.¶

Compromised or injected agent acts beyond its task:

Addressed by authority committed at the approval event (Section 5) (issuance); per-action PDP check (runtime). Residual: misuse within the approved scope; low-consequence authority the agent legitimately holds.¶

Prompt injection tries to widen authority:

Addressed by the same approval-time commitment: the Intent's prose members (goal, constraints, success_criteria) are inert at derivation, never parsed for machine semantics; authority enters as the structured proposal the AS only narrows, and the Approver consents to the derived result ([I-D.draft-mcguinness-oauth-mission]). Residual: injected text can still drive actions already in scope.¶

Agent escalates through the request path (expansion, requestable denial,

¶

deferred approval):

Addressed by every widening is a fresh approval event: expansion supersedes rather than amends, access-request adjudication routes high-consequence escalation to an independent approver, and an approval revision can only narrow ([I-D.draft-mcguinness-oauth-mission-approval-revision]). Residual: rubber-stamping: an over-asked Approver approves an escalation like a considered one (the consent-fatigue residual).¶

In-scope volume abuse (budget drain, call flooding, egress volume):

Addressed by consumption metering where deployed: atomic check-and-decrement, reserve and commit, duration leases; a bound that cannot be metered is refused, not rendered as enforced. Residual: without metering, volume inside the approved scope is bounded only by Mission expiry; with it, the published multi-PDP consistency bound.¶

Stolen or exfiltrated token:

Addressed by sender-constraint (proof-of-possession); the high-consequence key is held by the PEP, not the agent (mediated execution). Residual: a token stolen together with its key; a bearer token, where the deployment does not sender-constrain, usable until it expires; soundness of the PoP mechanism.¶

Token replayed at another resource (confused deputy):

Addressed by permit bound to audience, resource, sub, client_id, and action; cross-domain grant single-use and audienced. Residual: correct binding configuration is the deployment's.¶

Parameters change between decision and use (TOCTOU):

Addressed by parameter binding; the digest is reverified at the executing PEP immediately before acting. Residual: the PEP must sit at the last controllable boundary.¶

Active Mission used as ambient standing authority:

Addressed by per-action runtime enforcement, state re-check, fail-closed on stale state. Residual: an issuance-only deployment gets audit, not action-time defense.¶

Revoked or expired Mission still acts (kill switch):

Addressed by issuance gating; runtime state re-check within the staleness bound; short token lifetimes. Residual: a window up to the staleness bound or token TTL; a spoofed state source (a trusted component).¶

Approver approves more than was shown:

Addressed by the rendered disclosure is committed; rendering-assurance ladder up to an authenticator-signed commitment. Residual: comprehension: no server-side commitment proves what a human perceived or understood.¶

Approver account, session, or authenticator compromised:

Addressed by the approval-event authentication floor and the Intent's controls.acr step-up hook, which a deployment raises for high-consequence Missions ([I-D.draft-mcguinness-oauth-mission]). Residual: a phished, hijacked, or coerced Approver approves a hostile Mission, and the evidence machinery then faithfully attests the attacker's Mission; account security and step-up strength are the deployment's.¶

Exfiltration of private data (the third leg of the lethal trifecta):

Addressed by external communication is a gated consequential action; harness leaves no unmediated path; session taint downgrades egress after untrusted input (optional; recommended, not required); least-exposure context minimization narrows what an injected agent sees (runtime, harness); the composite is claimable as trifecta containment (runtime). Residual: PEP-placement completeness; no information-flow control, so a sequence of in-scope steps can launder data; the quarantine pattern (separate ingestion and egress Missions) turns that limit into a deployment architecture ([I-D.draft-mcguinness-mission-architecture]).¶

Sub-agent fan-out abuse (Child Missions):

Addressed by child creation is issuer-adjudicated: strict-subset authority, expiry no later than the parent, fan-out controls, separate child actor identity, cascade termination when the parent ends, and child credentials never transit the parent. Residual: breadth within the fan-out policy is the deployment's; a permissive delegation policy is consented but wide.¶

One instance of a swarm is compromised (class-pinned multiplication):

Addressed by three kills that stay separable: revoke the one instance's credentials and its peers continue; disable the Agent Deployment at the registry, whose state the consuming decision point fails closed on ([I-D.draft-mcguinness-mission-architecture]); revoke the Mission and the whole body of work stops. Evidence distinguishes the instances because a sender-constraint key is never shared across a client's instances, the instance-profile rule mediated custody composes with ([I-D.draft-mcguinness-mission-runtime]). Residual: instance-grain attribution, and the narrowest kill, exist only where the instance substrate is deployed (Section 6); without it attribution collapses to the shared client_id, and containment falls back to the Deployment and Mission kills.¶

Emergent authority through coordination (independent Missions):

Addressed by the non-transitive Mission-to-Mission handoff rule: a work product crossing into a Mission is input, re-evaluated under the receiving Mission's own Authority Set, so a producing Mission's authority never transfers with the information it wrote ([I-D.draft-mcguinness-oauth-mission-work-products], promoted from the quarantine pattern of [I-D.draft-mcguinness-mission-architecture]); the legitimate path to act on what was read is a Child Mission bounded by the parent ([I-D.draft-mcguinness-oauth-mission-child-delegation]). Distinct from one swarm instance compromised above, which is legitimate class-pinned multiplication under one Mission: here multiple agents executing independently bounded work communicate through shared state, so discoveries, credentials, techniques, or intermediate results persist across runtimes and Missions, and individually acceptable actions compose into behavior no single Mission authorized. Residual: the handoff rule denies authority transfer per artifact but does not by itself bound this aggregate composition through an unmanaged carrier; shared-state effect classification, an audience envelope, and lineage-keyed aggregate bounds are anticipated defense-in-depth, not yet specified ([I-D.draft-mcguinness-oauth-mission-work-products]).¶

Injection steers discovery (the agent binds the attacker's resource):

Addressed by default-closed discovery (no consented ceiling, no binding), the tainted-session human floor for egress-capable bindings, resource identity pinning, the rule that self-declarations never classify consequences, and Discovery Evidence ([I-D.draft-mcguinness-mission-discovery]). Residual: an untainted session binding within an over-broad consented family; ceiling breadth is a consent-time decision.¶

Offline sub-agent fan-out abuse:

Addressed by capability monotonicity (narrow-only) and the runtime kill-switch re-check on the carried chain. Residual: fan-out breadth is unobserved by the issuer; bounded by depth and policy, not by the issuer.¶

Materialized-capability containment escape (Mission Containment):

Addressed two ways. Issuance-side, containment gates every future derivation, delegation, cross-domain projection, and offline attenuation root against the Effective Authority Set, and propagates a contain transition to the child Missions the contained entry justified ([I-D.draft-mcguinness-oauth-mission-containment], [I-D.draft-mcguinness-oauth-mission-child-delegation]). Runtime-side, a containment-aware PDP denies the contained portion of an already-issued token's authority at the next action, even though the Mission stays active ([I-D.draft-mcguinness-mission-runtime]). Residual: what neither reaches. A cross-domain grant already redeemed into a local token the origin issuer cannot observe, and an offline attenuation root already minted, are validated by a party that does not consult the origin Mission's overlay; each keeps producing authority for its own bounded lifetime, closed only by short grant and root lifetimes ([I-D.draft-mcguinness-oauth-mission-cross-domain], [I-D.draft-mcguinness-oauth-mission-attenuation]).¶

Effective-ceiling composition (depth, cross-domain hops, and child

¶

generations):

Addressed by each dimension bounding itself: per-domain depth reset at a cross-domain hop, per-Mission max_derivations that a child does not inherit from its parent, and issuer adjudication at each child generation ([I-D.draft-mcguinness-oauth-mission-cross-domain], [I-D.draft-mcguinness-oauth-mission-child-delegation]). Residual: the composed bound across all active dimensions, depth times domains times child generations, plus the aggregate derivations a child subtree can draw, can exceed what a single approval appears to authorize; disclosing the composed bound at the consent surface is a deployment's to add, and an aggregate consumption cap is the metering profile's role ([I-D.draft-mcguinness-mission-metering]).¶

Operator surface abused (fleet management):

Addressed by management Client authorization; dry-run-then-execute with a bulk token pinning the evaluated membership; every call audited; never agent-facing. Residual: a compromised Management Client stops or resumes Missions fleet-wide and learns Mission existence; it cannot mint or widen authority.¶

Audit tampered, dropped, or reordered:

Addressed by transparency: append-only log, inclusion receipts, non-equivocation. Residual: single-service equivocation (per-service only; register with several); a producer can still log a false record.¶

Agent fabricates results or acts on false data:

Addressed by not addressed. Residual: full: semantic and grounding verification are a non-goal; pair with a grounding layer if needed.¶

A trusted-base component is compromised:

Addressed by not addressed; evidence detects it after the fact. Residual: not prevented; degrades the specific guarantee per Section 6.¶

Ten residuals are worth stating on their own, because they are the limits most likely to matter and most often overstated away elsewhere:¶

• Comprehension. The suite can commit and bind what an Approver was shown; it cannot prove what the Approver perceived or understood. The consent-evidence profile narrows what it can reach: authority rendered as language rather than structure, and a disclosure the Approver can interrogate ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). Proof of comprehension stays out of reach; no electronic-consent scheme provides it.¶

• Anchor semantics. The integrity anchors commit objects, not the relationships between them: intent_hash commits the approved intent, authority_hash the consented Authority Set, proposal_hash, where an authority proposal was submitted, the authority the client asked for, and that the authority faithfully serves the intent is a derivation policy fact (a recommendation, auditable via policy_version), not something any of the hashes proves. And authority_hash commits the full consented set, which a per-Resource-Server token, carrying a narrowed subset, does not contain: at such a Resource Server the anchor is an audit correlator, not an enforcement input, and the subset relationship it stands for is trust in the issuer's signature, not a per-token cryptographic proof. Enforcement value from the anchor accrues only to a full-set holder (an auditor, a Mandate verifier, a full-set Resource Server).¶

• Standalone-join ceiling. Under the standalone binding, an uncompromised join still has an assurance ceiling: the PDP's join proves the acting credential belongs to the subject and client the Mission names, but no mechanism in that mode proves the credential was derived under the Mission, and mapping coarseness and same-party misattribution remain ([I-D.draft-mcguinness-mission-authority-server], [I-D.draft-mcguinness-mission-substrate]). The credential-to-Mission association is an inference the join bounds, not a carried fact.¶

• Narrowing is typed. The subset rule, the "authority only narrows" guarantee, is defined over mission_resource_access and its Common Constraints. Authority expressed in another authorization_details type, including an opaque policy-language entry, has no defined subset relation: it is carried as approved and is neither narrowed nor delegated nor projected across a trust boundary. The strong narrowing guarantee therefore weakens exactly as a deployment moves authority into expressive policy-language entries, which is a design trade a deployment should make knowingly.¶

• In-scope volume. The Authority Set bounds what a Mission may touch, not how much. Consumption metering ([I-D.draft-mcguinness-mission-metering]) is the extension that bounds volume; where it is not deployed, an agent whose every action individually passes is limited only by Mission expiry, and the first row of the coverage table is unbounded in this dimension.¶

• Consent fatigue. The model multiplies approval moments: the approval event, expansion approvals, action-bound approvals, and review queues. A deployment that over-asks trains its Approvers to rubber-stamp, and a rubber-stamped approval carries the same commitments as a considered one; the evidence layer proves what was shown and decided, not that attention was paid. The mitigations are structural, not evidentiary: reserve action-bound approval for the highest-consequence actions ([I-D.draft-mcguinness-mission-runtime]), and use a pre-consented ceiling with policy-adjudicated drawdown where growth is anticipated ([I-D.draft-mcguinness-oauth-mission-progressive]), so the human moments that remain are rare enough to be read. The consent-evidence profile keeps those moments readable and questionable: a translation floor over the rendered authority and Disclosure Interrogation ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

• Single-service equivocation. Transparency is non-equivocating only per service; a deployment that needs that property checked registers with more than one independent service.¶

• Offline breadth. Offline attenuation ([I-D.draft-mcguinness-oauth-mission-attenuation]) bounds each child to a narrowing of its parent, but the issuer does not observe how many children are minted; breadth is bounded by depth and policy, not by the issuer. Child Delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]) is the observed alternative: creation is issuer-adjudicated, fan-out is controlled, and termination cascades. The trade between the two is availability against observation, and a deployment that chooses offline minting accepts the unobserved breadth.¶

• Self-graded enforcement. The strongest claims of Section 8 rest on a self-declared execution-environment scope statement ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-harness]): the wire carries no signal that lets a relying party tell a deployment that built the claimed isolation from one that only published the claim. Execution-environment attestation narrows this for the High-Assurance Agent claims, where it is required ([I-D.draft-mcguinness-mission-runtime]); elsewhere the claim is an organizational assertion taken on trust, and retained negative-conformance evidence ([I-D.draft-mcguinness-mission-runtime]) is what lets an auditor check it after the fact rather than at the wire.¶

• Availability. The model fails closed everywhere a trusted component cannot establish the fact it needs (Section 7), which trades availability for safety. An attacker who degrades a state source, an event stream, or a PDP does not gain unauthorized action, but converts the attack into work stoppage and, for in-flight work, unwind activity. A deployment provisions state-source, event-stream, and PDP availability accordingly, because under this model their outage stops governed work rather than loosening it.¶

10. Revocation-to-Action Latency

The kill switch is not instantaneous. Between the moment a Mission is revoked and the last possible consequential action under it there is a window, and its size is a composition of the mechanisms a deployment runs. The following non-normative table names the governing parameter at each layer; the end-to-end worst case for an action class is the tightest layer the deployment enforces for that class. The tables in this section read on the credential-issuing bindings (the OAuth Authorization Server and the AAuth Person Server); under the standalone MAS binding the unchanged Authorization Server keeps issuing valid tokens after revocation, and the cutoff for every column is the runtime layer's state re-check. Where the issuance join is deployed ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), the further-issuance column returns for consuming Authorization Servers: new grants stop at the MAS commit, and refresh is gated within each server's published staleness bound.¶

The token lifetime and introspection layers are the issuance profile's ([I-D.draft-mcguinness-oauth-mission]); Mission Status ([I-D.draft-mcguinness-oauth-mission-status]), Mission Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]), and runtime enforcement ([I-D.draft-mcguinness-mission-runtime]) each tighten the window as their own profile defines. A deployment reads the row for the mechanism it runs, or the tightest of several, to state how long a revoked Mission can still act. Where Child Delegation is used, a parent's terminal state cascades to its Child Missions ([I-D.draft-mcguinness-oauth-mission-child-delegation]), and each child's own window then runs under the same table.¶

The same window, read per Mission Assurance Level ([I-D.draft-mcguinness-mission-architecture]) and per what it stops:¶

Background work is bounded only where the harness re-checks Mission state on resume, retry, and dispatch ([I-D.draft-mcguinness-mission-harness]); without it, a resumed job acts on the authority its cached credential still carries.¶

11. Documenting the Trusted Base

A deployment cannot be evaluated against this model without knowing which components it actually trusts. The runtime profile already requires a deployment to document its enforcement scope, including its PEP locations, PDP identities, Mission state source, and the execution paths it mediates ([I-D.draft-mcguinness-mission-runtime]). This model recommends that a deployment claiming the Mission suite extend that documentation to its full trusted base: which of the components in Section 6 it relies on, which it does not deploy, and, for each consequential action class, which components must be intact for the class's guarantee to hold. The statement covers key custody: for each key class the deployment operates (issuer signing, evidence signing, agent sender-constraint, mediating-PEP custody, attenuation roots), where the key is held, at what custody grade, and the compromise-recovery procedure, since the model's strongest assumption reduces to those keys (Section 6). This documentation is what lets a relying party or auditor reason about the deployment's actual security posture rather than the model's idealized one.¶

The Mission Deployment Profile ([I-D.draft-mcguinness-mission-architecture]) is the artifact this statement belongs in: one publishable manifest that composes the per-layer scope statements and states its residual risks alongside its claims. The named guarantees of Section 8 are the vocabulary for the claims, and the residuals of Section 9 are the vocabulary for residual_risks: a deployment names which residuals it accepts, which it mitigates, and how.¶

12. Retention and the Audit Horizon

The guarantees this model states at audit time depend on artifacts that several profiles retain independently: Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), runtime decision and execution evidence ([I-D.draft-mcguinness-mission-runtime]), Shaping Evidence where a shaper is deployed ([I-D.draft-mcguinness-mission-shaping]), metering and settlement records where consumption metering is deployed ([I-D.draft-mcguinness-mission-metering]), and, where audit transparency is used, the receipts that stand over evidence a deployment may later erase ([I-D.draft-mcguinness-mission-audit]). Each of those profiles anchors its retention on the Mission's audit horizon, the deployment-declared window that runs at least the Mission's lifetime plus a post-terminal period ([I-D.draft-mcguinness-oauth-mission]). A deployment that retains every such artifact for at least the audit horizon can answer, at audit time, how long each artifact was to be kept for the guarantee that rests on it to still hold; an artifact dropped before the horizon forfeits the guarantee that depended on it.¶

13. Security Considerations

This document is itself a security-considerations document. It defines no mechanism and adds no attack surface. Its content is the consolidation above; the authoritative, normative security considerations are those of the issuance profile ([I-D.draft-mcguinness-oauth-mission]) and each companion it cites. Where this document and a profile appear to differ, the profile governs.¶

14. Privacy Considerations

The trusted components see Mission data: the Authorization Server and PDP see the Authority Set, the consent rendering layer and Approver see the disclosed authority, and the Transparency Service and state sources see the Mission Identifier and its activity over time. The single canonical Mission Identifier is a durable cross-audience correlator the suite acknowledges and does not yet narrow ([I-D.draft-mcguinness-oauth-mission]); unlinkable or per-audience presentation of Mission-bound authority is out of scope across the suite. Two of the newer surfaces concentrate observation and are handled accordingly: metering state is a fine-grained record of Mission activity over time, disclosed in decision responses only as refusals, never as remaining-balance oracles ([I-D.draft-mcguinness-mission-metering]), and the management endpoint holds the fleet-wide existence knowledge the status profile's anti-oracle rules deny to ordinary consumers, which is why it is authorized and audited as an operator surface ([I-D.draft-mcguinness-oauth-mission-management]). Each profile's Privacy Considerations govern the data its own component handles.¶

15. IANA Considerations

This document makes no IANA request.¶

16. References

Appendix A. OWASP Agentic Threat Coverage

This appendix is informative. It maps the fifteen threats of the OWASP Agentic AI Threats and Mitigations taxonomy [OWASP-AGENTIC] onto the model, followed by the OWASP Top 10 for LLM Applications [OWASP-LLM10], which predates the agentic taxonomy and mixes layers. Threat names and numbering follow the cited versions; the taxonomies evolve, and a reader should expect drift. Each threat gets one of three verdicts rather than a blanket claim:¶

Contained:

the threat lands on machinery built for it, with a named profile behind it.¶

Bounded:

the cause is outside the authorization layer's reach, and the blast radius is capped at the enforcement gate.¶

Delegated:

the threat belongs to a layer this family never claimed, and a named complement owns it.¶

The pattern behind the verdicts follows the model's one commitment (Section 5): authority is committed at the approval event, and every consequential action is checked against it fresh. Threats that attack authority are contained. Threats that attack the model, its memory, or its inputs are bounded, because a fully fooled agent still cannot out-argue a parameter check. Threats that attack other layers are delegated by name. The adversary model (Section 9) owns coverage and residuals; this appendix maps its rows onto OWASP vocabulary, and where the two could be read to differ, the adversary model governs.¶

The threats that attack authority (tools, privilege, goals, attribution, identity, rogue delegates) land on machinery built for them, and the threats that attack the model or the humans are capped rather than cured, because capping is what a deterministic gate can truthfully offer. No agentic threat lands delegated; that verdict is exercised by the LLM Top 10, where half the list belongs to the model and pipeline layers, and saying so is the point:¶

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 work and consolidates the trusted base and security assumptions that its profiles establish individually.¶

Author's Address