Mission-Bound Runtime Enforcement

1.1. Relationship to the issuance profile

This document depends normatively on the issuance profile and is not implementable alone: it consumes the Mission-bound access tokens that profile defines, or access tokens joined to an externally established Mission under Section 7.2. It does not place any new requirement back on the issuance profile; it reads only fields that profile already defines:¶

• the mission claim (id, issuer, authority_hash);¶

• the token's authorization_details, including entries of type mission_resource_access (resource, actions, constraints, and any delegation member) and any other entry type the deployment supports under the issuance profile's rules;¶

• the act chain, when delegation is in effect;¶

• the standard iss, aud, sub, client_id, and exp claims, when present in the token format; and¶

• any cnf sender-constraint binding.¶

Where this document needs a value the token does not carry (the current Mission lifecycle state, or a materialized policy-view version), it obtains it at runtime as described below, never by requiring the issuance profile to add a field.¶

The Resource Server enforcement rules in the issuance profile remain the baseline for every Mission-bound access token. This document adds an optional runtime conformance profile for deployments that claim execution-time Mission enforcement; it does not weaken the issuance profile's stateless token-validation, subset, delegation, or constraint-enforcement requirements.¶

4.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 token as described in Section 6. On permit the PEP reverifies the parameter binding, then executes; on deny it refuses. The runtime decision evaluates the action against the Mission's authority, the entry constraints, the actor chain, the Mission's current state, and Resource policy, as defined in Section 7.¶

4.2. Enforcement scope and conformance

This profile is implemented by a runtime deployment, not by an OAuth Authorization Server alone. Three things conform, at different granularities: the runtime deployment (this section), the Resource Server runtime profile for OAuth-protected resources (Section 5), and the PEP/PDP decision path for each consequential action (Section 7). Conformance is not global to a product, Authorization Server, Resource Server, or PDP: a deployment conforms to this profile only for the resources, action classes, execution paths, and authorization-detail 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. It 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]);¶

• the credential custody mode for each mediated class (mediated custody in the PEP, or agent-held, Section 4.6);¶

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

• the authorization_details types, action identifiers, and constraint vocabularies it supports;¶

• any Resource Server runtime profile and operation profiles it uses (Section 5);¶

• the Mission state source and maximum staleness bound used for each action class (Section 7.3);¶

• the runtime enforcement evidence mechanism and retention window (Section 12);¶

• the reconciliation window for matching execution-outcome evidence to decisions, the component responsible for orphaned-evidence and sequence-gap detection, and that component's alerting obligation (Section 12).¶

A deployment MUST NOT claim runtime enforcement for a resource, action class, authorization_details type, or execution path outside that declared scope. A Mission Issuer conforms to the issuance profile; it does not become a runtime-conforming deployment merely by issuing Mission-bound tokens.¶

The enforcement scope is a deployment conformance statement, not an OAuth Authorization Server 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.¶

4.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.¶

Classification floor. Actions in the irreversible, external commitment, and privileged administration classes MUST be treated as consequential and gated. These three are the high-consequence classes, to which this profile's strictest requirements attach (action-bound approval (Section 4.4), mediated custody (Section 4.6), active-state freshness (Section 7.3), and execution-outcome evidence (Section 12), each as specified in its own section). A Mission's purpose, or deployment policy, MAY raise an action to a stricter class; it MUST NOT lower an action below any minimum classification the Resource policy (Section 7) sets for it, including a floor the resource owner publishes in its protected resource metadata (Section 4.3.1), and in any case MUST NOT classify an irreversible, external-commitment, or privileged-administration action as non-consequential. A deployment that leaves such an action ungated does not enforce this profile for that action's class (Section 4.5).¶

{
  "resource": "https://erp.example.com",
  "mission_action_class_floors": {
    "journal-entries.read": "consequential_read",
    "journal-entries.write": "irreversible_action"
  }
}

4.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 an approval event under the issuance profile 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.¶

A PEP MUST refuse an action for which deployment policy or Resource policy requires an action-bound approval and a valid fresh approval bound to the action's parameters is not present. A deployment SHOULD require an action-bound approval for the high-consequence classes, where a token-lifetime-wide standing authority is least appropriate. 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.¶

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 binding composes with the AuthZEN Access Request and Approval Profile for exactly this (Section 13). 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 Mission expansion, not a property of the approval itself.¶

4.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 token-issuance decision does not replace execution-time authorization. A token-only Resource Server 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.¶

4.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.¶

Mission-bound tokens are sender-constrained ([I-D.draft-mcguinness-oauth-mission]): whoever holds the sender-constraint private key the token's cnf binds can present the token. 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 4.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 token is unchanged, the agent remains the principal of record (client_id still attributes the action to the agent), and no act-chain entry is added.¶

 Agent                Mediating PEP              Resource
   |                  (holds cnf key)               |
   |-- request ------>|                             |
   |                  | run the decision;           |
   |                  | present token with key ---->|
   |                  |<---------- 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.¶

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 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]).¶

Where the deployment issues tokens under the client-instance-assertion profile ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the sender-constraint key is instance-specific: that profile forbids a key shared across a client's instances. 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 the instance assertion and holding the instance key. In both shapes that profile's no-shared-key rule and this section's custody rules are satisfied together.¶

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 15); 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 cnf 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 tokens and re-derives. Mediating-PEP key rotation follows the deployment's published key set.¶

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.¶

4.7. Least exposure

Mission containment applies to 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 4.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 4.3), never replaces per-action authorization.¶

4.8. Agent-compromise-resistant enforcement

"Protects against agent compromise" is a verifiable claim, not a label. A deployment claims agent-compromise-resistant enforcement only when, for the high-consequence classes, all of the following hold. Each condition below is MUST under this claim regardless of its base-profile level: active-state freshness for the high-consequence classes is already MUST in the base profile (Section 7.3); the harness condition makes MUST the base profile's requirement that mediated classes have no unmediated path (Section 4.5); mediated custody and action-bound approval are SHOULD in the base profile (Section 4.6, Section 4.4) and MUST here.¶

• the sender-constraint private key is held by the mediating PEP, not by the agent component (Section 4.6);¶

• governed work runs under a harness conforming to the harness profile ([I-D.draft-mcguinness-mission-harness]) whose published execution-environment scope statement covers the mediated classes, so there is no unmediated path to those actions;¶

• each such action requires an action-bound approval (Section 4.4); and¶

• the Mission state source for those classes is an active freshness mechanism, not token-lifetime expiry (Section 7.3).¶

A deployment that leaves any of these unmet MUST NOT claim agent-compromise-resistant enforcement; it may still claim base runtime conformance. The claim names exactly the set of classes it covers.¶

The guarantee is the conjunction of these conditions, not any one of them. Mediated custody alone prevents only off-path presentation of the credential: the agent still initiates every action and supplies every parameter, and the mediating PEP executes any in-scope action the agent requests. What bounds a compromised agent is custody and complete PEP placement and correct classification acting together, so the claim is no stronger than the weakest of the three, and "mediated custody" on its own is not the property.¶

Each unmet condition loses a specific property:¶

7.1. Trifecta containment

An agent that holds private-data authority, is exposed to untrusted content, and can communicate externally combines the three ingredients of injection-driven exfiltration (Section 15.3). The profiles gate each ingredient separately; this claim names the composite. A deployment claims trifecta containment for a Mission's governed work only when all of the following hold, each MUST under this claim regardless of its base-profile level:¶

• Private-data exposure. Least exposure (Section 4.7) is applied: the context surfaced to the agent is scoped to the active Mission, and credential material stays out of the agent for every mediated class (Section 4.6).¶

• Untrusted content. The harness taint policy ([I-D.draft-mcguinness-mission-harness]) is in force and its egress rule is enforced, not advisory: a consequential external-communication or external-commitment action whose bound parameters derive from tainted content (or, under session-level taint, any such action in a tainted session) obtains a fresh action-bound approval (Section 4.4) or is refused. Where the decision-API binding carries taint context ([I-D.draft-mcguinness-mission-authzen]), the PDP enforces the rule; otherwise the harness does, and the scope statement says which.¶

• External communication. The external-communication and external-commitment classes are mediated: no unmediated path, the scope statement's egress-channel enumeration covers them ([I-D.draft-mcguinness-mission-harness]), and the sender-constraint keys are held by the mediating PEP (Section 4.6).¶

The claim is published with the enforcement-scope conformance statement (Section 4.2). It is containment, not immunity: the limits of Section 15.3 stand, in particular within-scope laundering, bounded quantitatively where an egress-volume bound is metered ([I-D.draft-mcguinness-mission-metering]), and PEP-placement completeness.¶

Both this claim and agent-compromise-resistant enforcement (Section 4.8) rest on the execution-environment scope statement, a self-declared artifact. A deployment MAY bind that statement to execution-environment attestation, presenting Entity Attestation Token evidence under the AI-agent-instance profile ([I-D.draft-mcguinness-oauth-ai-agent-instance]) covering the isolation properties the statement declares; a verifier SHOULD treat an unattested claim as an organizational assertion and an attested one as a technical one.¶

7.2. Mission binding establishment

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

• Credential-carried. The acting token's mission claim identifies the Mission, under the issuance profile's binding ([I-D.draft-mcguinness-oauth-mission]). The PEP takes the Mission reference from the validated token (Section 6).¶

• Externally established. The token carries no mission claim, 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]).¶

A deployment MUST document the mode each enforcement scope uses (Section 4.2). In either mode, the established Mission is the Mission every input of this section (authority, Resource policy, parameters, actor, time, state) is evaluated against, and the Mission reference the permit and the evidence record bind.¶

7.3. Mission state and freshness

A Mission-aware decision needs the Mission's current state, which a token alone does not convey. A runtime deployment MUST define the Mission state source it trusts for each enforcement scope. Examples include issuer AS token introspection, a local Mission database, an authenticated status or event feed from the Mission issuer, a materialized policy view, or a short-lived cross-domain credential ([I-D.draft-mcguinness-oauth-mission-cross-domain]) whose lifetime is the deployment's accepted state lease.¶

• 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 a freshness time, or define a lease interval over which a previously established active state remains acceptable for the relevant action class. A permit issued from that state view MUST expire no later than the applicable freshness time or lease interval.¶

• When the credential issuer also holds the Mission, the PDP can learn state through token introspection ([RFC7662]) at the issuer per [I-D.draft-mcguinness-oauth-mission]. A non-issuer Resource AS introspecting a local token ([I-D.draft-mcguinness-oauth-mission-cross-domain]) cannot report current Mission state; it can establish local token validity, but not issuer-side Mission freshness.¶

• This document defines no cross-issuer by-Mission status query. Deployments that need tighter freshness than the token or cross-domain grant ([I-D.draft-mcguinness-oauth-mission-cross-domain]) lifetime provides use the Mission Status profile ([I-D.draft-mcguinness-oauth-mission-status]) or Mission Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]), or an out-of-band trusted status feed.¶

• Each enforcement scope MUST publish its maximum staleness bound per action class and state source, together with the revocation latency that bound implies: a Mission's revocation takes effect, in the worst case, after the staleness bound plus the derived token's lifetime. This document imposes no universal value because the acceptable latency is deployment- and consequence-specific, but the bound is the number that determines the profile's headline revocation property, so publishing it without its latency consequence is non-conformant. The per-class budgets recommended below are the non-normative guidance 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: token introspection at the issuer ([RFC7662]), the Mission Status profile ([I-D.draft-mcguinness-oauth-mission-status]), or Mission Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]). Token-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 tokens age out, which is the ambient-authority gap this profile exists to close.¶

The following non-normative guidance illustrates freshness bounds that are likely to match the risk of common action classes:¶

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

7.4. Materialized policy view

A PDP evaluates a Mission against an action through a materialized policy view: the reproducible, evaluable form of the Mission's approved authority, produced by the issuing Authorization Server or a trusted compiler and loaded by the PDP. 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 13).¶

The materialized policy view MUST satisfy three properties:¶

• Reproducible: the same inputs (the Mission's approved Authority Set as committed by authority_hash, and the derivation policy_version recorded at the approval event) produce byte-identical materialized output 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.¶

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 payload>
}))

The committed materialized view payload MUST carry the Mission's mission_id and authority_hash as members. 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 view yields a new policy_view_id, so equality on policy_view_id is the cache identity and freshness test. This document defines no second canonicalization and no policy-language wire form for the view.¶

12.1. Required decision evidence

A record MUST contain:¶

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

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

• the parameter_digest for parameter-bound classes, or a privacy-preserving digest of the evaluation request otherwise.¶

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 the authority_hash (and intent_hash when known: it is carried in neither the mission claim nor introspection, so it is available only to a PDP with direct Mission-record access, and most deployments record authority_hash alone) it operated under;¶

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

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

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

• the authorization_details 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; and¶

• OPTIONAL, a compensates_decision_id member linking a compensating action's decision to the original decision identifier it reverses, so a compensation can be reconciled against the action it undoes.¶

For a token-validation failure, the record MUST NOT describe unverified token claims as authenticated facts. It MAY include a digest of the presented token 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 originating AS'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].¶

12.2. 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 decision identifier, recording at least success or failure and the parameter_digest actually executed. 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 deferred (Section 14).¶

Reconciliation is bounded in time. The enforcement scope MUST publish a reconciliation window within which an execution-outcome record is expected for each decision, and MUST name the component responsible for detecting orphaned evidence (a decision with no matching execution-outcome record within that window) and sequence gaps in a Mission's records (Section 12.4), and that component's alerting obligation when it detects either.¶

12.3. Mission Receipt

A Mission Receipt is the portable, tamper-evident projection of a runtime enforcement evidence record and, for a high-consequence action, its execution-outcome record: portable evidence of a material action taken under a Mission, 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: mission.id and mission.issuer, or a verifiable Mission projection such as the cross-domain grant's mission claim ([I-D.draft-mcguinness-oauth-mission-cross-domain]). It SHOULD bind 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 act chain), the custody boundary (whether a mediating PEP held the credential, Section 4.6), the downstream target (the resource and audience), the outcome, the timestamps, and, where receipt chaining substitutes for a transparency feed ([I-D.draft-mcguinness-mission-audit]), the digest of the previous Mission Receipt. The portable schema and canonical byte representation are deferred (Section 14); the members above are the minimum a deployment-defined Mission Receipt binds.¶

12.4. 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 AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]) is the suite's one signing convention for evidence objects and SHOULD be used, with a typ 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.¶

• Records for one Mission MUST carry a deployment-defined sequence indicator so decision order can be reconstructed without relying on wall-clock time alone.¶

• The enforcement scope MUST publish a retention window 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.¶

15.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: authority is checked at the point of use, parameters are bound to the permit, and each decision or refusal path is recorded. This closes the approval-to-execution gap the issuance profile leaves open.¶

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 14).¶

15.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 4.5). A deployment's claim is only as strong as the set of execution paths it actually mediates; it MUST name that set.¶

15.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 4.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 4.7) 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 4.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.¶

15.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 4.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 AuthZEN binding (Section 13), 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 14). 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 4.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.¶

15.5. Classification integrity

Because "consequential" is partly deployment-defined, the classification floor of Section 4.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.¶

15.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 7.3). A deployment MUST NOT advertise consumption enforcement it does not perform (Section 9); where cumulative bounds are metered, the exactness and consistency claims of the metering companion apply ([I-D.draft-mcguinness-mission-metering]).¶

15.7. 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.¶

15.8. 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.¶

15.9. Confused deputy across resources

The permit binding of Section 8 ties a decision to the Mission, the token audience or protected resource, sub, client_id, actor context, action, and 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.¶

15.10. Decision channel and token disclosure

A separate PDP becomes part of the Resource Server's trusted authorization path for the operations in its enforcement scope. The PEP/PDP channel therefore needs mutual authentication, integrity protection, and authorization for the declared scope (Section 6). Passing full access tokens 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.¶

15.11. Evidence privacy and correlation

Runtime enforcement evidence is intentionally durable and therefore sensitive. It can reveal a subject's resources, action timing, delegated actors, and Mission correlation identifier even when raw action parameters are not stored. Deployments SHOULD minimize recorded authority entries, store entry and parameter digests where full values are not needed for audit, restrict access to evidence by role, and document the retention window declared under Section 12. Evidence shared across resource boundaries can also correlate activity by mission.id and authority_hash; deployments that require unlinkability need an additional privacy design outside this profile.¶

General OAuth security guidance [RFC9700] applies to the underlying credentials.¶

16.1. OAuth Protected Resource Metadata Registration

This document registers the following in the "OAuth Protected Resource Metadata" registry ([RFC9728]):¶

• Metadata Name: mission_action_class_floors¶

• Metadata Description: JSON object mapping a protected resource's action identifiers to minimum runtime action classes.¶

• Change Controller: IETF¶

• Reference: this document, Section 4.3.1¶

The Mission-bound token claims this profile consumes are registered by [I-D.draft-mcguinness-oauth-mission]; any decision-API wire members are defined by the binding (Section 13, [I-D.draft-mcguinness-mission-authzen]).¶

17.1. Normative References

[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>.

[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>.

[RFC6749]

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

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[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>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[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>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

17.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-mcguinness-mission-audit]

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

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

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

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

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

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

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

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

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

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

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

[I-D.draft-mcguinness-mission-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-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-ai-agent-instance]

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

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

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

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

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

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

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

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

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

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

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

[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>.

[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>.