| Internet-Draft | Mission Security Model | July 2026 |
| McGuinness | Expires 8 January 2027 | [Page] |
Mission-Bound Authorization for OAuth 2.0 and its companion profiles spread enforcement across several components: a Mission Issuer derives authority and, in the OAuth binding, gates issuance (an OAuth Authorization Server, or a standalone Mission Authority Server that records and serves Missions without issuing tokens); a Policy Enforcement Point and Policy Decision Point evaluate each action; a harness establishes a mediated execution environment; a consent rendering layer discloses authority to an Approver; an orchestrator unwinds in-flight work; and optional services report Mission state, adjudicate requested authority, log evidence, and report completion events. In cross-domain use, a resource-side Authorization Server joins this base. Each profile states its own security considerations, but no single document says which components must be trusted, what each assumes of the others, and how the compromise of each degrades the guarantees. This document provides that consolidated view. It is an Informational security model for the Mission suite: it defines the trusted base, the cross-cutting assumptions, and the consequence of each component's compromise, and it points to the normative security considerations of each profile rather than restating them.¶
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-security-model.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-mission-security-model/.¶
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.¶
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, in the OAuth binding, gates issuance (an Authorization Server or a standalone Mission Authority 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: the parts that, if compromised, degrade or void the guarantees the suite otherwise provides.¶
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.¶
This document is Informational. It does not place normative requirements on implementations; the enforcement obligations are defined by the issuance profile ([I-D.draft-mcguinness-oauth-mission]) and its companions. 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.¶
This document uses Mission, Mission Issuer (the Authorization Server in the OAuth binding; the Mission Authority Server in the standalone binding), Policy Enforcement Point (PEP), Policy Decision Point (PDP), Approver, Subject, agent, Authority Set, and Mission state as defined in [I-D.draft-mcguinness-oauth-mission] and [I-D.draft-mcguinness-mission-runtime].¶
This model describes the components and trust relationships of the Mission model, not of OAuth 2.0 mechanics. Its analysis applies to any substrate that provides the Mission primitives the profiles consume: the identifier and issuer, the state space with its only-active rule, an authority representation with a subset rule, the integrity-anchor envelope, and, where the binding provides one, a Mission-bound credential; 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]). The issuance profile [I-D.draft-mcguinness-oauth-mission] is the OAuth 2.0 binding of those primitives and the substrate the profiles' security considerations assume; a different binding re-derives only the substrate-specific entries of this model.¶
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 Authorization Server 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 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.¶
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: a compromised issuer can mint arbitrary authority. This is the strongest trust assumption in the suite ([I-D.draft-mcguinness-oauth-mission]).¶
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]).¶
When the standalone Mission Authority Server binding is used, a service outside the OAuth Authorization Server implements the Mission Issuer role: it must run the approval ceremony faithfully, keep the Mission record and its anchors intact, and serve accurate Mission state, while the deployment's tokens remain ordinary and carry no Mission binding. 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 ([I-D.draft-mcguinness-mission-authority-server]).¶
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 ([I-D.draft-mcguinness-mission-runtime]).¶
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]).¶
Reports current Mission state for the freshness the runtime layer
requires, whether by introspection, the Status surface, or pushed
Signals. 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
([I-D.draft-mcguinness-oauth-mission-status],
[I-D.draft-mcguinness-oauth-mission-signals],
[I-D.draft-mcguinness-mission-runtime]).¶
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]).¶
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.¶
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]).¶
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]).¶
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]).¶
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-completion]).¶
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.¶
Four assumptions hold across the whole model:¶
Sender-constrained credentials. Mission-bound tokens are sender-constrained ([I-D.draft-mcguinness-oauth-mission]); a token exfiltrated without its proof-of-possession key is unusable. The model assumes the proof-of-possession mechanism is sound and keys are protected by their holder.¶
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. 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]). Authority is
fixed at the approval event.¶
Given an intact trusted base, the model guarantees that 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. In a deployment that claims the runtime profile's agent-compromise-resistant enforcement ([I-D.draft-mcguinness-mission-runtime]), the model further guarantees that such an agent cannot unilaterally take a high-consequence action it does not hold a mediated credential for. In the base profiles two of the mechanisms behind that further guarantee (mediated credential custody and action-bound approval) are recommendations, not requirements, while active-state freshness for the high-consequence classes and the no-unmediated-path rule for mediated classes are already base-profile requirements; a deployment that leaves the recommendations as recommendations 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. A deployment that additionally claims the runtime profile's trifecta containment enforces least exposure and the harness taint rule as MUSTs, so an injected agent cannot egress on the strength of untrusted content alone.¶
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.¶
The trusted base (Section 6) is the component view; this is the adversary view. The adversary is assumed to control the agent, 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 column is the honest part: it is what a deploying party still owns.¶
| Adversary move | Addressed by | Residual: not stopped |
|---|---|---|
| Compromised or injected agent acts beyond its task | Authority fixed at the approval event (issuance); per-action PDP check (runtime) | Misuse within the approved scope; low-consequence authority the agent legitimately holds |
| Prompt injection tries to widen authority | Authority fixed at approval: purpose and success_criteria are inert, and goal shapes authority only through the pre-approval derivation the Approver consents to |
Injected text can still drive actions already in scope |
| Stolen or exfiltrated token | Sender-constraint (proof-of-possession); the high-consequence key is held by the PEP, not the agent (mediated execution) | A token stolen together with its key; soundness of the PoP mechanism |
| Token replayed at another resource (confused deputy) | Permit bound to audience, resource, sub, client_id, and action; cross-domain grant single-use and audienced |
Correct binding configuration is the deployment's |
| Parameters change between decision and use (TOCTOU) | Parameter binding; the digest is reverified at the executing PEP immediately before acting | The PEP must sit at the last controllable boundary |
| Active Mission used as ambient standing authority | Per-action runtime enforcement, state re-check, fail-closed on stale state | An issuance-only deployment gets audit, not action-time defense |
| Revoked or expired Mission still acts (kill switch) | Issuance gating; runtime state re-check within the staleness bound; short token lifetimes | A window up to the staleness bound or token TTL; a spoofed state source (a trusted component) |
| Approver approves more than was shown | The rendered disclosure is committed; rendering-assurance ladder up to an authenticator-signed commitment | Comprehension: no server-side commitment proves what a human perceived or understood |
| Exfiltration of private data (the third leg of the lethal trifecta) | 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) | PEP-placement completeness; no information-flow control, so a sequence of in-scope steps can launder data |
| Offline sub-agent fan-out abuse | Capability monotonicity (narrow-only) and the runtime kill-switch re-check on the carried chain | Fan-out breadth is unobserved by the issuer; bounded by depth and policy, not by the issuer |
| Audit tampered, dropped, or reordered | Transparency: append-only log, inclusion receipts, non-equivocation | Single-service equivocation (per-service only; register with several); a producer can still log a false record (accountability, not prevention) |
| Agent fabricates results or acts on false data | Not addressed | Full: semantic and grounding verification are a non-goal; pair with a grounding layer if needed |
| A trusted-base component is compromised | Not addressed; evidence detects it after the fact | Not prevented; degrades the specific guarantee per Section 6 |
Seven 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. No electronic-consent scheme can.¶
Anchor semantics. The two integrity anchors commit two objects,
not the relationship between them: intent_hash commits the
approved intent, authority_hash the consented Authority Set, and
that the authority faithfully serves the intent is a derivation
policy fact (a SHOULD, auditable via policy_version), not
something either hash 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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
| Configuration | Worst-case window | Governing parameter |
|---|---|---|
| Baseline (token lifetime only) | until the token expires | access-token exp
|
| With introspection | one introspection cycle | per-request introspection at the issuer |
| With Mission Status | the staleness bound of the status view | published status staleness bound |
| With Mission Lifecycle Signals | event delivery latency, bounded by the poll fallback | signal delivery latency plus poll interval |
| With runtime enforcement | the per-class freshness bound | published per-class 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.¶
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. 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 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]), 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.¶
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.¶
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. Each profile's Privacy Considerations govern the data its own component handles.¶
This document makes no IANA request.¶
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.¶