Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 3 July 2026 Expires: 4 January 2027 Mission-Bound Runtime Enforcement draft-mcguinness-mission-runtime-latest Abstract The Mission-Bound Authorization for OAuth 2.0 profile binds issued authority to a durable, approved Mission, but it governs issuance and derivation only: it does not evaluate individual runtime actions, so an active Mission can become ambient authority for the actions an agent takes within a token's lifetime. This document specifies the companion runtime layer for deployments that claim runtime Mission enforcement. Within a declared enforcement scope, each consequential action is evaluated, before it executes, against the Mission the acting credential is bound to. The evaluation checks the action and its parameters against the Mission's approved authority and constraints, the actor context from the delegation chain, and the Mission against its current state. The document defines where enforcement sits, how a permit is bound to concrete parameters to close the time-of-check to time-of-use gap, how carried consumption bounds (budget, call counts, duration) are metered, and the runtime evidence each consequential action produces. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-mission/draft- mcguinness-mission-runtime.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-runtime/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Relationship to the issuance profile 2. Conventions and Terminology 3. Mission Substrate 4. Runtime model 4.1. Enforcement flow 4.2. Enforcement scope and conformance 4.3. Action classification 4.4. Action-bound approval 4.5. PEP placement 4.6. Credential custody and mediated execution 4.7. Agent-compromise-resistant enforcement 5. Resource Server runtime profile 6. Token presentation and validation 7. The decision 7.1. Mission state and freshness 7.2. Materialized policy view 8. Parameter binding and time-of-check to time-of-use 9. Consumption metering 10. Failure modes 11. Runtime enforcement evidence 11.1. Required decision evidence 11.2. Execution-outcome evidence 11.3. Record integrity and retention 12. Decision API binding 13. Out of scope 14. Security Considerations 14.1. What this layer adds, and its limits 14.2. Placement and bypass 14.3. Prompt injection and exfiltration 14.4. Relationship to inspection-based controls 14.5. Classification integrity 14.6. Freshness and consumption honesty 14.7. Resource policy remains authoritative 14.8. TOCTOU and replay 14.9. Confused deputy across resources 14.10. Decision channel and token disclosure 14.11. Evidence privacy and correlation 15. IANA Considerations 16. References 16.1. Normative References 16.2. Informative References Appendix A. Parameter Digest Worked Example Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") makes a Mission a first-class OAuth artifact: a structured, human-approved, integrity-bound task whose authority bounds and outlives every token an agent derives. But it is deliberately an issuance-and-derivation layer. As its security considerations state, it does not evaluate individual runtime actions, so an active Mission still bounds a set of authority an agent may exercise freely within a token's lifetime, and preventing that authority from becoming ambient for individual consequential actions requires a separate runtime enforcement layer. This document is that layer. It delivers exactly the four things the issuance profile names as out of scope, plus enforcement of the constraints that profile 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, metering of the consumption bounds (budget, call counts, duration) the issuance profile carries as constraints but leaves to this layer to enforce (Section 9). The model is a Policy Enforcement Point (PEP) at each consequential execution boundary that, before the action runs, obtains a decision from a Policy Decision Point (PDP) evaluating the action against the Mission. Mission-bound tokens bound what authority may exist; this profile defines where and how that authority is re-checked before consequential effects occur. 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 13. 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 decision API binding (Section 12), specified separately; the AuthZEN binding is [I-D.draft-mcguinness-mission-authzen]. This document is the architecture and invariant layer; the binding is the interoperability layer. 1.1. Relationship to the issuance profile This document depends normatively on the issuance profile and is not implementable alone: it consumes Mission-bound access tokens that profile defines. It does not place any new requirement back on the issuance profile; it reads only fields that profile already defines: * the mission claim (id, origin, 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. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification uses the terms "access token", "Authorization Server", "client", "protected resource", "resource owner", and "Resource Server" from OAuth 2.0 [RFC6749] through the terminology incorporated by [I-D.draft-mcguinness-oauth-mission]. It also uses the Mission, Mission Intent, Mission Issuer, Authority Set, Approver, delegation, and mission claim terminology from [I-D.draft-mcguinness-oauth-mission]. Policy Enforcement Point (PEP): The component that can prevent a consequential action and that obtains and enforces a decision before the action runs. Depending on the action this is a Resource Server, an MCP server, an egress proxy, a workflow engine, or the orchestrator itself. Policy Decision Point (PDP): The component that evaluates a consequential action against the Mission and returns permit or deny. Its placement is a deployment choice (Section 7). Resource policy: Local policy of the Resource Server or protected resource, including object-level authorization, tenant configuration, legal holds, service invariants, and risk decisions. Mission authority is an upper bound and does not override Resource policy. Consequential action: An action that has external visibility or effect and so MUST be evaluated before it runs (Section 4.3). Decision: A PDP's permit-or-deny result for one action, bound to the inputs it evaluated (Section 7). Policy-view version: A deployment-opaque identifier the PDP emits for the materialized policy and Mission view it evaluated against, so a permit and its evidence record tie to a reproducible decision basis. It need not reveal policy content; it is a correlator that lets an operator determine which materialized policy, Mission state view, and constraint interpretation a decision used. It is local to the runtime layer and is distinct from the issuance profile's policy_version Mission-record field ([I-D.draft-mcguinness-oauth-mission]); this document does not interpret it beyond correlation, and defines no portable policy- version registry. The materialized policy view and its content- addressed policy_view_id are defined in Section 7.2. Runtime enforcement evidence: The record a consequential action produces for a PDP decision or a PEP refusal path (Section 11). Enforcement scope: The set of resources, action classes, execution paths, PEP placements, supported authorization details, state sources, and evidence mechanisms for which a deployment claims conformance to this profile. Operation profile: Deployment documentation that defines operation- specific runtime semantics needed for interoperable enforcement within that deployment, including parameter normalization rules and duration measurement. Resource Server runtime profile: A deployment's Resource Server- facing conformance statement for this profile. It defines which protected resources and operations the Resource Server enforces, where the PEP sits, how local Resource policy composes with Mission authority, and which operation profiles apply. Mission state source: A deployment-trusted source from which the PDP establishes the Mission lifecycle state or the freshness of that state (Section 7.1). Mission-bound token: An access token issued under a Mission per [I-D.draft-mcguinness-oauth-mission], carrying authorization_details and a mission claim. 3. Mission Substrate This profile is defined against the Mission model rather than against OAuth 2.0 mechanics. It consumes these substrate primitives: the Mission identifier and origin; the lifecycle state space with its only-active-permits rule and a freshness source; the Authority Set representation with its subset rule and Common Constraints; the Mission-bound credential carrying the mission claim; the integrity- anchor envelope; and the Mission's audit horizon. The issuance profile [I-D.draft-mcguinness-oauth-mission] is this version's normative substrate: it defines each primitive for OAuth 2.0, and every OAuth artifact named in this document enters through it. Another authorization substrate that provides the same primitives with the same semantics can host this profile unchanged; such a binding is defined by that substrate, not here. 4. Runtime model 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 document its enforcement scope, including: * the protected resources, action classes, and execution paths it mediates; * the PEP locations that can prevent those actions; * 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.1); * the runtime enforcement evidence mechanism and retention window (Section 11); * 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 11); and * any consumption-metering consistency bound it advertises (Section 9). 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. +===================+==================+==========+================+ | Class | Examples | PDP gate | Parameter | | | | | binding | +===================+==================+==========+================+ | Non-consequential | internal | not | n/a | | | reasoning, cache | required | | | | reads, planning | | | +-------------------+------------------+----------+----------------+ | Consequential | reading user | MUST | not required | | read | data, querying | | | | | logged APIs | | | +-------------------+------------------+----------+----------------+ | Consequential | updating | MUST | MUST | | write | records, posting | | | | | messages | | | +-------------------+------------------+----------+----------------+ | Irreversible | sending mail, | MUST | MUST, with | | action | payment, | | TOCTOU | | | deletion | | reverification | | | | | and evidence | +-------------------+------------------+----------+----------------+ | External | signing, | MUST | MUST, with | | commitment | accepting terms | | TOCTOU | | | for the user | | reverification | | | | | and evidence | +-------------------+------------------+----------+----------------+ | Privileged | granting access, | MUST | MUST, with | | administration | changing policy | | TOCTOU and | | | | | evidence | +-------------------+------------------+----------+----------------+ Table 1 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. *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.1), and execution-outcome evidence (Section 11), 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, 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). 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. 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 12). 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]). 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 14); 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. 4.7. 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.1); 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.1). 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. Each unmet condition loses a specific property: +========================================+========================+ | Condition unmet | Property lost | +========================================+========================+ | Custody in the mediating PEP | Key exfiltration | +----------------------------------------+------------------------+ | Harness-established no-unmediated-path | Off-path execution | +----------------------------------------+------------------------+ | Action-bound approval | Unattended high- | | | consequence action | +----------------------------------------+------------------------+ | Active-state freshness | Revocation lag bounded | | | only by token lifetime | +----------------------------------------+------------------------+ Table 2 5. Resource Server runtime profile An OAuth Resource Server that claims conformance to this runtime profile MUST publish or otherwise make available a Resource Server runtime profile for the protected resources and operations in scope. The Resource Server runtime profile is a deployment conformance statement, not an OAuth Authorization Server metadata extension and not a new access token format. The Resource Server runtime profile records the enforcement-scope items of Section 4.2 (protected resources, action classes, execution paths, PEP and PDP identities, supported authorization_details types and vocabularies, Mission state source and staleness bound, evidence mechanism and retention, and metering consistency bound) at the granularity of its protected operations, and additionally MUST define: * the endpoint families, methods, tools, or operation identifiers in scope, and the minimum action class for each, including any Resource policy floor above the default classification (Section 4.3); * the PEP location that can prevent each operation and any known execution path outside the claim, and, when the PEP and PDP are separate components, how they authenticate and integrity-protect decision requests and responses; * the operation profile for each protected operation or family: parameter normalization, default insertion, omitted optional fields, set-like array handling, idempotency-key handling, and duration measurement when duration can be metered; * the permit validity window for each action class, and replay controls for permit use, including where single-use decision identifiers and idempotency keys are recorded and how long consumed identifiers are retained; * how Resource policy is evaluated and composed with Mission authority, including local object authorization, tenant configuration, legal holds, service invariants, and risk policy; * the consumption-metering topology, including reserve, commit, settlement, retry, and reconciliation behavior; and * the runtime enforcement evidence fields and privacy treatment for decision and refusal records. A Resource Server MUST NOT claim this runtime profile for an operation unless the operation's consequential effects pass through a PEP that can refuse the operation after token validation and before execution. A Resource Server that only validates the access token and checks static token audience or scope claims does not implement this runtime profile. The Resource Server runtime profile MAY be documented in Resource Server configuration, resource-server metadata defined elsewhere, a contractual deployment profile, or another deployment-specific mechanism. This document does not define a discovery document, registry, or wire format for publishing it. 6. Token presentation and validation The runtime decision is downstream of ordinary access token validation. Before using a token's Mission, authority, subject, client, actor, or confirmation-key values as decision inputs, the PEP MUST establish that the access token is valid for the protected resource and request. For the Mission-bound JWT access tokens defined by the issuance profile, this means validating the JWT per [RFC9068], verifying the issuer and audience, checking token expiry, and verifying any sender-constraint binding (cnf) under the proof-of- possession rules of the issuance profile ([I-D.draft-mcguinness-oauth-mission]); this profile defines no proof-of-possession mechanism of its own. The underlying OAuth deployment MUST follow the applicable security best current practice in [RFC9700]. In particular, a Resource Server PEP MUST refuse a token whose audience is not intended for that Resource Server, and MUST verify the proof-of-possession check for a sender-constrained token before treating its cnf binding as authenticated. A PEP MUST NOT ask a PDP to authorize an action from unverified token claims. If token validation fails, or if the deployment requires Mission governance for the protected operation and the token lacks a mission claim, the PEP MUST refuse before runtime Mission evaluation. When the PEP is an OAuth Resource Server, it uses the normal OAuth error behavior for the protected resource (for example, Bearer token errors under [RFC6750]); this profile defines no new OAuth error code. 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 token-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. The PEP SHOULD send the PDP the minimum token-derived claims needed for the decision rather than the presented access token. If a deployment sends the access token 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. 7. The decision Before a consequential action runs, its PEP MUST obtain a permit from a PDP that evaluates the action against the Mission the acting token is bound to. This is the normative contract. The decision API wire format is a deployment choice; a binding maps this contract onto a concrete API (Section 12). The PEP MUST supply the inputs the PDP needs for the Mission-bound decision. Runtime enforcement MUST evaluate: * *Authority.* The action MUST be authorized by an applicable authorization_details entry the Mission-bound token carries, or that is otherwise available to the PEP or PDP for that token under the issuance profile (for example, through introspection when the authority is not represented inline). For an entry of type mission_resource_access, the action's resource and invoked action or tool identity MUST be within that entry's resource and actions, under the subset rule of [I-D.draft-mcguinness-oauth-mission]. The PEP asserts the capability identity (for example, the tool or function name) it will invoke; the PDP MUST refuse an identity outside the approved actions. For any other authorization_details type, the PDP MUST evaluate the action under that type's documented runtime semantics and MUST refuse if it does not understand or cannot enforce those semantics. For a capability sourced from a discovered catalog (an MCP tool catalog, an OpenAPI document, or an equivalent source), where the validating server recorded a source-content digest for the capability at derivation, the PDP MUST also refuse the action when the current source digest differs from the digest recorded at derivation (capability drift); the recorded digest is part of the derived authority and is covered by authority_hash ([I-D.draft-mcguinness-oauth-mission]). Cross-format canonicalization, signed capability manifests, and cross-catalog identity remain out of scope (Section 13). * *Resource policy.* The runtime decision MUST include any applicable Resource policy. A Mission-bound token and runtime permit are an upper bound on authority, not a command for the Resource Server to perform the action. Resource policy MAY be evaluated by the PDP, by the Resource Server or PEP as a composed local authorization step, or by both. The action MUST fail closed unless both Mission authority and Resource policy permit it. Resource policy includes object-level authorization, tenant configuration, legal holds, service invariants, and risk policy. * *Parameters.* Every constraints value on the applicable entry MUST be evaluated against the concrete action parameters. A constraint the PDP does not understand or cannot enforce or meter MUST cause refusal; it MUST NOT be ignored or reduced to disclosure-only treatment. * *Actor.* When delegation is in effect, the PDP MUST evaluate the authenticated act chain as part of the runtime actor context and refuse a chain that is missing or malformed. Runtime enforcement consumes the actor context that results from the issuance profile's delegation checks; it does not recompute the issuance- time subset validation, and the runtime decision MUST NOT expand authority beyond the issued authorization_details. The issuance profile's delegation constraints are not re-applied here unless the deployment documents them as runtime Resource policy, but a deployment MAY apply additional actor-sensitive Resource policy (Section 7). When an act chain is present, the PDP MUST NOT treat client_id alone as the immediate actor. * *Time.* The PDP MUST refuse if the decision context indicates the token is expired. The issuance profile caps a derived token's exp at mission_expiry, so the exp check enforces the Mission's expiry transitively. The standard mission claim and introspection do not surface mission_expiry; where a Mission state source does expose it (or reports the Mission expired), the PDP MUST refuse on it independent of the token's own exp. The PDP sets the permit's validity window from these inputs; that the action actually executes within that window is the executing PEP's reverification, not a decision input (Section 8). * *State.* The PDP MUST refuse unless the Mission is active (Section 7.1). On a deny, the PEP MUST refuse the action; a deny is terminal for the attempted action. A deny need not end the task, however: a decision- API binding MAY mark a denial requestable and route it through an access-request and approval workflow, and an approved request MAY be realized as a durable Mission expansion (Section 4.4, Section 12). This profile defines the runtime decision; it leaves that request- approval loop, and the expansion that persists an approved request, to the decision-API binding and the issuance profile's expansion mechanism. The PDP's placement is a deployment choice (co-located with the Mission's origin, embedded in the Resource Server, a tenant-scoped service, or a shared service); this document does not mandate one. The requirement is only that a PEP at each consequential boundary can reach an applicable PDP. 7.1. 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 origin AS token introspection, a local Mission database, an authenticated status or event feed from the Mission origin, a materialized policy view, or a short-lived cross-domain credential 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-origin Resource AS introspecting a local token cannot report current Mission state under the issuance profile; it can establish local token validity, but not origin Mission freshness. * This document defines no cross-issuer by-Mission status query. Deployments that need tighter freshness than the token or cross- domain grant 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. This document does not impose one universal value. * For the high-consequence classes, the state source MUST be an active freshness mechanism that can reflect a revocation within the staleness bound: origin token introspection ([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: +================+=======================================+ | Class | Suggested freshness posture | +================+=======================================+ | Consequential | Token lifetime or a short state | | read | lease; tighter for privacy-sensitive, | | | cross-tenant, or bulk reads | +----------------+---------------------------------------+ | Consequential | A short state lease, typically | | write | measured in minutes | +----------------+---------------------------------------+ | Irreversible | Immediate check or single-use permit | | action | | +----------------+---------------------------------------+ | External | Immediate check or single-use permit | | commitment | | +----------------+---------------------------------------+ | Privileged | Immediate check, suitable for | | administration | composition with local step-up | +----------------+---------------------------------------+ Table 3 7.2. 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 12). 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": , "value": })) 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. 8. Parameter binding and time-of-check to time-of-use 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. * 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. * The operation profile MUST define default insertion, omitted optional fields, and set-like array handling before canonicalization. * The permit MUST also bind the Mission reference, token issuer when available, token audience or protected resource, sub, client_id, actor context, sender-constraint confirmation key when present, action, resource, the authorizing authorization_details entry or an entry digest, the PDP's policy-view version, and a permit lifetime control bounded by the Mission state freshness requirement (Section 7.1). For a reversible consequential write, the control MUST be either a single-use decision identifier or a short validity window combined with an idempotency key that prevents repeat execution of the same normalized action. For an irreversible action, an external commitment, or privileged administration it MUST be a single-use decision identifier: a validity window alone does not bound how many times such a permit executes. * Where a single-use decision identifier is used, the enforcing component MUST record consumed identifiers for at least the permit lifetime and 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. * The executing PEP MUST verify those bindings 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. 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. Duration-metered actions already carry such a lease (Section 9). 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 or idempotency key also prevents repeat execution of the same normalized action. 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. Consumption metering Consumption bounds the Mission carries are enforced here, not at issuance. The issuance profile ([I-D.draft-mcguinness-oauth-mission]) defines three Mission-level consumption bounds in the Mission context that this layer meters: * max_budget ({ amount, currency }): the PDP performs an atomic reserve-or-charge against the remaining balance for each consequential action and MUST refuse when the remaining balance is insufficient. * max_calls ([ { call_class, count } ]): the PDP increments an atomic counter for the named call_class and MUST refuse a call past count. * max_duration (an ISO 8601 duration, e.g. PT8H; the duration rule in Appendix A of [RFC3339]): the cumulative wall-clock duration of consequential activity under the Mission, as the issuance profile defines it (distinct from mission_expiry). The PDP accumulates the duration of consequential activity it reserves, commits, or permits and MUST refuse once that total would exceed the bound. For an action whose duration is not known before execution, the PDP MUST either reserve a bounded maximum duration or issue a duration lease that expires unless renewed; the PEP MUST stop the action or obtain a new permit before the reservation or lease is exhausted. After execution, the PEP MUST report the measured duration so the PDP can commit actual use and release any unused reservation. The operation profile defines how a single action's duration is measured so that PDPs accumulate consistently. A per-entry constraints value that expresses a consumption bound is metered the same way. When an applicable entry or the Mission's context carries such a bound, the PDP MUST meter use against it and MUST refuse a consequential action that would exceed it. The exactness of a consumption bound depends on the decision topology, and this profile does not overpromise: * Under a *single serializing PDP* for the Mission, the check and decrement can be atomic, and the bound is exact. * Under *multiple or distributed PDPs* (for example, Resource Server-hosted PDPs), an exact global counter is a distributed- counting problem. Such a deployment MUST publish the consistency bound it operates under (for example, per-PDP sub-budgets, or a bounded reconciliation window), and the effective guarantee is that bound, not exact-to-the-call enforcement. A deployment MUST NOT advertise exact consumption enforcement it cannot meet under its chosen topology. As with all constraints, an unmetered or unrecognized consumption bound MUST cause refusal rather than silent pass-through. For a metered permit, the PDP and PEP MUST define retry and idempotency behavior. A retry of the same normalized action under the same idempotency key or single-use decision identifier MUST NOT consume the bound twice. Reuse of an idempotency key or decision identifier for a different normalized action MUST cause refusal. For irreversible actions and external commitments, a deployment MUST define whether metering is reserved before execution and committed after success, or committed before execution; it MUST NOT leave the decrement ambiguous. A failed attempt releases any reserved consumption per the deployment's documented reserve/commit posture. 10. 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. +============================+================================+ | Condition | Required behavior | +============================+================================+ | Token validation fails, | Refuse before runtime Mission | | including sender- | evaluation | | constraint verification | | +----------------------------+--------------------------------+ | Mission governance is | Refuse before runtime Mission | | required but the token | evaluation | | lacks a mission claim | | +----------------------------+--------------------------------+ | PEP-PDP channel | Fail closed | | authentication or | | | integrity protection fails | | +----------------------------+--------------------------------+ | Mission state cannot be | Fail closed for consequential | | established within the | actions | | staleness bound | | +----------------------------+--------------------------------+ | PDP unreachable | Fail closed for consequential | | | actions; do not proceed on | | | cached permits past the window | +----------------------------+--------------------------------+ | Mission not active | Refuse | +----------------------------+--------------------------------+ | mission_expiry passed, | Refuse | | when known from the | | | Mission state source | | +----------------------------+--------------------------------+ | Unsupported | Refuse | | authorization_details type | | | for the action | | +----------------------------+--------------------------------+ | Unknown or unmetered | Refuse | | constraint on the | | | applicable entry | | +----------------------------+--------------------------------+ | Consumption bound would be | Refuse | | exceeded | | +----------------------------+--------------------------------+ | parameter_digest mismatch | Refuse | | at the executing PEP | | +----------------------------+--------------------------------+ | Re-presentation of a | Refuse (fail closed) | | consumed single-use | | | decision identifier | | +----------------------------+--------------------------------+ | Required act chain missing | Refuse | | or malformed | | +----------------------------+--------------------------------+ | Invoked capability | Refuse | | identity outside the | | | approved actions | | +----------------------------+--------------------------------+ | Resource policy refuses | Refuse | | the action | | +----------------------------+--------------------------------+ | Request would broaden the | Refuse (expansion is out of | | Mission's authority | scope) | +----------------------------+--------------------------------+ Table 4 11. Runtime enforcement evidence Every PDP decision on a consequential action MUST produce a runtime enforcement evidence record. A PEP refusal for a consequential action, whether before a PDP decision (for example, token validation failure or PDP unreachability) or after a PDP permit (for example, a parameter_digest mismatch), MUST likewise produce a runtime enforcement evidence record with the available fields and the failure condition. This document fixes the minimum record content and local integrity requirements. The concrete record schema, any interoperable canonical byte representation, separate Decision Evidence and Execution Evidence object schemas, and portable cross- domain receipts are out of scope (Section 13). 11.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.origin) 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]. 11.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 13). 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 11.3), and that component's alerting obligation when it detects either. 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). * 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]. 12. Decision API binding The decision contract of Section 7 is abstract: it fixes the inputs, the permit, and the invariants, not a wire format. A *decision API binding* maps that contract onto a concrete PEP-PDP wire protocol. For deployments using the OpenID AuthZEN Authorization API [AUTHZEN], the normative binding is the Mission-Bound Runtime Enforcement: AuthZEN Profile [I-D.draft-mcguinness-mission-authzen], which specifies how the Mission and actor inputs, the decision and evidence objects, and the denial classification map onto the AuthZEN request and response. Other decision APIs may be bound by other specifications. This document defines no binding of its own. Keeping the binding in a separate specification preserves substrate-independence: the enforcement contract, action classification (Section 4.3), PEP placement (Section 4.5), parameter binding (Section 8), consumption metering (Section 9), and runtime enforcement evidence (Section 11) are the substance, and they do not depend on the decision wire. 13. Out of scope The following compose with this profile but are deferred to future work and are not required to enforce it: * a standardized enforcement-scope manifest format and discovery mechanism; * cross-format capability-source binding beyond same-source digest drift (signed capability manifests, cross-catalog identity); * portable, third-party-verifiable decision receipts (this profile fixes only the local runtime enforcement evidence record); * separate Decision Evidence and Execution Evidence object schemas and media types; * actor provenance beyond the act chain, attestation of the execution environment, and a purpose registry; * compilation of the Mission into an engine-native policy artifact (Cedar, OpenFGA, or equivalent) and standardization of PDP deployment modes; * offline or partitioned PDP operation (a PDP that decides while disconnected from its Mission state source); fail-closed (Section 10) remains the base rule when state cannot be established; * action-hierarchy and resource-containment subset extensions (this profile uses the flat subset rule of [I-D.draft-mcguinness-oauth-mission]); * risk-signal and semantic intent-alignment inputs to the decision, which are advisory and deployment-defined (Section 14.4); and * integrity of the result a tool returns as the application relays it to the agent's model, and binding an executed action to the model's own decision (Section 14.4). Structured per-argument attenuation of tool grants ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]) is a related issuance/delegation-layer primitive, not part of this runtime profile. 14. Security Considerations 14.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, consumption is metered, 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 13). 14.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. 14.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. 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 max_calls / max_budget 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. 14.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 12), 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 13). 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. 14.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. 14.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.1). Consumption bounds are exact only under a single serializing PDP; a deployment MUST NOT advertise exactness it cannot meet across distributed decision points (Section 9). 14.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. 14.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. 14.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. 14.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. 14.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 11. 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. 15. IANA Considerations This document has no IANA actions. 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 12, [I-D.draft-mcguinness-mission-authzen]). 16. References 16.1. Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [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, . 16.2. Informative References [AUTHZEN] OpenID Foundation, "OpenID AuthZEN Authorization API 1.0", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", Work in Progress, Internet-Draft, draft- mcguinness-mission-authzen, 2026, . [I-D.draft-mcguinness-mission-harness] McGuinness, K., "Mission-Aware Agent Harnesses", Work in Progress, Internet-Draft, draft-mcguinness-mission- harness, 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-consent-evidence, 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-signals, 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission-status, 2026, . [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, . [RFC9470] Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, . Appendix A. Parameter Digest Worked Example This non-normative example shows an operation profile and the parameter_digest it produces (Section 8), so two implementations can confirm they normalize and digest the same way. Consider a payments.send operation. Its operation profile fixes the parameter set and normalization: the members are payee, amount, currency, and account; amount is a decimal string with exactly two fractional digits; currency is an uppercase ISO 4217 code; no defaults are inserted and no optional members are omitted; there are no set-like arrays to order. For a 9,000 USD payment, the normalized parameter object is: { "payee": "Acme Supply Co", "amount": "9000.00", "currency": "USD", "account": "****4417" } The parameter_digest is sha-256: followed by the base64url, no- padding SHA-256 of the JCS [RFC8785] serialization of that object, under the issuance profile's canonicalization rules (no envelope; the normalized parameter object is digested directly). The JCS canonical bytes are a single line with sorted member names and no whitespace, shown here wrapped for layout only; remove the layout line break, adding no characters, to recover the canonical form: {"account":"****4417","amount":"9000.00","currency":"USD","payee":"Acme Supply Co"} parameter_digest = sha-256:e7GXd0GWwOK2ezlb0CfUeYhjYOF1DE68_Gg0ofbr7do The PDP binds its permit to this value, and the executing PEP recomputes it over the parameters it is about to use immediately before acting (Section 8); any change to a normalized parameter yields a different digest and the permit is refused. Acknowledgments This document is the runtime companion to Mission-Bound Authorization for OAuth 2.0 and builds on the OpenID AuthZEN Authorization API and the OAuth 2.0 Rich Authorization Requests and JWT access token specifications. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com