Mission-Bound Runtime Enforcement

1.1. Invariants, Not a Wire Protocol

This profile specifies enforcement invariants, not a wire protocol: it does not standardize a PDP decision API, an enforcement-scope discovery format, a Mission Status endpoint, or a portable audit receipt. It defines what a deployment MUST satisfy when it claims runtime Mission enforcement; the surfaces it deliberately leaves to deployments or future work are collected in Section 16.¶

Because the invariants are not a wire format, two conforming deployments do not thereby interoperate at the PEP-PDP boundary; the interoperable wire surface is supplied by a separately specified decision API binding (Section 15), the AuthZEN profile being [I-D.draft-mcguinness-mission-authzen]. That a wire format is a deployment choice does not make it an ad hoc one: the Runtime-Enforced level of the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]) requires a specified decision-API binding, of which the AuthZEN profile is the one this family defines; a deployment that uses a different decision API specifies that binding likewise (Section 15). This document is the architecture and invariant layer; the binding is the interoperability layer.¶

1.2. Relationship to Issuance and Derivation

The seam between an issuance-and-derivation layer and this document is exact. This document delivers four things an issuance-and-derivation layer names as out of scope, plus enforcement of the constraints that layer carries but does not evaluate:¶

1. evaluation of a request's parameters against the Mission at the point of use (Section 7, Section 8);¶

2. per-action runtime enforcement evidence (Section 11);¶

3. binding of the invoked tool or function identity to the Mission's approved authority (Section 7);¶

4. execution-time re-evaluation that closes the approval-to-execution (time-of-check to time-of-use) gap (Section 8);¶

and, additionally, the fail-closed treatment of consumption bounds (Section 10).¶

This document depends normatively on the Mission Substrate (Section 4) and is not implementable alone: it consumes the Mission-bound credential a substrate-conforming binding derives, or a credential joined to an externally established Mission under Section 2.3. It does not place any new requirement back on the issuance-and-derivation layer; it reads only the credential's established Mission reference, effective authority, subject and actor context, and sender-constraint confirmation, each realized concretely by the binding's credential profile. It obtains any value the credential does not carry (the current Mission lifecycle state, or a policy-view version) at runtime as described below, never by requiring the issuance-and-derivation layer to add a field.¶

For the OAuth binding, that issuance-and-derivation layer is Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile"), and its credential profile is the runtime OAuth 2.0 profile ([I-D.draft-mcguinness-mission-runtime-oauth]). The issuance-and-derivation layer's own credential validation remains the baseline for every Mission-bound credential; this document adds an optional runtime conformance profile for deployments that claim execution-time Mission enforcement, and does not weaken that layer's credential-validation, subset, delegation, or constraint-enforcement requirements.¶

2.1. The Runtime Contract

Within a declared enforcement scope, a consequential action executes only after a Policy Enforcement Point (PEP) at the action's last controllable boundary obtains, from a Policy Decision Point (PDP), a permit that evaluates the action and its concrete parameters against the established Mission: its approved authority and constraints, the actor context from the delegation chain, its current lifecycle state, and the applicable Resource policy. The permit is bound to the parameters the action executes with, and every decision and refusal path leaves evidence.¶

Mission-bound credentials bound what authority may exist; the contract fixes where and how that authority is re-checked before consequential effects occur. The order is the point: approve the bounded work, then authorize every consequential action against that approved boundary. Per-action authorization alone cannot prevent individually permitted steps from composing into an outcome no one approved; the approved boundary bounds composition, with the cumulative bounds and exclusive latch of the metering companion where deployed (Section 10, [I-D.draft-mcguinness-mission-metering]). The PEP is whatever component can actually prevent the action: a Resource Server, an MCP server, an egress proxy, a workflow engine, or the orchestrator itself (Section 5.5). The PDP's placement is a deployment choice (Section 7). A deployment whose acting tokens carry no mission claim can still bind each decision to a Mission: the Mission Substrate (Section 4) admits an externally established Mission reference (Section 2.3).¶

2.2. Enforcement Invariants

Seven invariants restate the contract as the properties a conforming deployment maintains. Each is normative in its home section, and the failure-mode table (Section 2.11) is their operational form.¶

Gated at the point of use:

No consequential action executes without a prior PDP permit; token possession alone never suffices (Section 7).¶

Enforced at the last controllable boundary:

The PEP sits where the action can still be stopped; a check further upstream does not survive what happens after it (Section 5.5).¶

Bound to the bytes:

A parameter-bound permit binds the normalized parameters, and the executing PEP reverifies them immediately before acting; a changed parameter is a refused action (Section 8).¶

Fresh or refused:

A permit requires the Mission active within a published staleness bound, and the high-consequence classes require an active freshness source, not token-lifetime expiry (Section 2.5).¶

Fail closed:

An unknown or unmetered constraint, an unreachable PDP, Mission state that cannot be established within the staleness bound, or an unsupported authorization-details type refuses the action (Section 2.11).¶

Evidenced:

Every decision and every refusal path produces an integrity-protected record, and a high-consequence action also produces execution-outcome evidence (Section 11).¶

Never widening:

No runtime input expands authority beyond the issued Authority Set; a deny is terminal for the attempted action, and widening is a governance operation, never a runtime one (Section 7).¶

For the high-consequence classes (Section 5.3) the profile goes further: the acting credential is sender-constrained with a verified proof of possession (Section 5.6), action-bound approval re-consents the concrete parameters (Section 5.4), and mediated custody keeps the credential's sender-constraint key in the enforcing component rather than the agent (Section 5.6). Those mechanisms compose into the two named claims of Section 9.5, agent-compromise-resistant enforcement and trifecta containment: the bar a deployment meets before representing itself as resistant to a compromised or injected agent, and the High-Assurance Agent level of the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]).¶

2.3. Mission Binding Establishment

Every decision evaluates one Mission: the established Mission. A deployment establishes it in one of two modes:¶

• Credential-carried. The acting credential's Mission reference identifies the Mission, under the binding's own credential representation (the OAuth realization is the mission claim, [I-D.draft-mcguinness-oauth-mission]). The PEP takes the Mission reference from the validated credential, after establishing the credential's validity for the protected resource and request under the binding's own credential-validation rules (the OAuth realization is defined by [I-D.draft-mcguinness-mission-runtime-oauth]).¶

• Externally established. The acting credential carries no Mission reference of its own, and the PEP supplies a Mission reference from the deployment's Mission binding source. The PDP MUST verify that reference against the acting credential under a join a binding profile defines; an unverified reference MUST NOT establish the Mission. The Mission Authority Server profile defines the concrete join for this mode ([I-D.draft-mcguinness-mission-authority-server]), and the AAuth binding's reference propagation supplies the externally carried reference for such a join ([I-D.draft-mcguinness-mission-aauth]), as the MAS profile's Mission Reference Propagation channel does in credential-less MAS mode.¶

The mode each enforcement scope uses is part of its Enforcement Scope Statement (Section 5.2). In either mode, the established Mission is the Mission every input of Section 2.7 (authority, Resource policy, parameters, actor, time, state) is evaluated against, and the Mission reference the permit and the evidence record bind.¶

2.4. Remote Decision Channel

A PEP MUST NOT ask a PDP to authorize an action from unverified credential claims: a decision evaluates only what the PEP has already established as authenticated. Where the PEP and PDP are separate components, the decision request and response MUST be integrity-protected and the parties MUST authenticate each other. The PDP MUST accept credential-derived inputs only from a PEP authorized for the declared enforcement scope. A deployment can satisfy this with a mutually authenticated channel, a signed decision request and response, or another mechanism with equivalent security properties. A co-resident PDP and PEP, sharing one trust boundary, satisfy this requirement structurally and need no separate channel mechanism; the requirement is not optional for a boundary that is not co-resident.¶

The PEP SHOULD send the PDP the minimum credential-derived attributes needed for the decision rather than the presented credential itself. Where a deployment instead sends the credential itself to the PDP, the PDP MUST treat it as a credential, protect it against disclosure, and MUST NOT use it outside the declared enforcement scope.¶

2.5. Mission State and Freshness

A Mission-aware decision needs the Mission's current state, which the acting credential alone does not convey. A runtime deployment MUST define the Mission state source it trusts for each enforcement scope. A state source is a component, reachable under the deployment's own trust rules, from which the PDP establishes the Mission's lifecycle state and the freshness of that observation. Examples include a query to the Mission issuer, a local Mission database, an authenticated status or event feed, or a short-lived derived credential whose lifetime is the deployment's accepted state lease. A materialized policy view (Section 7.1) is not a state source: it commits the compiled authority, never the mutable lifecycle state a decision consults.¶

The substrate this profile enforces against provides at least a lifecycle-gated capability (Mission state at the issuer, with reliance boundable by credential lifetime alone) and MAY additionally provide a state-observable capability (an authenticated freshness source with a stated staleness bound).¶

A deployment claiming runtime enforcement for an action class whose published staleness bound is tighter than the credential lifetime REQUIRES a state-observable substrate for that class; the high-consequence classes below always are. A lifecycle-gated-only substrate supports issuance gating and a lifetime-bounded action-time posture only: it cannot reflect a revocation faster than the credential lifetime, so it cannot host a class whose bound demands that.¶

• The PDP MUST refuse a consequential action when it cannot establish, within the deployment's published staleness bound, that the Mission is active.¶

• A state source MUST either report the Mission state with an explicit expiry or lease end, or report only an observation time, in which case the state remains acceptable only until that observation time plus the deployment's published staleness bound for the relevant action class. A permit issued from that state view MUST expire no later than this state valid-through: the reported expiry or lease end, or, absent one, the observation time plus the published staleness bound. The observation time alone, without adding the staleness bound, is never a permit's expiry.¶

• When the credential issuer also holds the Mission, the PDP can learn state directly from the issuer through the binding's own state-query mechanism. A non-issuer PDP validating a locally accepted credential cannot report current Mission state that way; it can establish local credential validity, but not issuer-side Mission freshness, absent a separate cross-domain arrangement its binding defines ([I-D.draft-mcguinness-oauth-mission-cross-domain] for the OAuth binding).¶

• This document defines no cross-issuer by-Mission status query of its own. Deployments that need tighter freshness than the credential's own lifetime, or a cross-domain grant's lifetime, provides use an active freshness mechanism their binding defines: a status query, a status list, an event-driven signal feed, or an out-of-band trusted status feed.¶

• The maximum staleness bound per action class and state source is declared in the Enforcement Scope Statement (Section 5.2), together with the revocation latency it implies. Publishing the bound without its latency consequence is non-conformant. For a PDP-gated class, a Mission's revocation takes effect, in the worst case, after the staleness bound plus the permit validity window plus the class's execution bound (Section 8); the derived credential's lifetime is the bound only for paths outside PDP gating. This document imposes no universal value because the acceptable latency is deployment- and consequence-specific; the bound is the number that determines the profile's headline revocation property. The per-class budgets below are the RECOMMENDED defaults for the value.¶

• For the high-consequence classes, the state source MUST be an active freshness mechanism that can reflect a revocation within the staleness bound: one that is queried or pushed at a frequency independent of the credential's own lifetime, rather than a mechanism whose only signal is that lifetime expiring. Credential-lifetime expiry alone is not an acceptable state source for these classes: it bounds staleness only by the lifetime, so a revoked Mission keeps deriving consequence until credentials age out, which is the ambient-authority gap this profile exists to close.¶

An informative worked example of the latency arithmetic: for a PDP-gated class with a published staleness bound of 60 seconds and a declared execution bound of 30 seconds, a revocation committed immediately after a state observation stops new effect after at most 90 seconds. That worst case combines:¶

• the stale view remaining acceptable for up to 60 seconds;¶

• a permit issued from that view expiring no later than the view's valid-through (the permit cap above); and¶

• a permitted action completing within its execution bound.¶

The general worst case above counts the permit validity window as its own term because a state source reporting an explicit lease end can leave a permit window beyond the staleness bound; under observation-time reporting the permit cap collapses that term. A path outside PDP gating keeps only the derived credential's lifetime as its bound.¶

For a deployment whose Mission-bound credentials are short-lived and whose issuance and refresh are themselves gated on live Mission state, the refresh cycle itself is a conforming active freshness source for any action class whose published staleness bound the credential lifetime meets: the issuance gate is an active check, and a credential that exists is evidence the Mission was active within the lifetime. This source's revocation latency floor is the credential lifetime, so it conforms only for classes whose bound admits that floor, and a higher-frequency source remains the path to tighter bounds.¶

Credential-lifetime freshness. Below the high-consequence floor, credential expiry is itself a conforming state source where derivation and refresh are gated on active, so a credential's remaining lifetime bounds the staleness of the authority it carries, and the published staleness bound for a class relying on it is the maximum credential lifetime. Expiry is a state check performed by the clock: no status call, no query, no change at the consuming resource. A deployment declares it per class in its Enforcement Scope Statement like any other source; what it cannot do is reflect a revocation faster than the lifetime, which is why the high-consequence classes require an active source.¶

Together the sources form a single freshness dial, and a deployment picks a position per action class rather than one posture for the estate: from credential-lifetime expiry at one pole, through state-gated refresh, to a queried or event-driven active source at the other. No position on this dial requires a per-request issuer call: the tightest posture costs one lookup per staleness bound, amortized by caching, and the loosest costs a clock. The dial is the architecture's freshness dial made concrete ([I-D.draft-mcguinness-mission-architecture]), and the Enforcement Scope Statement records the chosen position per class. A credential profile catalogs its binding's concrete state sources against this dial, each with its capability class, exposure bound, per-action cost, and what it cannot provide; the OAuth catalog is [I-D.draft-mcguinness-mission-runtime-oauth], Section "Mission State Sources".¶

The following are the RECOMMENDED default freshness postures per class, adopted absent a documented, consequence-specific analysis:¶

A deployment justifies any looser value for a high-consequence class in its Enforcement Scope Statement.¶

For a Mission carrying a nonzero containment overlay ([I-D.draft-mcguinness-oauth-mission-containment]), the RECOMMENDED posture for a consequential read whose authorizing entry or action class intersects the overlay tightens to a containment-aware state source, for the remainder of that Mission: the overlay never clears on the same Mission, and restoration is a successor Mission's own approval ([I-D.draft-mcguinness-oauth-mission-containment], Section "Restoration Through Expansion"). A deployment adopting this tightening MUST name a containment-aware state source, not merely an active one: a contained Mission stays active, so a source that reports only lifecycle state does not change ([I-D.draft-mcguinness-oauth-mission-containment], Section "Propagation").¶

A containment-aware source reports the containment overlay or its changes, not only lifecycle state ([I-D.draft-mcguinness-oauth-mission-containment], Section "Visibility"); the credential profile names which of its sources qualify. A fresh derivation narrows what it mints and can shorten the residual, but it checks nothing at action time, so it carries Baseline, not Runtime-Enforced, and is not a containment-aware source for this tightening ([I-D.draft-mcguinness-oauth-mission-containment], Section "Containment Properties").¶

A deployment MAY instead tighten on any nonzero overlay regardless of class. That is a defensible conservative default; its cost is incident-time availability load on reads the overlay does not touch, since every consequential read then depends on state-source availability during the incident that triggered containment. The under-containment staleness bound for an affected class is declared in its Enforcement Scope Statement alongside the ordinary bound (Section 5.2); this posture adds no separate value, and the bound carries its latency consequence like any other.¶

The tightening narrows the post-taint window for the classes and deployments that adopt a containment-aware source; it does not close the Baseline residual ([I-D.draft-mcguinness-oauth-mission-containment], Section "Containment Properties"). A consumer bounded by token lifetime alone, or a class this tightening does not reach, still runs to its existing bound.¶

2.6. Decision Output

Whatever the wire, a runtime decision presents one abstract output, and a binding maps each member onto its protocol rather than inventing parallel semantics:¶

• an outcome: permit or deny;¶

• an evaluation identifier and evaluation time, correlating the decision with its evidence;¶

• on a deny, a reason from the binding's failure classification;¶

• on a permit, decision conditions: declarative constraints on relying on the permit (a request binding, a validity bound, a use limit), evaluated at every use of the permit; a condition the enforcing component does not recognize makes the permit unusable, the reliance counterpart of the obligations rule;¶

• zero or more obligations: mandatory enforcement duties the PEP completes under the existing decision, where an unfulfilled or unrecognized obligation is an effective deny;¶

• zero or more advice items, where the binding defines them: safely ignorable hints that never carry a mandatory control;¶

• optionally, an access-request signal marking a denial requestable through a governance workflow;¶

• optionally, a retry signal marking a denial transient, with a wait interval; and¶

• a reserved residual-policy member for a future partial-evaluation composition, which this profile does not define.¶

An approval produced by the governance workflow returns as decision input on a fresh evaluation (Section 5.4), never as output state. The AuthZEN profile maps this output onto its response context, the obligations profile, and ARAP (Section 15).¶

2.7. Decision Inputs

Runtime enforcement MUST evaluate every input below except the last: History (Section 2.7.8) is OPTIONAL, evaluated where the deployment declares it.¶

2.8. Parameter Digest

A permit for an operation does not authorize arbitrary parameter values. For consequential writes, irreversible actions, external commitments, and privileged administration, the PDP MUST bind its permit to the normalized action parameters through a parameter_digest, and the executing PEP MUST recompute and reverify that digest immediately before acting (Section 9.4).¶

• parameter_digest is sha-256: followed by the base64url, no padding, SHA-256 [RFC6234] of the JCS [RFC8785] serialization of the normalized parameter object. It MUST be computed under the same canonicalization rules the issuance profile defines (duplicate member rejection, significant array order, byte-for-byte URI comparison); this document does not define a second canonicalization. It is a canonical-object digest under the substrate's default commitment construction, which this document imports normatively ([I-D.draft-mcguinness-mission-substrate]): the I-JSON requirement and the reject-unknown-prefix rule apply to computing and verifying it unchanged.¶

• Every parameter that influences the action's external effect (for example, the recipient, destination, amount, or target object) MUST enter the parameter_digest. A field the deployment excludes MUST be shown effect-free in the Operation Profile, which records why that field cannot change the action's external effect; a field whose effect is not so justified MUST be included.¶

• The Operation Profile MUST define default insertion, omitted optional fields, and set-like array handling before canonicalization.¶

2.9. Permit Binding

Beyond the parameter_digest, the permit MUST also bind:¶

• the Mission reference;¶

• the credential issuer, when available;¶

• the credential audience or protected resource;¶

• the authenticated subject identifier;¶

• the client identity;¶

• the actor context, including the immediate actor;¶

• the sender-constraint confirmation key, when present;¶

• the action;¶

• the action phase, when the action is a phase of a compound action (Section 2.10);¶

• the resource;¶

• the authorizing authority entry, or an entry digest;¶

• the PDP's policy-view version; and¶

• a permit lifetime control bounded by the Mission state freshness requirement (Section 2.5).¶

A permit is bound to the full set of authorization-relevant inputs it was issued for: the authorization binding, which a decision-API binding realizes as one normalized projection over those inputs, never as an enumerated subset of fields ([I-D.draft-mcguinness-mission-authzen]). The credential profile maps these roles onto its credential ([I-D.draft-mcguinness-mission-runtime-oauth] for OAuth).¶

The permit lifetime control is set by action class:¶

2.10. Compound Actions

A compound action produces an effect through more than one boundary crossing, such as validate, reserve, execute, and settle, or draft, attach, and send. Four phases name what a crossing does:¶

• preflight: checks feasibility or availability without a reservation or external effect. Its reads retain the ordinary read-binding floor (Section 8.1).¶

• prepare: creates a reservation, hold, draft, or schedule. That state is consequential in its own right and is not authority for commit.¶

• commit: releases the consequential effect.¶

• compensate: offsets an already committed effect. Cancelling an uncommitted reservation is not, merely by its name, compensation for a committed effect.¶

Every consequential phase MUST obtain its own Decision. A permit MUST NOT authorize more than one phase. A preflight Decision MUST NOT satisfy the gate for a consequential phase. A reservation MUST NOT be presented as authorization for commit. The commit phase MUST obtain its own Decision against the Mission's effective authority (Section 2.7.1) and active state (Section 2.5), under the existing freshness bounds. This does not impose zero staleness or an issuer call for every request; it forbids using prepare's Decision or state observation as the commit authorization. A fresh commit-phase Decision binds the request as presented: where a resource-resolved fact moved between prepare and commit, the parameter digest can still match. Capturing target state at decision time is a separate, optionally claimed extension (Section 9.1), outside this section.¶

A permit for a phase MUST bind that phase. Where phases already have distinct action identifiers, the action binding also distinguishes them; where they share an identifier, phase binding prevents a prepare permit from releasing a commit effect with otherwise identical resource and parameters. The PEP derives the crossing's phase from its trusted Operation Profile (Section 8), which states whether each operation is part of a compound action and its phase. The PEP MUST NOT derive the phase from an agent-supplied argument.¶

The executing PEP MUST compare the permit's bound phase with the phase of the crossing before releasing an effect. Unequal phases, an absent binding where the Operation Profile identifies a phase, or a phase that cannot be established MUST cause refusal, fail closed, before any effect is released. A PEP that does not recognize the phase condition MUST treat the permit as invalid. The AuthZEN realization is the returned permit condition conditions.action_phase ([I-D.draft-mcguinness-mission-authzen]); context.action_phase is the request mirror and Decision Evidence is retrospective. Neither substitutes for the permit condition. The phase MUST NOT be injected as a synthetic parameter into parameter_digest, whose definition is unchanged. Requester and executor remain one enforcement identity; this binds permit scope, not the agent's intent.¶

Decision Evidence for a phase MUST record its action_phase. A compensate-phase Decision MUST carry compensates_evaluation_id identifying the evaluation whose committed effect it offsets. A compensation MUST NOT be authorized by the compensated action's permit. Its authority basis, unwind ordering, and partial-failure semantics remain the orchestration profile's ([I-D.draft-mcguinness-mission-orchestration]). The correlation identifier itself supplies no authority. A compensation is a new operation with a new idempotency key and obtains fresh action-bound approval where its class requires it.¶

For a compound action, the transaction-authorization companion's single-use token authorizes one commit-phase operation, not a permit spanning preparation, commit, and compensation ([I-D.draft-mcguinness-oauth-mission-transaction-authorization]). Metering reserve/commit governs consumption, not these effect phases ([I-D.draft-mcguinness-mission-metering]). Outcome verification stays with Execution Evidence and reconciliation (Section 11). These phases are Runtime Core vocabulary, not a new Named Assurance Extension.¶

2.11. Failure Modes

Enforcement is meaningful only if failure is bounded. A PDP or PEP MUST behave as follows; in all cases the evidence record (Section 11) MUST be sufficient to reconstruct which path produced a refusal.¶

2.12. Required Decision Evidence

A record MUST contain:¶

• the decision or refusal result and, on refusal, the failure condition from Section 2.11;¶

• the request time (RFC 3339 [RFC3339]); and¶

• the parameter_digest for parameter-bound classes, or a digest of the evaluation request otherwise, over the input the runtime evidence companion defines ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

A record MUST also contain the following fields when they are available and trusted for the refusal or decision path:¶

• the Mission reference (mission.id, mission.issuer) and, when available, the authority_hash and intent_hash it operated under: a credential need not carry either, so a PDP has them only through a source its credential profile names ([I-D.draft-mcguinness-mission-runtime-oauth] names the OAuth sources);¶

• the credential issuer and audience or protected-resource identifier when available;¶

• the authenticated subject identifier, the client identity, a client-instance identifier (a deployment-defined correlator) when present, the sender-constraint confirmation key when present, and the actor-delegation chain projection when delegation applies;¶

• the action and resource identifiers (and the asserted capability identity when applicable);¶

• the authority-entry type and authorizing entry, or a digest of that entry when recording the full entry would disclose excess authority or sensitive policy;¶

• the decision identifier, when the PDP produced one;¶

• the PDP's policy-view version;¶

• the identity and role of the emitting enforcement component; and¶

• a compensates_evaluation_id member, REQUIRED for a compensate-phase decision and OPTIONAL otherwise, linking a compensating action's decision to the original evaluation identifier it reverses, so a compensation can be reconciled against the action it undoes.¶

The credential profile maps the roles above onto its credential ([I-D.draft-mcguinness-mission-runtime-oauth] for OAuth).¶

For a credential-validation failure, the record MUST NOT describe unverified credential claims as authenticated facts. It MAY include a digest of the presented credential or rejected claim set for correlation and forensics, subject to the privacy requirements below.¶

The authority_hash and intent_hash in a record are the Mission Issuer's commitments, cited as anchors; the PDP does not recompute them and is not required to hold the full Authority Set to record them, consistent with [I-D.draft-mcguinness-oauth-mission].¶

5.1. Enforcement Flow

 Agent          PEP (action boundary)        PDP
   |                  |                        |
   |- action+params ->|                        |
   |                  | validate token         |
   |                  |- evaluate vs Mission ->|
   |                  |  (authority, params,   |
   |                  |   actor, state)        |
   |                  |<---- permit / deny ----|
   |                  | bind to params;        |
   |                  | write evidence         |
   |<- execute/refuse-|                        |

The PEP first validates the acting credential (for the OAuth binding, [I-D.draft-mcguinness-mission-runtime-oauth]). On permit the PEP reverifies the parameter binding, then executes; on deny it refuses. The inputs the decision evaluates are defined in Section 7.¶

5.2. Enforcement Scope and Conformance

This profile is implemented by a runtime deployment, not by a credential issuer alone. Three things conform, at different granularities: the runtime deployment (this section), the Resource Server runtime profile for the protected resources it mediates (Section 6), and the PEP/PDP decision path for each consequential action (Section 7). Conformance is not global to a product, credential issuer, Resource Server, or PDP: a deployment conforms to this profile only for the resources, action classes, execution paths, and authority-entry types named in its enforcement scope.¶

A deployment that claims conformance to this profile MUST publish an Enforcement Scope Statement: the structured, referenceable declaration of its enforcement scope that auditors, procurement, and interop tests key on. A deployment adopting the Runtime-Enforced bundle of the Mission Assurance Levels publishes this statement; the level stays guidance, and the statement's named claims are what a relying party compares. The statement feeds the Mission Deployment Profile, the deployment-level manifest the architecture describes ([I-D.draft-mcguinness-mission-architecture]).¶

The statement's baseline declaration, required of every conforming deployment regardless of which named claims or assurance extensions it also carries, MUST include:¶

• the protected resources, action classes, and execution paths it mediates, the PEP locations that can prevent those actions and the unmediated paths explicitly excluded from the claim (the harness profile's execution-environment scope statement supplies these for a harness-run deployment, [I-D.draft-mcguinness-mission-harness]), and the Mission-establishment mode each enforcement scope uses, including the perimeter dispositions defined below inside this same mediated-scope declaration;¶

• the supported authority-entry types, action identifiers, and constraint vocabularies, and the evaluator for each supported type (Section 2.7.1);¶

• the PDP or PDPs that evaluate Mission-bound decisions;¶

• the Mission state source and maximum staleness bound used for each action class, including the PDP-unavailability posture the deployment rides through on unexpired, unconsumed permits (Section 2.5, Section 2.11); and¶

• the remote decision-channel trust mode for every PEP/PDP boundary that is not co-resident: the mutual authentication or signed request/response mechanism satisfying Section 2.4; and¶

• the append-only, integrity-protection mechanism for its records (a hash-linked log, signed segments, a transparency anchor, or equivalent), which every record MUST have regardless of which evidence extension, if any, the deployment also claims (Section 11.3).¶

Each declared resource and excluded path MUST have exactly one perimeter disposition: mediated, reconstructed, or unrecorded. mediated means every consequential effect on the entry crosses a PEP before the effect. reconstructed means no per-action gate is in the path, but the executing system records how outputs derive from inputs. unrecorded means neither holds. These are per-entry fields inside the existing mediated_scope member, not a seventh baseline member. The Security Model describes their limits informatively ([I-D.draft-mcguinness-mission-security-model]).¶

The nested declaration has this shape:¶

"mediated_scope": {
  "resources": [
    { "resource": "https://erp.example.com", "disposition": "mediated" },
    { "resource": "https://warehouse.example.com/sales",
      "disposition": "reconstructed" }
  ],
  "excluded_paths": [
    { "path": "notebook_interpreter", "disposition": "unrecorded" }
  ],
  "action_classes": ["irreversible_action"],
  "execution_paths": ["tool-gateway"],
  "pep_locations": ["tool-gateway"],
  "mission_establishment_mode": "mission_claim"
}

Resource identifiers and path names are non-empty strings. Resource entries take any of the three dispositions; excluded paths take only reconstructed or unrecorded. For compatibility, a resource entry written as a bare string denotes mediated, its existing meaning. An excluded-path string has no such default: unrecorded would fabricate a claim and reconstructed would overclaim, so it requires migration to an object. A validator MUST reject a missing or unknown disposition, an excluded-path entry written as a bare string, an excluded path marked mediated, or duplicate keys with conflicting dispositions, naming the entry in each case. Identical repeated keys can be normalized to one entry.¶

A deployment MUST NOT represent reconstructed or unrecorded entries as mediation. A runtime-enforcement claim is in scope only when its resource is mediated and its named execution path is not excluded, even if that path also appears in execution_paths. The existing resource, action-class, authority-entry-type, and execution-path scope checks still apply. Reconstruction supplies provenance, never authorization after the effect. Declaring a reconstructed or unrecorded entry is a stated posture, not itself nonconformance. This declaration qualifies the entries already enumerated; it does not require enumeration or closure of all arbitrary computation. It is distinct from the harness's per-channel disposition, whose not-covered value disclaims that channel rather than reconstructing its flow.¶

A named assurance extension or enforcement claim attaches its own declaration requirement to the baseline statement, rather than adding a universal item every deployment carries whether or not it claims the extension: the per-class Evaluation-Context Binding declaration (Section 9.1); the credential custody mode for a mediated class (Section 5.6); the transaction-assurance tier's Exact idempotency-claim domain per mediated action class or idempotency scope (Section 9.3); the runtime enforcement evidence mechanism, retention window, and the locations of the deployment-published evidence signing key sets (the runtime evidence companion's PDP and PEP key sets, [I-D.draft-mcguinness-mission-runtime-evidence], resolve here), together with the agent-isolated evidence-emission condition's per-emitter declaration where that condition is claimed (Section 11, Section 5.7); the per-row EAT evidence selections a High-Assurance Agent claim rests on (Section 9.5.1, Section 9.5.2); and the reconciliation window, responsible component, and alerting obligation for outcome reconciliation (Section 11). A deployment claiming none of these carries only the baseline declaration above; the baseline declaration is never optional.¶

A deployment MUST NOT claim runtime enforcement for a resource, action class, authority-entry type, or execution path outside that declared scope. A Mission Issuer conforms to its binding; it does not become a runtime-conforming deployment merely by issuing Mission-bound credentials. The converse is a stated posture, not a failure: a resource or class outside the declared scope relies on issuance gating and credential-lifetime freshness (Section 2.5), and the Enforcement Scope Statement says so. This profile does not require every resource to evaluate Mission state; it requires the deployment to say which do.¶

Within the declared scope the duties tier by action class, and the tiers have names; the Enforcement Scope Statement names which tier covers which class.¶

Core enforcement tier:

What every conforming deployment carries:¶

• Mission establishment;¶

• per-action evaluation against current Mission state and Resource policy;¶

• state freshness;¶

• permit or deny with a decision identifier and Decision Evidence; and¶

• parameter binding for the parameter-bound classes.¶

Transaction-assurance tier:

Claimed per mediated class and required for the high-consequence classes:¶

• single-use permits and execution leases;¶

• Execution Evidence; and¶

• outcome reconciliation.¶

One bound is stated rather than implied: reconciliation detects divergence between decisions and outcomes; it never manufactures exactly-once execution, which exists only where the resource itself supports idempotency, as its Operation Profile records (Section 6).¶

The enforcement scope is a deployment conformance statement, not a discovery-metadata extension. This document defines no discovery mechanism, registry, or wire format for publishing it. Different deployments can document scope through configuration, operational policy, resource-server metadata defined elsewhere, or a contractual profile.¶

5.3. Action Classification

The boundary between consequential and non-consequential actions is deployment policy, bounded by the classification floor below. This document defines a default classification a deployment SHOULD adopt, and a floor it MUST observe.¶

The table's per-class requirements (the PDP gate and parameter binding) are requirements for an action once it is assigned to that class. Assigning an action to a class is deployment policy, bounded by the floor below and by any Resource-policy minimum (Section 7): the profile does not require every read to reach a PDP. A read that is already fully constrained by the token's audience, resource, and the Resource Server's object-level authorization, and that does not materially affect the resource set or disclosure risk, need not be classified a consequential read, and is then not separately PDP-gated by this profile. A deployment MUST NOT, however, use classification to evade the floor or a Resource-policy minimum, and once an action is a consequential write or higher it MUST be gated and bound as the table requires.¶

One predicate cuts across the classes. An external-communication action is a consequential action, of any class, whose effect carries data to a recipient outside the deployment's trust boundary (sending a message or mail, posting to an external service, publishing, or any equivalent egress). The term names the egress property, not a sixth class: an external-communication action keeps its class and that class's requirements, and rules stated over "external-communication and external-commitment actions" (the taint rule, trifecta containment, egress metering) apply to any action satisfying the predicate or classified external_commitment.¶

The three highest classes are defined by predicates; the table's examples illustrate them:¶

Irreversible action:

the action's effect cannot be reversed by the same authority within the deployment's own systems.¶

External commitment:

the action creates an obligation or communication binding the Subject to a party outside the deployment.¶

Privileged administration:

the action changes who holds authority or how authority is evaluated.¶

Classification remains deployment-scoped: each deployment applies the predicates to its own actions and systems. The predicates make the resulting classifications comparable across deployments and auditable: an assignment is justified by whether its predicate holds, not by resemblance to the examples.¶

Some operations have no fixed class: a shell, a generic HTTP client, a code interpreter, any operation whose consequence depends on its arguments. Such an argument-dependent operation is classified per invocation, from its normalized parameters, by a classifier the deployment declares in its Enforcement Scope Statement (Section 5.2). An invocation the classifier cannot affirmatively place MUST be treated as the widest class the operation can reach, and the floor below applies to the classifier's assignments as to any other: a class the deployment cannot justify by its predicate is not a basis to leave the invocation ungated.¶

Classification floor. Four rules bound classification:¶

1. Actions in the irreversible, external commitment, and privileged administration classes MUST be treated as consequential and gated.¶

2. A Mission's purpose, or deployment policy, MAY raise an action to a stricter class.¶

3. A Mission's purpose or deployment policy MUST NOT lower an action below any minimum classification the Resource policy (Section 7) sets for it, including a floor the resource owner publishes through its own metadata mechanism (the OAuth binding's realization, mission_action_class_floors in OAuth protected resource metadata, is defined by [I-D.draft-mcguinness-mission-runtime-oauth]).¶

4. In any case, a Mission's purpose or deployment policy MUST NOT classify an irreversible, external-commitment, or privileged-administration action as non-consequential.¶

The three classes of the first rule are the high-consequence classes, to which this profile's strictest requirements attach (action-bound approval (Section 5.4), mediated custody (Section 5.6), active-state freshness (Section 2.5), and execution-outcome evidence (Section 11), each as specified in its own section). A deployment that leaves such an action ungated does not enforce this profile for that action's class (Section 5.5).¶

5.4. Action-Bound Approval

The Mission's approval event ([I-D.draft-mcguinness-oauth-mission]) consents to the task and its authority bound; it does not consent to a specific action's concrete parameters at the point of use. For the highest-consequence classes, a deployment can require a second, action-bound approval: a fresh approval bound to the concrete action and the parameters the PEP is about to permit, distinct from the Mission's initial approval. A deployment SHOULD reserve action-bound approval for the actions whose consequence genuinely warrants a human pause: applied broadly it trains the Approver to rubber-stamp, and a rubber-stamped approval binds like a considered one (the consent-fatigue residual of [I-D.draft-mcguinness-mission-security-model]).¶

An action-bound approval is a governed approval bound to the action: it is obtained from an independent Approver or policy authority, never self-issued by the agent or asserted from the agent's own context, and its rendered disclosure MAY be committed as Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) bound to the action parameters. It composes with, and does not replace, [RFC9470] step-up authentication, which strengthens the actor's authentication context rather than approving a specific action.¶

Five rules govern the approval's enforcement:¶

1. A PEP MUST refuse an action for which the applicable entry's constraints.requires_action_approval is true, or deployment policy or Resource policy otherwise requires an action-bound approval, and for which a valid fresh approval bound to the action's parameters is not present. Absent a usable approval mechanism, the action fails closed.¶

2. An action-bound approval MUST carry a maximum age, bounded by a value the deployment set publishes, and MAY additionally carry an absolute approved_until expiry (the AuthZEN profile surfaces ARAP's approval expiry there, Section 15). The approval is fresh only before the earlier of approved_at plus the maximum age and any approved_until; past that bound the approval is not fresh and the PEP MUST refuse.¶

3. A deployment SHOULD require an action-bound approval for the high-consequence classes, where a token-lifetime-wide standing authority is least appropriate.¶

4. Because the approval is bound to the concrete parameters, it MUST be reverified under the time-of-check to time-of-use rules of Section 8. A parameter change after approval invalidates it.¶

5. The surface that resolves an action-bound approval MUST NOT be invocable from the agent's tool plane or from any channel the agent drives. The resolving principal's identity and achieved authentication context MUST be established by the resolution surface itself, never taken from caller input. An approval resolved through a surface that fails either rule MUST NOT satisfy this section's gate, and the PEP MUST refuse the action.¶

An agent MAY observe an approval's state, and a status poll is often necessary for it to decide whether to proceed; it MAY request an independent approval; it MUST NOT be able to resolve one. Observable, not invokable, is the distinction: whoever nominally holds the resolving credential, the resolution path is not among the agent's tools.¶

The permit lease does not substitute for the maximum-age bound: a permit's validity window (Section 8) bounds the permit, not the age of the approval it relied on.¶

This profile does not define the wire workflow that obtains the approval. A decision-API binding MAY route the requiring denial through a standardized access-request and approval workflow and carry the resulting approval back as decision input; the AuthZEN profile composes with the AuthZEN Access Request and Approval Profile for exactly this (Section 15). However obtained, the approval is decision input, not a bearer grant: the runtime decision of Section 7 remains authoritative, and a persisted grant beyond the single action is a governance state change the fresh decision observes (a Mission expansion, a role or relationship grant, or another authority update), never a property of the approval itself.¶

Two proposed OAuth-native transports are converging on this same per-action moment, and both compose here rather than compete. The transaction authorization challenge ([I-D.draft-rosomakho-oauth-txn-challenge]) has the protected resource return a signed challenge that the client presents to the AS, which obtains approval and issues a token whose authorization_details describe the approved operation; under a Mission, the approval event is the policy behind that challenge, the Authority Set bounds what any challenge can be approved into, and Consent Evidence is its record. The Mission Transaction Authorization profile ([I-D.draft-mcguinness-oauth-mission-transaction-authorization]) defines that cross-domain wire workflow, with the approval as decision input and the issued transaction token restricted to its one recorded transaction. The intent admission assertion ([I-D.draft-jiang-oauth-intent-admission]) has an admission point sign a short-lived assertion binding an intent digest, its originator, an authorized presenter key, and consent evidence, which the executing endpoint re-verifies; a Mission-governed admission point evaluates against the Authority Set, and its consent-by-prior-grant case is exactly a reference to the Mission's committed anchors. In both compositions the durable record this family defines is what makes the per-action artifact accountable to an approved task rather than to policy alone.¶

5.5. PEP Placement

Enforcement only works at the component that can actually stop the action. A deployment claiming this profile MUST observe these rules:¶

• The PEP MUST sit at the last controllable boundary before the action. A permit checked further upstream does not survive parameter changes, retries, or routing that happen after the check.¶

• A credential-issuance decision does not replace execution-time authorization. A Resource Server that only validates credentials cannot claim runtime enforcement; the issuance gate is governance, the runtime gate is enforcement.¶

• A tool-catalog filter does not replace per-call authorization. Filtering a tool list by the caller's authority is exposure control; every consequential tool call MUST still pass the runtime gate.¶

• An orchestrator's internal check does not replace a Resource Server's PEP. Defense in depth is permitted; substitution is not.¶

• If no PEP can prevent the action for a given class, the deployment MUST NOT claim runtime enforcement for that class, and MUST name the action classes and execution paths it does mediate.¶

The boundary varies by action: an OAuth-protected API call is gated at the Resource Server; a consequential MCP tools/call at the MCP server; a local tool invocation, file write, or payment at the orchestrator or whatever component drives the call; external egress at an egress proxy. Where an action can be reached by an unmediated path (a debug shell, an unsanctioned egress route, a direct connector), the profile is not enforced for the classes that path reaches.¶

5.6. Credential Custody and Mediated Execution

In an agentic deployment the agent component is itself part of the attack surface: it may be prompt-injected or compromised. The issuance and runtime gates do not make the agent trustworthy; they bound what it can do. A deployment lowers that bound further by not letting the agent hold the authority whose misuse is unacceptable.¶

Whoever holds the private key a sender-constrained credential's confirmation binds can present the credential. Mediated execution is a PEP placement that uses this: for the action classes a deployment mediates, the sender-constraint private key is held by the PEP that sits at the last controllable boundary (Section 5.5), not by the agent component. The agent therefore cannot present the Mission-bound credential directly; to act, it asks the mediating PEP, which runs the decision of Section 7 and only then uses the key.¶

No new token type, credential handle, or wire protocol is introduced: this is a custody and placement property of the existing sender-constraint key. The mediating PEP is a co-trusted process in the agent's own trust domain, not a delegate: the credential is unchanged, the agent remains the principal of record (its client identity still attributes the action to it), and no actor-delegation chain entry is added.¶

 Agent                Mediating PEP              Resource
   |                  (holds the key)               |
   |-- request ------>|                             |
   |                  | run the decision;           |
   |                  | presents credential ------->|
   |                  |<---------- result ----------|
   |<---- result -----|                             |
   |                                                |
   |     X - - - - - - unmediated path absent - - ->|

For any action class a deployment mediates, the acting credential MUST be sender-constrained: a bearer token is incompatible with mediated custody, because a bearer token can be presented by whoever holds it, including the agent, so the mediating PEP could not be the sole holder of the authority.¶

Independently of mediation, the acting credential for an action in a high-consequence class (Section 5.3) MUST be sender-constrained, whether the Mission reference is credential-carried or externally established (Section 2.3). The PEP MUST NOT supply a confirmation key as a decision input unless it verified the binding with a current proof of possession of that key; a confirmation member alone is not a verified binding. The PDP MUST deny a high-consequence action whose decision request carries no confirmation key. The credential profile defines the binding and its proof ([I-D.draft-mcguinness-mission-runtime-oauth] for OAuth). Sender-constraint makes a stolen credential unusable on its own; it does not protect against compromise of the bound key or of a component that can use it.¶

For an action class it mediates, a deployment SHOULD hold the sender-constraint private key for the Mission-bound credential in the mediating PEP rather than in the agent component, and SHOULD do so for the irreversible-action, external-commitment, and privileged-administration classes.¶

Two properties follow:¶

• a credential exfiltrated from a compromised agent is unusable without the key; and¶

• a compromised agent cannot reach a mediated action without passing the per-action check, because it never holds a usable credential for that class.¶

Mediated execution depends on the agent having no unmediated path to the resource; a Mission-aware harness establishes that execution environment ([I-D.draft-mcguinness-mission-harness]).¶

Mediated custody's realizable form today is gateway custody: a server-side gateway, an LLM gateway, an MCP gateway, or an egress proxy, holds the sender-constraint key and the Mission-bound credentials, and the agent receives no bearer credential at all. That shape is the claim's home: the custody properties above belong to a deployment built this way, and a developer laptop with a shell is outside them by construction, not by configuration.¶

Where the deployment attributes presentations to client instances ([I-D.draft-mcguinness-oauth-client-instance-id]), the sender-constraint key is instance-specific: that profile attributes a presentation to an instance only under a key unique to it ([I-D.draft-mcguinness-oauth-client-instance-id], Section 7.3). Mediated custody composes with that rule in either of two shapes:¶

• the mediating PEP holds per-instance keys, taking custody of each instance's key rather than one shared key; or¶

• the mediating PEP is itself the attested instance that obtained the token, presenting its own Client Attestation and holding the instance key.¶

In both shapes that profile's instance-unique key and this section's custody rules are satisfied together.¶

Attestation-based client authentication and SPIFFE ([I-D.draft-ietf-oauth-attestation-based-client-auth], [I-D.draft-ietf-oauth-spiffe-client-auth]) can supply the client-instance authentication and workload credentials beneath this custody layer; they do not define the Mission actor, delegation, intent, lifecycle, or evidence semantics.¶

This narrows, and does not eliminate, the compromised-agent exposure. The mediating PEP becomes a trusted component whose compromise is out of scope here (Section 17); a compromised agent can still request mediated actions, which are gated, and can still misuse any low-consequence authority it legitimately holds directly. The aim is that the agent is structurally unable to take a high-consequence action unilaterally, not that the agent is trusted.¶

The set of action classes a deployment mediates is the load-bearing parameter here: a deployment that mediates nothing gains nothing from this section, however it labels itself. A deployment that relies on this profile to protect against agent compromise therefore MUST include the high-consequence classes in its mediated set; the protection is only as broad as that set.¶

Custody has a lifecycle. A deployment SHOULD prefer per-class credentials with distinct sender-constraint keys over sharing one key across mediating PEPs, so that compromise of one mediating PEP does not expose the authority of another. On compromise of a mediating PEP's key, the deployment revokes the affected credentials and re-derives. A sender-constraint private key is never published; rotation is re-derivation with a new sender-constraint binding plus revocation or expiry of the credentials bound to the old key.¶

The Enforcement Scope Statement SHOULD state the custody replica topology (a shared HSM-held key versus per-replica keys): replicating one sender-constraint key across a PEP fleet widens the exposure custody exists to shrink.¶

Mediated execution also places a controllable chokepoint on the egress path itself: content-level controls this profile does not define (data-loss prevention, redaction, payload policy) compose naturally at the mediating PEP, the one component that sees the full payload after the decision and before presentation.¶

5.7. Agent-Isolated Evidence Emission

An evidence-signing key is not an authorization credential, and its signature MUST NOT be accepted as a grant or as widening the Authority Set. Its compromise corrupts the record plane and, where signed history is a decision input (Section 2.7.8), can also corrupt later authorization outcomes within that envelope: a forged record is a forged precondition (Section 17). The record plane is what a post-compromise investigation relies on, so the property that the agent cannot emit records under an emitter's identity has an owner here, as a standalone condition a deployment claims per emitter and scope. No named claim of this document includes it; a composition that wants both prevention and post-compromise evidence assurance names it explicitly alongside the claims of Section 9.5.¶

A deployment claims the agent-isolated evidence-emission condition for a named emitter (a PDP, a mediating or executing PEP, or a companion-defined executor-side emitter) and scope only when all of the following hold:¶

• the evidence-signing private key is generated inside the declared trusted holder boundary, or imported through a trusted procedure in which the agent never possesses plaintext key material, and is non-exportable to, and inaccessible from, the agent component, with that property preserved across rotation, backup, replication, restore, and migration;¶

• only an authenticated identity for the named emitter's trusted emission path can invoke the signing operation;¶

• the agent cannot submit a complete evidence object, or an arbitrary digest, for signature;¶

• the trusted emission path constructs the record from its authoritative decision, refusal, or execution state and from request inputs it independently validates and normalizes; the caller cannot supply the completed record or directly assert the emitter identity or role, the decision or outcome, the protected record type, the sequence position, the evaluation or execution identifiers, or the authoritative interpretation of the Mission, scope, audience, and digests; and¶

• a signing result cannot be relabeled or reused for another emitter, role, scope, audience, or evidence type.¶

The load-bearing property is the authenticated construction-and-signing path, not the storage technology: an HSM or KMS whose API the agent can invoke over arbitrary bytes is a signing oracle, a separate process the agent controls is not isolated, and an in-process signer inside a trusted PEP can be isolated where the control boundary is real. A signing service MAY accept a digest rather than the record, only over an authenticated channel from the trusted emission path with the record type and protected scope bound to the request; the signer is not required to parse the record schema.¶

The condition bounds forgery, not activity: the agent can still trigger real decisions and effects that cause the emitter to create its own records of them; it cannot invent or alter a record under the emitter's identity. The condition establishes neither the truth of an emitter's assertion nor the completeness or ordering of the evidence stream; those remain the concern of reconciliation, sequence-gap detection, and the transparency mechanisms (Section 11, [I-D.draft-mcguinness-mission-audit]).¶

Agent-invokable approval resolution can leave evidence-emission isolation intact while defeating the approval gate. An isolated emitter can faithfully record a decision whose approval input the agent supplied by invoking a resolution surface, even when the nominal Approver is a distinct principal. Emission-path validation alone does not establish independent resolution; the approval-resolution boundary in Section 5.4 supplies that rule.¶

Key separation is not part of this condition: an evidence-signing key SHOULD be cryptographically distinct from every sender-constraint, token-issuance, approval, and other authority-bearing key; a composing profile MAY require that separation; and isolation of one key plane MUST NOT be inferred from separation or custody of another.¶

A deployment SHOULD satisfy this condition for every emitter whose records cover the high-consequence classes. Signer unavailability MUST NOT fall back to an agent-held key, to an unsigned record represented as verified, or to an unconstrained signing path, and it relaxes neither Section 11 nor the runtime evidence companion's required envelope. Enforcement MAY continue through an outage only where the trusted emission path durably commits every required record for signing and publication under a declared recovery bound, preserving ordering and this condition; otherwise the deployment is not conforming for the affected decision or refusal and MUST NOT represent the condition as continuously satisfied. An execution outcome discovered after its effect is durably queued and reconciled, never synthesized or silently omitted (Section 2.11).¶

On a declared compromise of an evidence-signing key, the runtime evidence companion's key-set lifecycle applies ([I-D.draft-mcguinness-mission-runtime-evidence]). The declared boundary is deployment-declared semantics and does not by itself resist backdating: a holder of the key can sign records carrying earlier timestamps. A record under a compromised key can be shown to have existed before the declared boundary only by an independent existence proof (a trusted timestamp, a transparency inclusion, or a Receipt, [I-D.draft-mcguinness-mission-audit]); even then the proof establishes existence before the declared boundary, not that the key or emitter was uncompromised earlier, and not that the assertion is true.¶

The Enforcement Scope Statement declaration for this condition is per covered emitter, together with its key set and custody policy (optionally naming kid coverage): the emitter identity and role, the holder's trust boundary, the authorized invocation path, the mechanism class (separate process or service, HSM or KMS, attested environment), the custody and replica class across rotation, backup, replication, restore, and migration, the covered action classes, scope, and audience, whether the key is shared, the key-separation posture, and an audit or attestation reference (Section 5.2). Routine rotation under the same holder and invocation policy does not require a new declaration; a change in trust boundary or signer policy does. The declaration discloses no operational secret. At base the declaration is declared-only; under a named claim that composes this condition, the attested or audited material covers the workload identity, the signer policy, and the trusted emission path, not merely the private key's location, and the weakest self-declared or organizationally audited term is named plainly, as Section 9.5.1 does for path scope.¶

5.8. Least Exposure

A Mission bounds exposure as well as authority. An agent exceeds the Mission envelope by invoking an action outside the Authority Set, but also by being exposed to inputs the approved task does not need: tools, data, memories, prompts, schemas, credentials, or downstream responses. Authority bounds what execution can do; exposure bounds what reasoning can see, and unnecessary context is the raw material of prompt injection and within-scope laundering.¶

A Mission-aware runtime SHOULD minimize exposure of prompts, retrieved documents, memory, tool catalogs, schemas, credentials, and downstream responses to what the active Mission needs. Where mediated custody is the deployment's declared control for an action class (Section 5.6), credential material and the sender-constraint private key MUST NOT be exposed to the agent component: exposure reduces mediation to advice.¶

Least exposure narrows what injection can read and what within-scope laundering can draw from; it is not information-flow control, and an exposure filter, like a tool-catalog filter (Section 5.3), never replaces per-action authorization.¶

7.1. Materialized Policy View

This section governs a PDP that evaluates a Mission against an action through a materialized policy view: the reproducible, evaluable form of the Mission's approved authority, produced by the Mission Issuer or a trusted compiler and loaded by the PDP. A PDP can instead evaluate the Mission's recorded authority directly; the authority bounds, the state-source rule, and capability-source provenance apply either way (Section 2.7.1). A trusted compiler is a component the deployment trusts to materialize the Mission's approved authority faithfully and reproducibly; it is in the deployment's trust domain and its output is bound by the content-addressed policy_view_id below. The view is substrate-independent runtime machinery; a decision-API binding carries only its identifier on the wire (Section 15).¶

The materialized policy view MUST satisfy three properties:¶

• Reproducible: identical manifest inputs, including the compiler identity, produce a byte-identical manifest, and therefore an identical policy_view_id, under the canonicalization rules of [I-D.draft-mcguinness-oauth-mission].¶

• Identifiable: the view carries a policy_view_id, so PDP cache entries are addressable.¶

• Bounded: materialization is faithful and does not enlarge the Authority Set's semantic bounds. A materialized view is an evaluation aid, never new authority.¶

The committed object is a canonical JSON manifest, never the engine binary itself: JCS canonicalization applies to the manifest, and an engine-native artifact enters the manifest only by digest, never directly. policy_view_id is the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]) of the SHA-256 [RFC6234] of the JCS [RFC8785] canonical bytes of that profile's domain-separated, issuer-bound integrity-anchor envelope with typ mission-policy-view:¶

SHA-256(JCS({
  "typ":   "mission-policy-view",
  "iss":   <mission.issuer>,
  "value": <materialized view manifest>
}))

policy_view_id is an envelope anchor under the substrate's default commitment construction, which this document imports normatively ([I-D.draft-mcguinness-mission-substrate]).¶

The committed manifest MUST carry:¶

• mission_id and authority_hash: the Mission's identifier and Authority Set integrity anchor.¶

• policy_version: the derivation policy_version recorded at the approval event.¶

• compiler: an object naming the trusted compiler that produced the manifest, with profile (the compiler's identity) and version (its version), so a change in compiler identity or version is itself a reproducibility input rather than an unaccounted difference.¶

• Either policy_ir, the normalized policy intermediate representation as JSON, or artifact, an object carrying digest (the integrity-anchor encoded digest of the engine-native artifact) and encoding (naming the artifact's format), for a deployment that compiles to an engine-native form this document does not standardize.¶

The manifest MUST NOT embed Mission lifecycle state: three independent values govern reliance, and conflating them is the common implementation error. policy_view_id is the content identity of the compiled authority and the cache key. A mission_state_version, the state version a Mission state source reports where it reports one, versions the mutable lifecycle state the decision consulted. The state observation's freshness or lease bounds how long that consultation stands (Section 2.5). A state transition invalidates reliance through the version and freshness values without re-identifying the compiled authority; the manifest acquires a new policy_view_id only when the authority it compiles, or the compiler that compiled it, changes. A consistency check between a decision request's Mission reference and the loaded view is therefore an equality test: the request's Mission id and authority_hash either equal the committed values or the view does not apply. Because policy_view_id is a content hash, any change to the manifest yields a new policy_view_id, so equality on policy_view_id is the cache identity; it is never the freshness test. This document defines no second canonicalization and no policy-language wire form for policy_ir or the engine-native artifact.¶

7.2. Semantic Evaluators

A structurally valid action can still be semantically out of bounds: every schema check passes while the content betrays the task. A deployment MAY add a semantic evaluator (a data-loss-prevention engine, an LLM-based content policy, an embedding-similarity check) to the decision path. This profile does not standardize the evaluator; it fixes how one composes:¶

• Rubric. The evaluator judges content against the approved task, not a free-floating policy: its rubric is the recorded Mission Intent, whose integrity is verifiable against intent_hash, optionally with the consented Authority Set under authority_hash. A rubric that cannot be tied to the committed record is ordinary deployment policy, not a Mission check.¶

• Composition. The verdict enters the decision as Resource policy, carried as deployment-defined context. It can deny, or route the action to the existing affordances: an action-bound human approval (Section 5.4, the decision API binding's approval_required) or an authentication step-up, which the decision API binding carries as an obligation on the permit (Section 15). It MUST NOT widen authority and MUST NOT substitute for a structural check this profile requires.¶

• Evidence. When a verdict contributes to a decision, the decision evidence SHOULD record the evaluator's identity or version and its verdict, so a semantic denial is as reconstructable as a structural one.¶

• Latency. The evaluator runs inside the invoking action class's latency budget (Section 13); a deployment that cannot afford a synchronous evaluation on a class routes the class to action-bound approval or narrows its authority instead.¶

An LLM-based evaluator is itself part of the attack surface: it reads the same adversarial content it judges, and can be injected by it. It therefore augments the structural signals (provenance, composition, enumeration, volume, re-consent) and never replaces them, and a deployment that relies on one for an action class states that reliance in its Enforcement Scope Statement.¶

8.1. Binding for Consequential Reads

Consequential reads do not require a parameter digest by default; the evaluation request still appears in the evidence record, by digest where the parameters are sensitive (Section 11).¶

Deployments MUST require parameter binding for consequential reads when read parameters materially change the effective resource set or disclosure risk. Independent of that risk judgment, a binding floor applies: a consequential read whose parameters select a cross-tenant or cross-audience scope, request a bulk or export-like result, or choose the returned fields or destination MUST bind those parameters. A deployment MUST NOT classify such a read as not materially affecting the resource set. Other examples that materially change the resource set or disclosure risk include privacy-sensitive filters and aggregation level. Ordinary reads that do not change the resource set or disclosure risk can remain unbound.¶

9.1. Evaluation-Context Binding

The evaluation context of a decision is the set of resource-resolved facts, declared decision-relevant by the Operation Profile, whose values the decision depended on.¶

Evaluation-Context Binding is an OPTIONAL Named Assurance Extension, claimed per mediated action class in the Enforcement Scope Statement. It does not add a requirement to Runtime-Enforced conformance for a deployment that does not claim it. The Operation Profile owns its declaration; an approval-time resource contract can reference that declaration but supplies no dispatch-time observation.¶

A claiming deployment MUST publish the covered classes and operations, each operation's versioned binding descriptor, and whether it reaches the verified or enforced property below. The descriptor MUST identify each decision-relevant fact, its authoritative resolution interface, normalization, and granularity: revision (an opaque version or entity tag) or effective_values (the enumerated resolved fields). Mixed granularities are represented per fact, never by an ambiguous scalar mode. An enumerated target set commits every selected identity in the declared canonical order; a predicate or cardinality bound MUST NOT be represented as equivalent to that set commitment.¶

The descriptor's reference is an object with id (a URI), version (a non-empty string), and digest (the canonical-object digest of the descriptor). Published descriptor bytes MUST remain immutable for that reference. The bound evaluation-context object contains that reference, the qualified Mission identity, operation and resolved target identities, the normalized facts, and a secret salt with its version. The PEP MUST commit the descriptor reference with the facts in evaluation_context_digest, using the canonical-object digest construction and sha-256: encoding of Section 2.8; this extension defines no second canonicalization or hashing algorithm.¶

The enforcing PEP MUST capture the declared facts from their authoritative interfaces and MUST NOT accept agent-supplied values as those observations. Requester and executor remain one enforcement identity. Agent arguments remain bound as parameters; authoritative facts remain available to the PDP wherever policy needs their values. The context digest is a PEP-supplied observation, not a value the PDP can independently recompute, and does not attest that a compromised PEP is honest.¶

Adoption MUST preserve existing approval-to-decision, transaction-token, parameter, and operation-idempotency bindings. Moving a fact into the evaluation context MUST NOT permit an earlier approval or operation identity to authorize changed effect parameters after fresh context capture. Overlapping commitments are permitted where each preserves its distinct property; adoption does not require shrinking an existing parameter digest. The Operation Profile identifies every consumer of a changed digest form and its migration rule, including vendor/target identity, amount/currency and destination facts where applicable.¶

The salt MUST be unpredictable, secret, qualified by Mission and version, and retained for the lifetime of every outstanding binding that uses it. It never appears in decision requests or evidence. It MUST survive restart and be consistently available to the PEP replicas that can use those bindings, on the terms Section 9.2 sets for the consumed-identifier store; a deployment MUST fail closed for a binding whose salt or descriptor cannot be recovered, rather than silently replacing either. This is persistent secret-state coordination, not a stateless digest scheme. Salting limits guessing of low-entropy values; digest-only evidence still exposes equality and linkability.¶

The PDP MUST return the supplied context digest as a permit condition for a covered operation. The executing PEP MUST re-resolve the declared facts and recompute the bound context with its own applicable descriptor immediately before releasing the effect, in the same step as the parameter_digest recomputation of Section 9.4. A missing binding, changed descriptor, unequal digest, or unavailable fact MUST cause refusal before any effect. A condition on an operation outside the declared binding is invalid there. The normal invalid-condition and permit-binding rules still apply; the request or retrospective evidence cannot replace the permit condition.¶

An inability to capture context before requesting a Decision produces a pre-decision Refusal Record. After a permit exists, failure to re-resolve or match the context produces Execution Evidence with outcome suppressed and error target_drift, not a new PDP denial reason. The extension composes with the single-use rule (Section 9.2) and never substitutes for it, changing neither single-use consumption nor retained-permit retry semantics. Every consequential phase captures and checks its own context; a fact declared prepare-stable SHOULD also be compared across prepare and commit, without reusing either phase's permit.¶

The verified property is a successful reread and comparison. It leaves a possible resource change between that comparison and the effect. Where the authoritative resource supports a conditional effect, the PEP SHOULD carry the bound revision as a precondition (for example If-Match or an expected-version compare-and-swap). The enforced property MUST NOT be claimed without an atomic resource-side comparison coupled to the effect. These are declared properties of this extension, not new Mission Assurance Levels. Neither covers undeclared facts, arbitrary set-valued targets, or all policy changes; non-adopters retain the TOCTOU residual.¶

9.2. Single-Use Identifiers

Where a single-use decision identifier is used:¶

• The enforcing component MUST record consumed identifiers for at least the permit lifetime.¶

• The enforcing component MUST refuse, fail closed, any second presentation of a consumed identifier. This is independent of consumption metering and applies even when the action carries no consumption bound.¶

• The consumed-identifier store MUST survive an enforcing-component restart, or the component MUST fail closed for permits issued before the restart.¶

• A multi-instance PEP MUST share or partition the store so a single-use identifier cannot be consumed once per replica.¶

9.3. Idempotency

A single-use identifier bounds executions of one permit, not permits for one action. Enforcement is an atomic state machine over the (idempotency scope, idempotency_key) pair, not a comparison against retained parameters, with three separated responsibilities: the PDP prevents concurrent double-permits before an operation completes, the PEP prevents a consumed permit from executing twice, and the resource owns the lifecycle and prior result of a completed operation.¶

• For every non-idempotent operation in the irreversible-action, external-commitment, and privileged-administration classes, the Operation Profile MUST therefore also define an idempotency key.¶

• Before issuing a permit for a keyed action in the irreversible-action, external-commitment, or privileged-administration classes, the PDP MUST atomically claim the pair (idempotency scope, idempotency_key) together with the request's operation identity, a canonical projection a decision-API binding defines ([I-D.draft-mcguinness-mission-authzen]). The claim is a single linearizable operation: of two concurrent requests presenting the same scope and key, exactly one obtains the claim, and the other observes it.¶

The claim's exactly-one-winner property has the same non-degradable shape as the metering companion's exclusive latch ([I-D.draft-mcguinness-mission-metering]). Two enforcement profiles describe how single-winner state is held across replicas:¶

Exact enforcement profile:

The check and the update are atomic against one authoritative record: a single serializing PDP, a shared linearizable store, or claim domains that are structurally exact by construction.¶

Bounded-consistency enforcement profile:

Replicas share the state without linearizable coordination and converge within a published bound, so two of them can each accept the same claim before they converge.¶

The metering companion applies the same two profiles to its counters ([I-D.draft-mcguinness-mission-metering]).¶

• The idempotency claim MUST be enforced under the Exact enforcement profile: a single serializing PDP, a shared linearizable store, or claim domains that are structurally exact by construction.¶

• The Bounded-consistency enforcement profile MUST NOT be applied to the idempotency claim: an exactly-one-winner claim cannot degrade gracefully, the same reason the metering companion bars exclusive from Bounded consistency ([I-D.draft-mcguinness-mission-metering]).¶

• A PDP or store that cannot reach its declared Exact domain MUST fail closed rather than issue a permit.¶

• The deployment MUST name the Exact claim domain per mediated action class or idempotency scope in its Enforcement Scope Statement (Section 5.2), not as an enumeration of individual dynamic claims.¶

Evaluation retransmission (PDP):

For a re-presentation whose cache key is equal to the prior decision's and whose claim matches (same idempotency scope and key, same operation identity), while the prior permit is unexpired and its evaluation_id unconsumed, the PDP SHOULD return the prior decision, so a permit response lost in transit does not lock the action out for the reconciliation window. This is the only same-key path that returns a permit: the PDP claim's purpose is narrowed to preventing concurrent double-permits before completion, never to replaying a completed result.¶

Permit replay prevention (PEP):

Unchanged: the single-use rule of Section 9.2 is itself atomic. Before releasing the effect of a use_limit-bearing permit, the enforcement scope MUST atomically consume, or atomically reserve and then confirm, the evaluation_id in a store that is linearizable across every PEP replica of the scope. Two replicas MUST NOT both succeed in consuming the same identifier; a replica that instead observes an already-consumed identifier treats the presentation as consumed, not as a fresh single use, a decision-API binding's permit_consumed classification ([I-D.draft-mcguinness-mission-authzen]).¶

Operation idempotency (Resource Server / Operation Profile):

The resource, not the PDP, owns the key's lifecycle and the prior result once an operation completes: for a COMPLETED duplicate the resource returns the prior operation result under the Operation Profile's rules. A fresh authorization denial is not the vehicle for result replay; the claim states below govern only whether a new permit issues, never what the resource returns for a completed key.¶

The claim resolves per state, keyed on whether the presented (idempotency scope, idempotency_key) pair matches an existing claim and whether the request's operation identity equals the one the claim was made under:¶

A different operation identity under the same key is always a conflict, never a new execution: an idempotency key identifies one intended execution of one normalized request, the same discipline HTTP's own Idempotency-Key handling applies, restated here in the family's own terms. A consumed key never yields a second execution: retransmission returns the prior decision, and a completed operation's result is replayed by the resource, not re-executed. An intentional re-execution of the same normalized action is a new operation under a new idempotency key, never a retry under the consumed one, and an action-bound approval (Section 5.4) authorizes that new operation as such, never re-execution under the consumed key.¶

• The idempotency scope is, at minimum, the Mission, the subject and the actor, the audience, the action, and the resource; a deployment MAY narrow it further and MUST publish the scope in its Enforcement Scope Statement. Volatile members MUST NOT be added to the scope.¶

• Where compound-action phases share an action identifier, the idempotency scope MUST include the phase (Section 2.10).¶

• For the high-consequence classes the deployment MUST retain a durable consumed-key record (a tombstone) for at least its declared idempotency horizon, published in the Enforcement Scope Statement. Tombstones are enforced, not merely retained: within that horizon a claim against a tombstoned key MUST be refused, never treated as a fresh claim. Outside those classes a deployment MAY scope the guarantee to the reconciliation window (Section 11), and it MUST publish which posture applies.¶

The PDP makes no claim for a reversible consequential write's idempotency-key control (Section 2.9): that control is not one of the classes above. Narrowing the PDP claim to those classes does not narrow this guarantee; it moves the enforcement point. The enforcing PEP or the resource MUST instead atomically reserve the (idempotency scope, idempotency_key) pair against a concurrent duplicate, and MUST retain the reserved-or-completed record for at least the retention posture the deployment publishes above for keys outside the high-consequence classes, so a duplicate arriving after the permit's own short validity window still resolves against the recorded key rather than executing again. This is the same single-winner discipline as Section 9.2, applied to the key instead of the decision identifier.¶

9.4. Execution Reverification

The executing PEP MUST verify the permit's bindings (Section 2.9) and MUST recompute the parameter_digest against the parameters it is about to use. A mismatch MUST cause refusal: the permit does not authorize the changed parameters.¶

The phase comparison of Section 2.10 runs at this same use boundary. A mismatch suppresses execution and is recorded as Execution Evidence, not as a pre-decision Refusal Record; an inability to establish phase before asking for a Decision is a pre-decision refusal instead.¶

A permit authorizes initiation. An action still executing when the permit expires MAY run to completion, unless the action class requires an execution lease, which the Operation Profile defines; when a lease is required the executing PEP MUST stop or renew before the lease expires. For the irreversible-action, external-commitment, and privileged-administration classes the Operation Profile MUST define an execution lease or a published maximum execution duration, and run-to-completion applies only within that bound.¶

This closes the time-of-check to time-of-use gap and prevents a permit from being replayed for a different request (the parameter_digest mismatches). For non-idempotent consequential writes, irreversible actions, external commitments, and privileged administration, the single-use decision identifier prevents repeat execution under one permit (Section 9.2), and the required idempotency key prevents repeat execution of the same normalized action across separately obtained permits (Section 9.3).¶

9.5. Named Enforcement Claims

The strongest properties this profile enables 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. This section defines them as named claims, each a conjunction of conditions specified elsewhere in this profile, each individually verifiable, and none implied by base conformance. A deployment publishes the claims it makes, and the classes each covers, in its Enforcement Scope Statement (Section 5.2), and demonstrates them with the negative tests of Section 12. The two claims together are the High-Assurance Agent bar of the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]).¶

11.1. Execution-Outcome Evidence

For an action in the high-consequence classes, the executing PEP MUST also produce, after it acts, an execution-outcome record keyed to the permit's evaluation identifier, recording at least success or failure and the effective parameter digest actually executed, alongside the authorized parameter digest the permit bound ([I-D.draft-mcguinness-mission-runtime-evidence]). This lets a decision and its execution be reconciled one to one, so a permit that was obtained but executed more than once, or executed for different parameters, is detectable after the fact. The detailed object schema is the Execution Evidence Object, defined by the runtime evidence companion ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

Reconciliation is bounded in time by the reconciliation window, orphan-detection component, and alerting obligation the Enforcement Scope Statement declares (Section 5.2): an execution-outcome record is expected for each decision within the window, and the named component detects orphaned evidence (a decision with no matching execution-outcome record within it) and sequence gaps in a Mission's records (Section 11.3).¶

An unknown outcome has an owner and a deadline, not only a window: the declared component MUST actively reconcile each unresolved outcome before the window closes, querying the resource and matching evidence, and record the outcome the evidence establishes (completed, failed, or suppressed, [I-D.draft-mcguinness-mission-runtime-evidence]). Evidence, never the deadline, determines the result: an outcome the component cannot establish stays undetermined-outcome, is escalated under the declared alerting obligation, and is never synthesized into a terminal result. Reconciliation survives the Mission: once the Mission is non-active, it MAY record the outcome of work already initiated and MUST NOT admit a new effect under that Mission (an action already executing follows the run-to-completion rule of Section 9.4, unchanged). Consumed and reserved decision identifiers and idempotency claims persist across Mission lifecycle transitions for at least the reconciliation window and any declared tombstone horizon (Section 9.3): termination does not erase them, so a post-termination retry resolves against the recorded claim rather than executing again. An unresolved claim never becomes reusable through time alone: when the window closes on an undetermined outcome, the claim converts to a non-reusable indeterminate tombstone, retained for at least the declared idempotency horizon and released only by an evidence-recorded operational resolution, never by expiry into a fresh claim.¶

11.2. Mission Receipt

A Mission Receipt is the portable, tamper-evident projection of runtime enforcement evidence: portable evidence of exactly what its kind claims (a rendered decision, an executed action's terminal outcome, or a pre-decision refusal, [I-D.draft-mcguinness-mission-runtime-evidence]), as a Mandate ([I-D.draft-mcguinness-mission-mandate]) is portable evidence about the Mission itself.¶

A Mission Receipt MUST identify the Mission the action was authorized under, as mission.id and mission.issuer; a verifiable Mission projection such as the cross-domain grant's mission claim ([I-D.draft-mcguinness-oauth-mission-cross-domain]) travels beside the receipt at its carriage layer, never in place of the tuple. It MAY project the policy decision (the decision identifier and result), the policy state it was decided under (the PDP's policy-view version and the Mission's policy_version), the executor (the authenticated actor and any actor-delegation chain), the custody boundary (whether a mediating PEP held the credential, Section 5.6, carried as a profiled issuer assertion), the downstream target (the resource and audience), the outcome, the timestamps, and, where a deployment chains receipts, the digest of a predecessor Mission Receipt. The portable schema, receipt kinds, evidence references, verification, and chaining are defined by [I-D.draft-mcguinness-mission-runtime-evidence], which fixes the minimum join and integrity core every Mission Receipt carries; the members above are what a receipt MAY project beyond that core.¶

11.3. Record Integrity and Retention

The following requirements apply to every record:¶

• The Resource Server runtime profile MUST define the record's concrete serialization and canonicalization before storage and integrity protection. JSON records SHOULD use JCS [RFC8785] under the issuance profile's canonicalization rules.¶

• It MUST be append-only and integrity-protected; the enforcement scope MUST name the mechanism (a hash-linked log, signed segments, a transparency anchor, or equivalent). Where a JSON record is individually signed, the evidence_envelope JWS convention of the runtime evidence companion ([I-D.draft-mcguinness-mission-runtime-evidence]) is the suite's one signing convention for evidence objects and SHOULD be used, with the protected typ that convention fixes and a cty that names the record's own media type, rather than a record-specific signing scheme.¶

• Raw parameters MUST NOT appear in the record; when retained for forensics they MUST be in separately access-controlled storage referenced by an opaque identifier, with only the parameter_digest in the record. A deployment SHOULD retain the normalized parameters of denied high-consequence attempts in that forensic store, so an auditor can reconstruct what was refused, not only that a refusal happened.¶

• Records for one Mission MUST carry a deployment-defined sequence indicator, scoped per emitter, so gaps are detectable and one emitter's records order without relying on wall-clock time alone. This does not by itself reconstruct Mission-wide decision order across emitters; that ordering is best-effort, from the correlation members and each record's timestamps together ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

• The retention window declared in the Enforcement Scope Statement MUST be no shorter than the Mission's audit horizon, as defined in the Mission Record section of [I-D.draft-mcguinness-oauth-mission].¶

Digest encoding is uniform across this document family: every digest a family document defines uses the sha-256: prefixed base64url, no-padding encoding of the issuance profile's integrity-anchor rules ([I-D.draft-mcguinness-oauth-mission]). The exceptions are externally fixed encodings: the COSE hashed payload of the audit companion's Signed Statements ([I-D.draft-mcguinness-mission-audit]) carries the raw digest bytes the COSE hash-envelope mechanism requires, and the attenuation substrate's parent-hash form ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]) is unprefixed base64url. Each exception is identified by its carrying context; the sha-256: prefix appears in neither.¶

14.1. Outage Blast Radius

The primary axis is action class, as in Section 5.3 and Section 2.11. The security model's Revocation-to-Action Latency table describes a different axis: what a committed revocation stops ([I-D.draft-mcguinness-mission-security-model]).¶

Every cell is conditional on dependency topology. An issuer outage does not imply that an independently operated authoritative state source is down. Conversely, a PDP or a fallback state source may depend on the failed issuer. New issuance or mutation stops when its required authoritative control-plane dependency is unavailable, not merely when a component with a particular name fails.¶

Continued execution requires the credential, state observation, permit, parameter binding, use limit, metering/latch state, and every other applicable input to remain valid. A fallback cannot re-stamp an older observation. Paths outside the enforcement claim remain outside it: continued effects or reconstructed provenance on such a path do not demonstrate available Mission enforcement. Per-entry perimeter dispositions can refine the table when that declaration shape is adopted; they do not change the action-class requirements.¶

14.2. The Remaining Window Is the Ride-Through

A deployment SHOULD publish, for each action class, the availability consequence of its declared staleness bound and the recovery objective considered when choosing it.¶

The ride-through is the minimum remaining applicable credential, state, permit, and other validity window at the point of use, subject to prior consumption and all non-temporal checks. It is not a new window that begins when an outage is detected. A bound shorter than the dependency's recovery objective describes a designed halt. Recovery objectives can inform a bound within the security ceiling; they cannot justify extending that ceiling during an incident or resetting a permit's validity.¶

The PDP-unavailability posture already declared in the Enforcement Scope Statement can choose a stricter immediate stop or bounded use of existing permits. It cannot authorize a missing decision, reuse a consumed permit, or skip parameter, action, state, and other permit conditions.¶

14.3. Positive Break-Glass Is a Declared Separate Mode

A deployment providing positive emergency authority SHOULD declare the mode in its Enforcement Scope Statement, require dual control and automatic expiry, retain truthful activation and action evidence, and identify the affected actions as excluded from its Mission enforcement claim.¶

Evidence identifies the independent authority, activation, scope, expiry, and excluded claim. It does not fabricate a PDP Decision or Mission permit when the ordinary path could not produce one. Activations are counted and reviewable. The ordinary Mission path continues to fail closed; emergency authority is a separate mode, not a successful result of that path. The Positive emergency authority is separate section of [I-D.draft-mcguinness-mission-control-plane] states that separation.¶

14.4. Replication Is a Declared Deployment Property

A deployment using replica-served state sources SHOULD disclose, in its Enforcement Scope Statement, the replication model and lag counted inside each published staleness bound.¶

This recommends no consensus protocol or leader architecture. The observation must be justified by the deployment's consistency mechanism; a signature or new signing key does not turn a lagging value into a fresh one, per the Fresh observations, not fresh signatures section of [I-D.draft-mcguinness-mission-control-plane]. Operators watch observation age, available fallback sources, propagation gaps, permit refusals, and recovery progress. Metrics targets and fleet benchmarks are separate deployment work.¶

17.1. What This Layer Adds, and Its Limits

Gating every consequential action against the current Mission prevents an active Mission from acting as ambient authority (Section 7, Section 8, Section 11), closing the approval-to-execution gap the issuance profile leaves open.¶

It governs actions, not meaning. A request can satisfy every structural check while its content does harm no schema names: the approved send_email whose body carries what an injection extracted. The profile's answer is to convert semantic risk into structural signals rather than ask the PDP to judge content: provenance (the harness taint context and its default-taint polarity, [I-D.draft-mcguinness-mission-harness]), composition (the quarantine pattern, [I-D.draft-mcguinness-mission-architecture]), egress-channel enumeration (Section 9.5.2), volume bounds and exclusivity ([I-D.draft-mcguinness-mission-metering]), and action-bound re-consent for the highest classes (Section 5.4). A deployment that additionally runs a content evaluator (data-loss prevention, an LLM-based content policy) composes it as Resource policy at the PDP: the verdict enters the decision as deployment-defined context, only ever narrows, and its latency belongs to the action class that invokes it (Section 7.2).¶

It does not make a compromised enforcement component safe. A compromised PEP can decline to consult the PDP or ignore its decision; a compromised PDP can return whatever decisions it chooses. Decision and enforcement evidence make such behavior auditable after the fact; they do not prevent it in the moment. Signed, externally verifiable decisions are future work (Section 16).¶

17.2. Placement and Bypass

The strongest decision logic is void if the PEP is not at the last controllable boundary, or if an unmediated path can reach the action (Section 5.5). A deployment's claim is only as strong as the set of execution paths it actually mediates, and that set is the Enforcement Scope Statement's mediated-paths declaration (Section 5.2).¶

17.3. Prompt Injection and Exfiltration

This profile assumes the agent can be prompt-injected and does not try to prevent that. It constrains what an injected agent can do by gating the external-communication leg: external communication is a consequential action, so every attempt is checked against the Authority Set, bound to parameters, metered, and (with mediated execution, Section 5.6) made unreachable to an agent that does not hold the egress credential. This is the architectural defense, gate the exfiltration against an authority the injection cannot widen, rather than make the agent injection-proof. Least exposure (Section 5.8) is the input-side complement: it shrinks what an injected agent can read and what within-scope laundering can draw from, without changing the limits below.¶

Two limits are inherent and a deployment MUST NOT overstate the guarantee. First, it is exactly as strong as PEP-placement completeness: every exfiltration channel an agent runtime offers (DNS, logs, error strings, a write to a store another process reads) is a channel that must be mediated, and this profile gates the channels routed through a PEP but cannot prove a deployment enumerated them all (the Achilles' heel of Section 5.5). Second, this profile provides no information-flow control: it evaluates each action in isolation against authority over resources and actions, so a sequence of individually-authorized steps can compose into an exfiltration no single check catches (within-scope data laundering), and cumulative consumption bounds, where metered ([I-D.draft-mcguinness-mission-metering]), bound volume, not flow. Closing that needs a separate taint or information-flow layer. A coarse session-level mitigation, downgrading egress authority once untrusted content has entered a session, is available at the harness layer ([I-D.draft-mcguinness-mission-harness]); it raises the bar but is not information-flow control.¶

17.4. Relationship to Inspection-Based Controls

Inspection-based runtime defenses for agentic systems share this profile's premise that the agent application is part of the attack surface (Section 5.6), and combine deterministic checks over the message flow with semantic checks over the agent's intent. This profile is the authority half of that picture; it composes with, but does not replace, an inspection layer.¶

Two of this profile's mechanisms are deterministic checks of that kind. Parameter binding (Section 8) ties a permit to the concrete parameters the action executes with, so an application cannot alter a tool call's arguments after the decision. Capability-source binding, in the capability-binding companion ([I-D.draft-mcguinness-mission-capability-binding]), ties an approved action to the digest of the capability definition it was derived from, so a swapped or poisoned tool definition fails the decision. Both refuse the action; neither inspects the agent's reasoning.¶

Two adjacent checks are out of scope (Section 16). This profile evaluates the request path: it does not verify the integrity of the result a tool returns as the application relays it back to the agent's model, so an application can still falsify what the model sees; and it does not by itself establish that an executed action reflects the model's own decision rather than an application substitution. Mediated execution (Section 5.6) bounds the second case, since an action outside the Authority Set is refused however it arose, but it does not bind the executed action to the model's decision; a deployment that can establish that correspondence SHOULD. Both sit at the semantic and grounding boundary the issuance profile names a non-goal ([I-D.draft-mcguinness-oauth-mission]).¶

A semantic intent-alignment signal, for example a judgment that a requested tool fits the task extracted from the conversation, MAY be supplied to the PDP as advisory decision input. Such a signal MAY contribute to a denial; it MUST NOT widen, grant, or refresh authority, consistent with the inert treatment of goal and purpose in the issuance profile ([I-D.draft-mcguinness-oauth-mission]). Gating authority on intent inference is out of scope: verifying an agent's declared reasoning against the task is an attestation problem outside both layers, and intent inference is not reliable enough to be load-bearing for high-consequence authority.¶

17.5. Classification Integrity

Because "consequential" is partly deployment-defined, the classification floor of Section 5.3 is load-bearing: a deployment cannot evade enforcement by classifying a high-consequence action as non-consequential. A purpose may raise a class but never lower it below the resource owner's floor.¶

17.6. Freshness and Consumption Honesty

A permit is a lease, not a standing grant: stale Mission state MUST fail closed for consequential actions within the published bound (Section 2.5). A deployment MUST NOT advertise consumption enforcement it does not perform (Section 10); where cumulative bounds are metered, the exactness and consistency claims of the metering companion apply ([I-D.draft-mcguinness-mission-metering]).¶

17.7. The History Input

The history input (Section 2.7.8) makes prior evidence load-bearing for later decisions, so it is attacker-adjacent wherever evidence producers are compromised: a forged record is a forged precondition, and a suppressed record denies the step that depends on it. This is the existing evidence-integrity story, not a new one; the record integrity requirements of Section 11.3 and the transparency mechanisms of the audit companion ([I-D.draft-mcguinness-mission-audit]) are the countermeasures, and a deployment that makes history load-bearing weighs them as part of the decision path, not only as after-the-fact audit. Shaping Evidence is never an input to this or any authorization decision; the shaping profile's existing prohibition stands unchanged ([I-D.draft-mcguinness-mission-shaping]).¶

17.8. Resource Policy Remains Authoritative

Mission authority is a maximum authority envelope. It does not force a Resource Server to perform an action, bypass local authorization, or override object ACLs, tenant configuration, legal holds, service invariants, or risk policy. A runtime deployment that treats a Mission-bound permit as sufficient without Resource policy evaluation can perform actions that the resource owner or service would otherwise forbid.¶

17.9. TOCTOU and Replay

Parameter binding (Section 8) ties a permit to specific normalized parameters and a short window or single use, so a permit cannot be replayed for a different request or survive a parameter change between check and use. The executing PEP, not an upstream component, MUST perform the reverification.¶

Parameter binding freezes the request, not the target. Between decision and execution the resource itself can change meaning: a revised document, a reclassified record, a query that returns a different set. That residual is outside parameter_digest's reach, and the mitigations are operational: keep permit validity windows tight (Section 8), re-evaluate rather than re-present a permit on retry, and, where the resource exposes a version or revision identifier, bind it as a parameter so the permit commits the target state it was decided against. Evaluation-Context Binding (Section 9.1) declares and checks selected resolved facts for adopting classes. A reread does not close a remote check-to-act window; only a coupled resource-side precondition earns its enforced property. Uncovered facts and deployments not claiming the extension retain this residual and the operational mitigations above.¶

An idempotency key identifies one request, not the business event the request carries out (Section 9.3). Two requests that carry out the same event under different action names, parameters, or actors are separate operations, and each can execute. Where an event must take effect once, the Operation Profile names the parameters that identify it, and the resource deduplicates on them. Under a metered bound each execution is charged, so a second representation duplicates an effect within the bound but adds no capacity ([I-D.draft-mcguinness-mission-metering]).¶

17.10. Confused Deputy Across Resources

The permit binding of Section 2.9 ties a decision to the Mission, the credential audience or protected resource, the subject, the client identity, the actor context, the action, and the resource it evaluated. It follows that a PDP decision for one protected resource, audience, tenant, or operation is not reusable at another: the executing PEP, which reverifies those bindings before acting (Section 8), refuses a permit whose bindings do not match the boundary at which it is presented. A deployment MUST NOT relax those bindings in a way that would let a permit cross a resource, audience, tenant, or operation boundary it was not issued for.¶

17.11. Decision Channel and Credential Disclosure

A separate PDP becomes part of the Resource Server's trusted authorization path for the operations in its enforcement scope, which is why mutual authentication, integrity protection, and authorization for the declared scope are baseline requirements on that channel (Section 2.4), not deployment advice. Passing full credentials to a PDP also extends credential exposure beyond the Resource Server boundary; a deployment that does so needs the same credential handling, retention, and disclosure controls it applies at the Resource Server.¶

General OAuth security guidance [RFC9700] applies to the underlying OAuth credentials, where the binding is OAuth ([I-D.draft-mcguinness-mission-runtime-oauth]).¶

20.1. Normative References

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

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

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

20.2. Informative References

[AUTHZEN]

OpenID Foundation, "OpenID AuthZEN Authorization API 1.0", 2026, <https://openid.net/specs/authorization-api-1_0-final.html>.

[I-D.draft-ietf-oauth-attestation-based-client-auth]

Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-11, 3 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-11>.

[I-D.draft-ietf-oauth-spiffe-client-auth]

Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-02, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

[I-D.draft-jiang-oauth-intent-admission]

Jiang, Y., Lun, L., Song, Y., and F. Liu, "Intent Admission Assertions for Agentic Systems", Work in Progress, Internet-Draft, draft-jiang-oauth-intent-admission-00, 23 June 2026, <https://datatracker.ietf.org/doc/html/draft-jiang-oauth-intent-admission-00>.

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

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

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

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

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

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

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

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

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

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

[I-D.draft-mcguinness-mission-capability-binding]

McGuinness, K., "Mission Capability Binding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-capability-binding.html>.

[I-D.draft-mcguinness-mission-control-plane]

McGuinness, K., "Mission Control-Plane Consistency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-control-plane.html>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[I-D.draft-mcguinness-oauth-actor-proofs]

McGuinness, K., "OAuth Actor-Signed Hop Proofs", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-proofs-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-proofs-00>.

[I-D.draft-mcguinness-oauth-actor-receipts]

McGuinness, K., "OAuth Actor Receipts for Delegation Provenance", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-receipts-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-receipts-00>.

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

McGuinness, K., "Client Instance Identification for Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-00>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[I-D.draft-niyikiza-oauth-attenuating-agent-tokens]

Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-01>.

[I-D.draft-rosomakho-oauth-txn-challenge]

Rosomakho, Y., Campbell, B., McGuinness, K., and P. Kasselman, "OAuth Transaction Authorization Challenge", Work in Progress, Internet-Draft, draft-rosomakho-oauth-txn-challenge-00, 25 June 2026, <https://datatracker.ietf.org/doc/html/draft-rosomakho-oauth-txn-challenge-00>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.