--- title: "Mission-Bound OAuth Runtime Enforcement Profile" date: "2026-06-01T09:00:00-07:00" lastmod: "2026-06-01T09:00:00-07:00" description: "A composition profile layered on the Mission-Bound OAuth MVP. The MVP binds tokens to a Mission; this profile evaluates every consequential agent action against the same Mission at request time, with per-decision evidence." summary: "The MVP binds OAuth tokens to a durable Mission record. This profile adds the runtime layer: AS-side intent-to-policy compilation, mandatory escalation via AuthZEN, tool-and-action binding, mandatory actor chains, per-decision evidence records, and a governed purpose registry. Modular by design: a Core enforcement contract plus Optional Modules that deployments adopt as their governance posture requires." slug: "mission-bound-oauth-runtime-enforcement-profile" tags: - "OAuth" - "Authorization" - "Agentic Identity" - "Mission-Bound OAuth" - "Intent-Based Authorization" - "Intent-Based Access Control" - "AuthZEN" - "Internet-Draft" series: - "mission-bound-oauth-mvp" --- [The Mission is the Missing Abstraction for Agents](/notes/the-mission-is-the-missing-oauth-abstraction/) made the conceptual case. The [Mission-Bound OAuth MVP](/notes/mission-bound-oauth-mvp/) added the Mission as a durable governance layer to the existing OAuth stack. This post adds the runtime enforcement layer on top of that governance layer, with per-action evaluation and per-decision evidence. [Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls/) applies the full stack to MCP. The Runtime Enforcement Profile builds on the MVP with two outcomes the MVP alone cannot deliver. ## Goals **Execution continuity.** A long-running agent task stays inside the user's approved intent across actions, sub-agents, hops, and time, without restart prompts, silent failures, or implicit broadening. Every consequential action consults the same compiled policy bound to the same Mission. Every in-bounds action succeeds. Every out-of-bounds action becomes a governed Mission Expansion through AuthZEN Access Request, not a terminal denial that interrupts the workflow. The agent's task can run for hours or days under one approved authority object, with policy evaluation gating each step. **Proof of authority.** Every consequential action produces a per-decision evidence record. The record binds `mission.id`, `mission.origin`, `proposal_hash`, the compiled policy version evaluated, the decision and the constraint clauses that drove it, and the `act` chain at decision time. A governance reviewer can reconstruct end-to-end whether the agent stayed within what the user approved without stitching logs across resource servers by hand. The Mission Authority remains the canonical source. Evidence records are append-only artifacts that defend the agent's behavior in front of an auditor. Portable cryptographic receipts are an optional module layered on top of those records. Mission-Bound OAuth becomes Intent-Based Access Control (IBAC) when the Mission is not only a token-bounding object, but the authoritative input to runtime policy decisions for every consequential agent action. The two goals above are what make that worth the effort. This profile is OPTIONAL for v1 deployments and REQUIRED for any deployment that claims request-time intent enforcement. It turns several MVP composition points into MUST-level policy-layer requirements, and adds requirements the MVP does not impose at all. # What the MVP Gives You Readers who just finished the [MVP](/notes/mission-bound-oauth-mvp/) can skim this section. It is a reference for readers landing on Part 3 directly. Before the Runtime Enforcement strengthening, the MVP already defines: - A `mission_intent` RAR envelope (`purpose`, `mission_expiry`, `context`) and a `resource_access` RAR type (`resource`, `actions`, `constraints`), composed in a single `authorization_details` array submitted at PAR. - A Mission record at the Authorization Server with a seven-state lifecycle, anchored by `proposal_hash` (canonical hash of the approved array) and `consent_rendering_hash` (hash of what the user saw). - An access-token `mission` claim with `id` and `origin` carrying the Mission handle and the originating AS identifier. - A per-entry, per-type subset rule for derivation: requested entries MUST be subsets of approved entries of the same `type`, and unknown constraints MUST be preserved verbatim or refused. - Cross-AS derivation via Token Exchange and ID-JAG, with `mission.id` preserved across hops. - A requestable-denial escalation path through AuthZEN Access Request for Mission Expansion workflows. - An `act` chain on sub-agent delegation paths. - Standardized inactive-Mission signaling at the token endpoint and introspection. The Runtime Enforcement Profile builds on these primitives. It does not redefine any of them. # Profile Structure The Runtime Enforcement Profile is itself modular. **Core** defines the essential runtime enforcement contract: a Mission-aware PDP that evaluates every consequential action against the same approved authority object, with evidence per decision. **Optional modules** are independent extensions that add specific governance capabilities on top. A deployment that ships Core reaches Conformance Level 4 ([MVP ladder](/notes/mission-bound-oauth-mvp/#conformance-ladder)). Optional modules are needed for Level 5. **Core sections (required for Runtime Enforcement Profile compliance):** - **Intent-to-Policy Compilation** — AS deterministically compiles approved `authorization_details` into an evaluable policy artifact at Mission activation. - **Resource-Side Enforcement Contract** — PDP evaluates every consequential request against approved bounds; RS-B minimum. - **Standard Subset Semantics** — per-RAR-type subset rule with strict unknown-constraint refusal. - **Runtime Denial and Escalation** — every in-policy denial is a requestable Mission Expansion via AuthZEN Access Request (MUST). - **Mission Introspection Profile** — extended introspection response with `act` chain, tenant, subject, audience-relevant `authorization_details`, compiled policy version. - **Local-Action Boundary** — non-OAuth actions MUST be governed by AuthZEN Access Evaluation; orchestrator MUST NOT execute consequential local actions inline. - **Decision evidence handles** — every PDP decision produces an evidence record bound to `mission.id`, `proposal_hash`, compiled policy version. (Format is Core; portable cryptographic receipts are an Optional Module.) **Optional modules (independently adoptable):** | Module | What it adds | Substrate | | --- | --- | --- | | **Tool Binding Profile** | Pins approved actions to manifest-identified tools; detects post-approval drift | RFC 9728 PRM, MCP server manifests, OpenAPI | | **Decision Receipt Profile** | Portable cryptographic per-decision receipts, third-party-verifiable across domains | W3C Verifiable Credentials Data Model 2.0 | | **Purpose Registry Profile** | Governed registry of `mission_intent.purpose` URIs with declared bounds, risk class, escalation rules | IANA, OIDF, or industry-body registry | | **Actor Provenance Profile** | Extends `act` chain attribution beyond sub-agent paths to every Mission-bound token, with tool, workflow step, human approver | [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/), [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) | | **Attestation Profile** | Binds Mission `cnf` to attested agent identity / execution environment | RATS PTV, WIMSE Workload Identity | | **Policy Projection Profile** | AS-to-RS carriage of compiled policy artifact for Cedar-capable RS-C audiences | Cedar, OpenFGA, AuthZEN policy | Each Optional Module corresponds to a section below. Sections labeled with one of these module names are Optional; everything else is Core. ## Reading the strengthening sections Where Runtime Enforcement strengthens or builds on the MVP, the section follows a consistent shape: 1. **MVP baseline.** What the MVP already says about this concern (required, optional, or absent). 2. **Runtime Enforcement strengthening.** What the profile adds or tightens (typically "optional" to "required", or "absent" to "required"). 3. **Reason.** Why the strengthening is necessary for the execution-continuity or proof-of-authority goal. 4. **Interop consequence.** What an MVP-only deployment must accept when interacting with a Runtime Enforcement deployment, and vice versa. This pattern recurs across the Core sections. Skim the four-step shape for any topic that overlaps between profiles. # Threat Impact Relative to the MVP Several threats in the MVP's Privacy and Security section are mitigated more strongly under IBAC than under the MVP alone. - **Silent constraint loss** is reduced from "preserve verbatim or refuse" to "refuse on unknown constraint": the PDP MUST understand every approved constraint or refuse the request. - **Downstream over-granting** is constrained at request time, not only at token issuance, because RS-B or higher and the runtime policy gate evaluate every consequential request against the approved bundle. - **Confused deputy through sub-agents** is bounded more tightly because the `act` chain is required on every Mission-bound token and the PDP evaluates the chain on every decision. - **Stale Mission state** and **audience replay** are unchanged: IBAC strengthens the policy-state layer, not the token-state or Mission-state layer. # Key Use Cases Five concrete cases that Runtime Enforcement newly enables on top of the [MVP](/notes/mission-bound-oauth-mvp/). Where the MVP already gives a partial answer, the profile turns composition points into normative requirements and adds the surfaces that close the gap. ### Real-time governance of non-OAuth tool calls The agent invokes a local tool (filesystem write, MCP server, payment confirmation, internal workflow step) that is not behind an OAuth-protected API. - **Today:** no protocol-layer governance for non-OAuth actions. The harness becomes the de facto PDP. Tool-call boundaries are deployment-specific code with no audit interoperability and no relationship to the user's approved Mission. - **MVP gives:** not standardized. A deployment can use the Mission record as local-policy input, but the MVP does not define PDP consultation for non-OAuth actions. - **Runtime Enforcement delivers:** the Runtime Policy Gate is MUST. The orchestrator MUST NOT execute consequential local actions inline; it MUST consult the PDP. Every PDP decision produces an evidence record bound to `mission.id`, `proposal_hash`, compiled policy version, decision, constraint clauses, and actor chain. - **Enabling features:** AuthZEN Authorization API (Access Evaluation, mandatory), AS-compiled policy artifact, per-decision evidence records, Mission Expansion via AuthZEN Access Request on denial. ### Tool-manifest drift detection A Resource Server deploys a new tool that an existing approved scope now covers (mutable scope semantics). The user approved against the older manifest. - **Today:** the AS validates scope and the RS validates scope; the new tool is reachable; the agent gains capability the user never saw. Catastrophic in regulated or high-risk environments. - **MVP gives:** not addressed. Tool-bounded narrowing is useful deployment practice but the MVP does not standardize manifest binding. - **Runtime Enforcement delivers:** tool-and-action binding pins approved actions to manifest-identified tools at approval time. The AS consults a tool manifest (RFC 9728 PRM extension, MCP server manifest, OpenAPI document) at approval and binds each approved action to a stable tool identifier. Derived requests MUST present the tool identifier; the PDP MUST validate it. Tool-manifest drift after approval MUST cause refusal or trigger Mission Expansion. - **Enabling features:** tool-and-action binding at approval, manifest digest on the Mission record, MUST-level refusal on drift. ### PDP-enforced budget at every consequential request The agent's per-call cost is small but cumulative tool calls exceed the approved budget. The AS counts derivations only, so tool-call overspend slips through. - **Today:** not addressed at the wire layer. - **MVP gives:** a standard `mission_intent.context` container and preservation/refusal rules for deployment-defined constraints. A deployment can define budget keys and count derivations, but the MVP does not standardize budget semantics. - **Runtime Enforcement delivers:** the PDP evaluates every consequential request against the approved budget, including non-OAuth tool calls, when budget constraints are defined by the deployment or a later constraint catalog. Cumulative spend is tracked against the Mission record and reflected in decision evidence records. Crossing the cap refuses the action at the PDP, not only at the AS. - **Enabling features:** AuthZEN Access Evaluation against `mission_intent.context`, AS-compiled policy artifact (which encodes the budget bound), per-decision evidence records that record the budget delta. ### Per-decision evidence with compiled policy version A governance review needs to reconstruct what specific policy was evaluated for a denied request weeks ago. The policy could have evolved through Mission Expansions or compiled-artifact updates. - **Today:** not standardized. Reviewers depend on whatever the deployment chose to log. - **MVP gives:** lifecycle audit records keyed on `mission.id` with `proposal_hash` and `consent_rendering_hash`, but no per-decision evidence and no compiled-policy version. - **Runtime Enforcement delivers:** per-decision evidence records at every PDP evaluation, bound to `mission.id`, `mission.origin`, `proposal_hash`, the compiled policy version evaluated, the decision (permit or deny) and the constraint clauses that drove it, the `act` chain at decision time, and any resulting Mission Expansion request. Records are append-only and integrity-protected. - **Enabling features:** AS-compiled policy artifact with version/fingerprint, extended Mission introspection response, per-decision evidence records, full `act` chain attribution. ### Sub-agent attribution as foundation for graceful actor eviction A parent orchestrator delegates to multiple sub-agents. One sub-agent's `cnf` key is compromised mid-task. Killing the parent loses all in-flight work across the other healthy sub-agents. - **Today:** revocation is whole-Mission. The compromised sub-agent forces termination of the parent and every sibling. - **MVP gives:** `act` chain on sub-agent derivation paths. Sufficient for attribution after the fact but not for selective revocation. - **Runtime Enforcement delivers:** `act` chain MUST on every Mission-bound token, not only sub-agent paths. The PDP evaluates the chain on every decision. The chain identifies the orchestrator, each sub-agent, the tool or workflow step invoking the action, and the human approver where applicable. This is the foundation for a future `revoke_actor` profile (see Gaps) that evicts a single compromised actor while leaving the Mission active. - **Enabling features:** mandatory `act` chain on every Mission-bound token, full actor attribution (orchestrator, sub-agent, tool, human approver), PDP chain evaluation on every decision. # Worked Example The MVP's board-packet [Worked Example](/notes/mission-bound-oauth-mvp/#worked-example) shows how an approved Mission projects to tokens across many Resource ASes. Under IBAC, the same Mission gets runtime enforcement at every consequential action. ```mermaid sequenceDiagram participant O as Orchestrator participant PDP as Policy Decision Point participant AS as Mission Authority participant RS as Resource Server participant Audit as Evidence Log O->>PDP: AuthZEN Access Evaluation
mission.id, action, parameters PDP->>AS: Resolve Mission record
+ compiled policy artifact AS-->>PDP: Mission state, bounds,
compiled policy Note over PDP: Evaluate action against
approved bounds + local policy PDP-->>O: permit PDP->>Audit: Write decision evidence
mission.id, proposal_hash, policy_version,
decision, constraint clauses, act chain O->>RS: API call with Mission-bound token RS->>PDP: (RS-C/D) Authorize request PDP-->>RS: permit PDP->>Audit: Write decision evidence RS-->>O: Resource response ``` The MVP Worked Example walks the board-packet task end to end: an agent prepares a quarterly board packet, drafts the document, gathers finance data, and routes for review across multiple Resource ASes under one Mission. Under IBAC, the same scenario gains four things at the points the MVP example glossed: - **Mission activation** also compiles the approved `authorization_details` into a Cedar, OpenFGA, AuthZEN-policy, or equivalent artifact, stored on the Mission record with a policy version fingerprint. - **Every consequential action** (not only OAuth-protected derivations) calls the PDP before execution. Local tool calls, filesystem writes, payment confirmations, and MCP invocations all gate at the same PDP boundary. - **Out-of-bounds requests** (the finance-data step in the MVP example) produce a MUST-level requestable denial with a Mission Expansion handle, not the MVP's SHOULD-level. The deployment's approval workflow either creates a successor Mission or denies and the prior Mission stays active. - **Every PDP decision** produces a decision evidence record bound to `mission.id`, `mission.origin`, `proposal_hash`, compiled policy version, decision, constraint clauses, and the `act` chain at decision time. Audit is per-decision, not per-lifecycle-event. The wire shape between the orchestrator, PDP, AS, RS, and audit log is what the sequence diagram above shows. # Core The following sections define the enforcement contract that a deployment MUST implement to claim Runtime Enforcement Profile compliance. Each turns an MVP composition point into a normative requirement or adds a requirement the MVP does not impose. ## Intent-to-Policy Compilation The IBAC AS MUST compile the approved `authorization_details` array into an evaluable policy artifact at the moment the Mission transitions to `active`. The compiled artifact MAY be Cedar, OpenFGA tuples, AuthZEN policy, or any internal representation; the compilation MUST be deterministic and reproducible from the same approved array. The compiled artifact is stored on the Mission record and consulted by every PDP evaluation. Clients do not submit compiled policy at PAR; the AS owns the compilation step. A concrete AuthZEN Access Evaluation against a Mission-scoped action: ```http POST /access/v1/evaluation HTTP/1.1 Host: pdp.example.com Content-Type: application/json { "subject": { "type": "user", "id": "alice@example.com", "properties": { "mission_id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1", "mission_origin": "https://as.example.com", "act_chain": [ { "client_id": "agent.example.com" }, { "client_id": "subagent.example.com", "instance_id": "inst_42" } ] } }, "action": { "name": "documents.write", "properties": { "tool_id": "docs.example.com:documents.write@v1.2" } }, "resource": { "type": "document", "id": "doc_board_packet_q3", "properties": { "folder": "board-materials" } }, "context": { "request_time": "2026-06-01T15:00:00Z" } } ``` The `act_chain` shown here is a flat array adapted for the AuthZEN evaluation request shape (PDP properties are easier to evaluate as arrays). The canonical wire shape on issued tokens is the RFC 8693 nested `act` claim (outermost actor is the most recent; the parent's prior `act` is carried as the nested `act`). Translation between the two shapes is the orchestrator's responsibility. Response on permit: ```json { "decision": true, "context": { "policy_version": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1#v1", "decision_evidence_id": "evid_01J2K8...", "parameter_digest": "sha256-..." } } ``` Response on denial with Mission Expansion handle (using the AuthZEN Access Request and Approval Profile shape): ```json { "decision": false, "context": { "reasons": ["resource not in approved targets"], "policy_version": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1#v1", "access_request": { "endpoint": "https://as.example.com/access-requests", "template": "mission_expansion", "expires_at": "2026-05-31T20:25:00Z", "binding_token": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC0xIn0..." } } } ``` ## Resource-Side Enforcement Contract Runtime Enforcement deployments require RS-B or higher (per the MVP's Resource Server Tiers). Every consequential request MUST be evaluated against the Mission's approved bounds, covering: resource, action, constraints, actor (matches the approved `act` chain), tenant, time (within `mission_expiry` and any time-based constraints), risk signals (deployment-defined), and purpose (consistent with the Mission's `purpose` URI). RS-A is insufficient for request-time intent enforcement: a token check without authority evaluation does not enforce intent at request time. ### PDP Deployment Modes The PDP may live in different places depending on the deployment shape. Each mode has different latency, governance, and trust properties. IBAC supports any of them as long as the AuthZEN Access Evaluation wire shape is consistent. | Mode | Where the PDP runs | When to use | Trade-offs | | --- | --- | --- | --- | | **AS-hosted PDP** | Co-located with the originating Authorization Server | Single-tenant deployments; AS already owns the Mission record and compiled policy | Lowest latency for AS-side decisions; PDP fate-shares with AS availability | | **RS-hosted PDP** | Embedded in each Resource Server | High-throughput Resource Servers; minimum per-request latency at the RS | Each RS must consume Mission state (cached or live); policy update propagation needed | | **Tenant governance PDP** | A tenant-scoped PDP shared across multiple ASes and RSes within an organization | Multi-AS enterprise deployments; centralized governance and audit | Network hop per evaluation; tenant operates the PDP itself | | **Federated PDP** | A PDP operated by a third party or industry body, consulted across organizations | Cross-organizational deployments where multiple parties must agree on a decision | High latency and trust complexity; appropriate only for high-assurance Missions | The Mission Authority does not mandate a mode. The IBAC requirement is that *some* PDP, reachable by the orchestrator and the relevant Resource Servers, evaluates every consequential request. PDP discovery (where the PDP lives) is currently deployment-specific (see Roadmap). ## Standard Subset Semantics per RAR Type The MVP's per-entry, per-type subset rule applies. IBAC tightens it: - **Action hierarchy.** When actions form a containment hierarchy, the RAR type metadata MUST define the relation. Derived actions are evaluated under the hierarchy, not just under exact set inclusion. - **Resource containment.** When resource URIs form a containment hierarchy (folders, projects, organizations), the RAR type metadata MUST define the relation. Derived resources MAY narrow to a contained resource if the type permits. - **Constraint preservation.** Every approved constraint MUST be evaluated by the PDP. Constraints the PDP does not understand MUST cause refusal. This is stricter than the MVP baseline, which permits an AS to preserve an unknown constraint verbatim instead of refusing. - **Conflict handling.** When two approved entries appear to grant overlapping authority with conflicting constraints, the PDP MUST take the more restrictive intersection. ## Mission Introspection IBAC RS/PDPs need a richer introspection response than the MVP baseline. The IBAC Mission introspection response MUST include: - All MVP minimum fields (`id`, `origin`, `state`, and when active: `expiry`, `purpose`, `proposal_hash`). - The `authorization_details` entries relevant to the requesting audience. - `tenant` and `subject` claims. - The `act` chain when sub-agent delegation is in effect. - The compiled policy artifact version or fingerprint (`policy_version`), so the PDP can detect compilation drift between issuance and evaluation. ### Policy Freshness Rules PDPs that evaluate against a cached Mission record or cached compiled policy MUST respect the following freshness rules: - **Cache TTL.** A cached Mission record or compiled policy MUST NOT be used past 30 seconds of staleness unless the PDP holds a current SSF/CAEP subscription that delivers Mission state events for that Mission. With a current subscription, the cache MAY persist until invalidated by an event. - **policy_version coherence.** Every PDP decision MUST record the `policy_version` evaluated. When the PDP receives an introspection response whose `policy_version` differs from its cache, the PDP MUST refresh before issuing the next permit. - **Fail-closed on uncertainty.** When the PDP cannot verify that its cached Mission policy is current (introspection unreachable, no event subscription, or a missed heartbeat), it MUST fail closed for consequential writes, irreversible actions, external commitments, and privileged administration. It MAY fail open for non-consequential reads. - **Policy update propagation.** When the AS publishes a new `policy_version` (Mission Expansion, in-place amendment, or compiled-artifact rebuild), it SHOULD emit an SSF/CAEP event so subscribing PDPs can invalidate their caches before stale evaluations occur. PDPs without an event subscription MUST poll introspection at least once per cache-TTL window. ## Runtime Denial and Escalation Every PDP denial that would fall within client registration and deployment policy if expanded MUST be returned as a requestable denial through [AuthZEN Access Request](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) (AuthZEN WG draft). The orchestrator MAY initiate a Mission Expansion from the denial response. Terminal denials (out of client registration, against deployment policy) MUST be returned without an escalation handle. This turns "agent exceeded the Mission" into a governed approval workflow rather than a silent failure. Under IBAC the escalation loop is MUST, not SHOULD. ## Local-Action Boundary The MVP explicitly leaves non-OAuth local actions outside the wire-level MVP. IBAC brings them into scope. Every consequential local action that is not an OAuth-protected API call (tool invocations, file writes, payment confirmations, internal side effects) MUST be governed by an AuthZEN Access Evaluation against the Mission before execution. The orchestrator MUST NOT execute consequential local actions inline; it MUST consult the PDP. ### Action Classification The boundary between "consequential" and "not consequential" is deployment policy, but IBAC defines a default classification that deployments SHOULD adopt: | Class | Examples | PDP gate required? | Parameter binding required? | | --- | --- | --- | --- | | **Non-consequential** | Internal reasoning, cache reads, planning steps with no external visibility | NO (orchestrator may proceed inline) | N/A | | **Consequential read** | Reading user data, fetching documents, querying APIs that log access | YES (default SHOULD) | NO | | **Consequential write** | Updating records, creating resources, posting messages | YES (MUST) | YES | | **Irreversible action** | Sending email, executing payment, deleting data, deploying code | YES (MUST) | YES, with TOCTOU verification | | **External commitment** | Signing on behalf of user, accepting terms, making promises to third parties | YES (MUST) | YES, with TOCTOU verification and decision evidence | | **Privileged administration** | Granting access, modifying policy, changing tenant configuration | YES (MUST) | YES, with TOCTOU, decision evidence, and human-in-the-loop signal | The Mission Authority MAY further restrict a class for specific `purpose` URIs. For example, a `purpose=urn:example:mission:research` Mission MAY classify "writing to a project doc" as Consequential Write rather than Irreversible Action, while a `purpose=urn:example:mission:financial-settlement` Mission MAY classify the same write as External Commitment. ## Parameter Binding and TOCTOU Protection A `tool_id` permits the *operation*, not arbitrary parameter values. For irreversible actions, external commitments, and privileged administration (see Action Classification above), the PDP MUST bind its permit to the canonicalized action parameters or a parameter digest. The orchestrator submits the action parameters with the Access Evaluation request; the PDP includes a `parameter_digest` (base64url-no-pad SHA-256 of canonical JSON of the parameters) in the permit response. The orchestrator MUST present the same parameters at invocation time, and the executing component (Resource Server, tool gateway, or orchestrator itself) MUST verify the digest match before executing the action. This closes a Time-Of-Check-To-Time-Of-Use (TOCTOU) gap: between the PDP permit and the action execution, no field of the action call may change. A deployment MAY relax this to permit-shape-only for non-consequential reads where parameter mutability is acceptable; the boundary is set by the action classification. ## Decision Evidence Records Every PDP decision on a consequential action MUST produce a decision evidence record containing `mission.id`, `mission.origin`, `proposal_hash`, the action identifier, the action parameters or a `parameter_digest` of them when parameters contain sensitive data, the compiled `policy_version` evaluated, the decision (permit or deny) and the constraint clauses that drove it, the actor chain at the time of the decision, and the resulting Mission Expansion request if any. Records MUST be append-only and integrity-protected in deployment-defined storage. They are the local evidence record that the agent stayed within the user's approved intent. This strengthens the lifecycle audit-record shape described in the MVP's Operational Requirements: the MVP requires the record shape per Mission lifecycle event; IBAC Core additionally requires a per-decision record for every consequential action. Portable, third-party-verifiable cross-domain receipts are an Optional Module (the Decision Receipt Profile), not Core. Core only requires the record shape and local integrity protection; deployments that need cross-domain auditability layer the Optional Module on top. # Optional Modules The following profiles compose on top of Core. Each is independently adoptable. A deployment claims Core compliance without any Optional Module; full Conformance Level 5 requires the modules relevant to the deployment's risk and governance posture. ## Tool Binding Profile IBAC binds approved authority to concrete tools, OpenAPI operations, MCP tool identifiers, or workflow steps. The AS MUST consult a tool manifest (RFC 9728 PRM extension, MCP server manifest, OpenAPI document, or equivalent) at approval time and bind each approved `resource_access.actions` value (or ecosystem-specific equivalent) to a stable tool identifier. Derived requests MUST present the tool identifier; the PDP MUST validate that the identifier is in the approved set. Tool-manifest drift after approval MUST cause refusal or trigger Mission Expansion; it MUST NOT silently broaden the agent's authority. On the wire, tool-and-action binding upgrades `resource_access.actions` from a simple string array to an array of per-action objects. Each object binds the action name, the tool identifier, the manifest operation reference, and the manifest digest together so that the PDP can validate all four invariants on a single request: ```json [ { "type": "mission_intent", "purpose": "urn:example:mission:board-packet", "mission_expiry": "2026-06-05T12:00:00Z", "context": { "classification": "confidential", "tool_manifest": { "uri": "https://docs.example.com/.well-known/tool-manifest", "digest": "sha256-3Yk..." } } }, { "type": "resource_access", "resource": "https://docs.example.com", "actions": [ { "name": "documents.read", "tool_id": "docs.example.com:documents.read@v1.2", "operation_ref": "#/paths/~1documents~1{id}/get", "manifest_digest": "sha256-3Yk..." }, { "name": "documents.write", "tool_id": "docs.example.com:documents.write@v1.2", "operation_ref": "#/paths/~1documents/post", "manifest_digest": "sha256-3Yk..." } ] } ] ``` The per-action object MUST include `name`. When tool-and-action binding is in effect, `tool_id`, `operation_ref`, and `manifest_digest` are also required. The PDP MUST validate that the inbound request presents a matching `tool_id` and that the live manifest digest at fetch time equals the stored `manifest_digest`. Drift detection: when the orchestrator submits a request bearing a `tool_id` not in the approved set, the PDP MUST refuse. When the manifest's digest at fetch time differs from the stored digest, the AS MUST treat this as drift and either refuse new derivations or require Mission Expansion. ## Decision Receipt Profile When third-party verification across organizational or trust-domain boundaries is required, the Decision Receipt Profile defines a portable cryptographic receipt format that an external auditor can verify without access to the originating AS's storage. The substrate is W3C Verifiable Credentials Data Model 2.0: each Decision Evidence Record from Core is wrapped in a VC signed by the PDP, with the Mission Authority as the credential subject and the receipt content as credential claims. The portable receipt format is layered on the Core record shape; deployments that operate within a single trust domain can ship Core records only and add this module later for cross-domain auditability. A deployment that adopts this module MUST verify VC signatures against the PDP's published key set; auditors MUST treat the VC as evidence of authorization, not as authorization itself. ## Actor Provenance Profile IBAC requires actor binding on every Mission-bound token and ID-JAG, not only on sub-agent paths. The `act` chain MUST identify the delegation chain of agents and sub-agents (orchestrator client instance plus each sub-agent invoked via Token Exchange with an `actor_token`). Each `act` hop is an OAuth actor in the RFC 8693 sense: a principal that received delegated authority. Provenance beyond the delegation chain (tools, workflow steps, human approvers, execution environments) is recorded separately, not inside `act`. The IBAC Mission introspection response and per-decision evidence records carry these in dedicated fields: - **`tool` / `tool_id`** for the manifest-bound tool the action invoked (Tool Binding Profile). - **`workflow_step`** for the named workflow step (orchestrator-defined or workflow-engine-defined). - **`approver`** for a human-in-the-loop approver of a specific action (deployment-defined identity). - **`execution_environment`** for the attested runtime (Attestation Profile composition: RATS PTV identifier or WIMSE workload identity). Keeping these separate from `act` keeps the delegation chain clean (one principal per hop, signed under OAuth conventions) while letting the PDP and the audit layer attribute every dimension of provenance. Actor receipts (per [Actor Receipts](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts)) are RECOMMENDED for high-risk Mission classes and MUST be supported by IBAC-compliant deployments even when not always emitted. ## Purpose Registry Profile This module defines a governed registry of `mission_intent.purpose` URIs. Each registered purpose MUST declare the allowed resource types and actions, the required and forbidden constraints, the risk class and escalation rules, the display language for consent rendering with localization, and the maximum Mission lifetime and reauthorization cadence. Free-form purpose URIs are sufficient for Core; the registry adds governance for deployments that operate at scale or across organizations. The registry MAY be operated by the AS, by an organizational governance authority, or by an industry body. ## Attestation Profile This module binds the Mission `cnf` to an attested agent identity or execution environment. The PDP consumes attestation evidence alongside the `act` chain and the Mission record when evaluating policy. The substrate composes with [RATS PTV (Prove-Transform-Verify)](https://datatracker.ietf.org/doc/draft-anandakrishnan-rats-ptv-agent-identity/) for attested agent identity and with WIMSE Workload Identity for attested execution environments. For high-assurance Mission classes the PDP MAY require fresh attestation evidence on every consequential decision. The wire shape is left to the substrate spec; this module names the composition point. See Roadmap. ## Policy Projection Profile This module defines the AS-to-RS wire shape for carrying compiled Authority Model policy from the originating AS to Cedar-capable or AuthZEN-capable Resource Servers. The MVP's Cedar example shows what an AS-compiled policy looks like; this module standardizes the carriage mechanism so the PDP at the RS does not have to round-trip to the AS to evaluate. The substrate is Cedar in `authorization_details` (or a future generic compiled-policy carriage). See Roadmap. # Architectural Challenges IBAC is more ambitious than the MVP and inherits four hard problems that the protocol cannot fully solve. Acknowledging them is part of the spec's honest contract with implementers. ## PDP Latency Overhead IBAC mandates a synchronous PDP evaluation via AuthZEN Access Evaluation for every consequential agent action, including non-OAuth tool calls, file writes, and database checks. In massive agent chains with hundreds of tool calls per task, cumulative latency can bottleneck execution loops. The latency profile is dominated by the network hop between orchestrator and PDP plus the PDP's evaluation time. Deployments mitigate by: - Colocating the PDP with the AS or the Resource Server (PDP Deployment Modes table above). - Reserving the strictest gating (TOCTOU-verified permits) for Irreversible Actions, External Commitments, and Privileged Administration; classifying lower-risk reads as Consequential Read or Non-consequential so the PDP roundtrip is avoided or amortized. - Caching policy-version-bound permits within the parameter-digest scope for repeated identical operations. - Treating the Action Classification table as a tuning knob: deployments with latency-sensitive workloads can raise the bar for what counts as "consequential." The latency is real and the classification is the primary lever. IBAC does not promise zero-overhead enforcement. ## Lethal Trifecta Control The Runtime Enforcement Profile is where Mission-Bound OAuth addresses the agent lethal trifecta at execution time. The trifecta appears when one agent loop has private-data access, untrusted-content exposure, and authority to cause external side effects or exfiltrate data. The profile does not make that combination safe by granting it as one broad Mission. It makes the combination governable by forcing each consequential step through the same Mission-bound PDP contract: | Trifecta element | Runtime Enforcement control | | --- | --- | | Private data access | PDP evaluates resource, action, actor, tenant, purpose, time, and constraints before the read or derived token is accepted | | Untrusted content exposure | Policy can classify source, risk tier, and context; untrusted content cannot expand Mission authority without Mission Expansion | | External side effects | Local-action boundary requires AuthZEN Access Evaluation before sends, publishes, payments, file writes, egress, or other consequential actions | This is the key distinction from the MVP. The MVP prevents future derivation after Mission state changes and gives every artifact a common Mission handle. Runtime Enforcement controls what the agent may do *inside* an active Mission. It requires parameter binding, per-decision evidence, policy freshness, requestable denial, and Mission Expansion for actions that are outside the approved bounds. A deployment claiming Runtime Enforcement Profile compliance therefore cannot treat `mission.id` as ambient authority. `mission.id` is the lookup key for policy. The permit still depends on the concrete resource, action, actor chain, tenant, parameters, policy version, and Mission state at decision time. ## Unknown Constraint Brittleness (under IBAC) The MVP's "preserve or refuse" rule for unknown constraints becomes "refuse" under IBAC. The MVP's [Architectural Challenges](/notes/mission-bound-oauth-mvp/#architectural-challenges) cover the general shape. Under IBAC the trade is sharper: the silent-drop attack surface is gone, but multi-vendor deployments face a refusal anywhere the vocabulary diverges. Two Optional Modules mitigate each half of the problem. The Purpose Registry Profile gives deployments a place to register expected constraints per `purpose` URI, so the constraint vocabulary is pre-coordinated rather than refused on contact. The Tool Binding Profile mitigates the action half: when actions are bound to manifest-identified tools, the action vocabulary is also pre-registered. Constraint brittleness is most acute in deployments that compose Optional Modules from different vendors without either registry. ## State Synchronization at Scale The MVP's State Synchronization Scale challenge becomes load-bearing under IBAC because every consequential action goes through the PDP. The Policy Freshness Rules in Core require a 30-second cache TTL absent a current SSF/CAEP subscription, and fail-closed on uncertainty. The worst-case staleness window is bounded by the smaller of the cache TTL or the event lag. Cross-AS Mission state federation accumulates lag across hops. Deployments at scale must monitor SSF/CAEP event delivery and accept that IBAC promises bounded staleness, not real-time consistency. ## Tool Manifest Fracturing The Tool Binding Profile relies on a `manifest_digest` over a `tool_manifest` reference. In practice no industry-wide consensus exists today on what a tool manifest format is. OpenAPI documents, MCP server definitions, A2A Agent Cards, and proprietary agent graphs each have their own structure and canonicalization rules. Computing a cryptographic hash that survives format-aware re-serialization across vendors is a real interop problem. The Tool Binding Profile defers manifest format to the deployment. A single-vendor or single-format deployment can apply the profile today. A cross-vendor deployment needs a manifest-format adapter layer, or a future tool-manifest interoperability standard, before the profile delivers cross-vendor drift detection. This is an industry coordination problem, not a protocol bug, but it limits the Tool Binding Profile's near-term reach. # Standards Composition These rows describe what IBAC additionally requires or strengthens beyond the MVP. | Concern | IBAC mechanism | Why it is needed | Composed with | | --- | --- | --- | --- | | Compiled policy | AS deterministically compiles the approved `authorization_details` into an evaluable policy artifact at activation | Gives the PDP a stable, hashable artifact to evaluate every request against | Cedar, OpenFGA tuples, AuthZEN policy; can compose with [draft-cecchetti-oauth-rar-cedar](https://www.ietf.org/archive/id/draft-cecchetti-oauth-rar-cedar-02.html) for AS-to-RS policy carriage | | Tool and action binding | Approved actions bound to manifest-identified tools at approval time | Prevents post-approval manifest drift from broadening agent authority | [RFC 9728 PRM](https://datatracker.ietf.org/doc/html/rfc9728), MCP server manifests, OpenAPI | | Mandatory runtime escalation | AuthZEN Access Request becomes MUST for in-policy denials | Eliminates the silent-failure path; every in-policy denial becomes a governance handle | [AuthZEN Access Request](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) (AuthZEN WG draft) | | Local-action policy gate | AuthZEN Access Evaluation MUST for every consequential non-OAuth action | Brings tool calls, file writes, payment confirmations, and other side effects under the same authority bounds as OAuth-protected APIs | [AuthZEN Authorization API](https://openid.github.io/authzen/) | | Extended introspection | RFC 7662 response additionally carries compiled policy version, `act` chain, tenant, subject, and audience-relevant `authorization_details` | Lets RS/PDP evaluate every approved bound, not only check token validity | [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) | | Full actor chain | `act` chain MUST on every Mission-bound token, not only sub-agent paths | Lets the PDP and audit attribute every consequential action to a specific actor (orchestrator, sub-agent, tool, human approver) | [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/), [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) | | Decision evidence | Per-decision evidence records bound to `mission.id`, `mission.origin`, `proposal_hash`, compiled policy version, decision, constraint clauses, and actor chain | Provides per-action evidence that the agent stayed within approved intent; portable receipts are an optional profile over these records | [Actor Receipts](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts) | | Governed purpose registry | Registered `mission_intent.purpose` URIs declaring allowed resources, actions, constraints, risk class, escalation rules, display language, and reauthorization cadence | Constrains free-form intent to governed templates with enforceable defaults | Future profile; deployment registry | The IBAC profile turns the MVP's token-binding model into a runtime authority model: the Mission is not only a token-bounding object, it is the authoritative input to every PDP decision for every consequential agent action. # Gaps and Open Issues ☐ **Formal policy.** Should a later profile define a recommended AS-compiled policy format, or leave formal policy entirely deployment-specific? ☐ **Tool-manifest binding.** IBAC requires manifest-identified tool binding but does not standardize the manifest reference format. Should a later profile bind `mission_intent` to tool manifests using `{uri, digest}`, signatures, or some richer manifest format? # Standards Path The Runtime Enforcement Profile would ship as a companion Internet-Draft, `draft-mcguinness-oauth-mission-bound-runtime-enforcement-profile`, layered on top of `draft-mcguinness-oauth-mission-bound-minimum-profile`. Its normative additions are: - Intent-to-policy compilation requirement (AS-side, deterministic, reproducible). - Tool-and-action binding to manifest-identified tools at approval time. - Mandatory runtime escalation via AuthZEN Access Request. - Local-action policy gate via AuthZEN Access Evaluation for non-OAuth actions. - Extended Mission introspection response (compiled policy version, `act` chain, tenant, subject, audience-relevant `authorization_details`). - Mandatory `act` chain on every Mission-bound token, not only sub-agent paths. - Per-decision evidence records bound to `mission.id`, `mission.origin`, `proposal_hash`, compiled policy version, decision, constraint clauses, and actor chain. - Governed `mission_intent.purpose` registry with declared bounds, risk class, escalation rules, and reauthorization cadence. Later profiles can add tool-manifest binding signatures, Mission receipts, formal policy projection, per-actor revocation, and key-compromise lifecycle events without changing the MVP's core wire shape or the Runtime Enforcement Profile's enforcement contract. Mission-Bound OAuth becomes IBAC when the Mission is not only a token-bounding object, but the authoritative input to runtime policy decisions for every consequential agent action. Execution continuity comes from gating every step against one approved authority object. Proof of authority comes from producing an evidence record for every step, with portable receipts layered on where third-party verification is required. Both fall out of the same construction. # Standards Ask A focused list of what this post asks of the standards community. **Standardize now (Runtime Enforcement Profile Core):** - AS-side deterministic Intent-to-Policy compilation requirement, with `policy_version` surfaced on tokens and introspection. - Resource-Side Enforcement Contract: RS-B minimum; PDP evaluates every consequential request against approved bounds covering resource, action, constraints, actor, tenant, time, risk, purpose. - Standard Subset Semantics per RAR type, with strict refusal on unknown constraints (stricter than MVP). - Runtime Denial and Escalation: AuthZEN Access Request as MUST for in-policy denials. - Mission Introspection Profile: extended response with compiled policy version, `act` chain, tenant, subject, audience-relevant `authorization_details`. - Policy Freshness Rules: 30-second cache TTL or current SSF/CAEP subscription; fail-closed on uncertainty for consequential writes and above. - Local-Action Boundary: AuthZEN Access Evaluation as MUST for non-OAuth actions. - Action Classification: the six-class default (non-consequential, consequential read, consequential write, irreversible, external commitment, privileged administration). - Decision Evidence Records: per-decision record format with parameter binding for TOCTOU protection. **Compose with existing work:** - AuthZEN Authorization API (Access Evaluation) and AuthZEN Access Request (now an AuthZEN WG draft). - RFC 7662 introspection extended with Mission state. - W3C Verifiable Credentials Data Model 2.0 as the substrate for portable cryptographic receipts (Optional Module). - Actor Profile and Client Instance Assertion for the `act` chain (now MUST on every Mission-bound token). - RFC 9728 PRM, MCP server manifests, and OpenAPI documents for tool-manifest references. **Defer to optional modules:** - Tool Binding Profile (manifest signatures, version labels, content-type negotiation). - Decision Receipt Profile (portable cryptographic receipts cross-domain). - Purpose Registry Profile (governed `mission_intent.purpose` URIs with declared bounds). - Actor Provenance Profile (extends `act` chain beyond delegation; adds `tool`, `workflow_step`, `approver`, `execution_environment`). - Attestation Profile (RATS PTV, WIMSE Workload Identity). - Policy Projection Profile (AS-to-RS Cedar carriage). # Roadmap The Runtime Enforcement Profile ships in step with the [MVP](/notes/mission-bound-oauth-mvp/) and inherits its dependency stack. The ordering below is about runtime-enforcement-specific work that follows the base profile. Each phase is tagged with the goal it primarily advances: **(C)** for execution continuity, **(P)** for proof of authority. ## Now: shipping the Runtime Enforcement base profile The Core normative additions defined in this post, packaged as `draft-mcguinness-oauth-mission-bound-runtime-enforcement-profile` layered on the MVP. Composes with AuthZEN Authorization API and AuthZEN Access Request. Delivers both (C) and (P) at the baseline. ## Next: filling the open Runtime Enforcement questions - **Standardized AS-compiled policy format (C, P).** Today the profile says the AS compiles to Cedar, OpenFGA, AuthZEN policy, or any internal representation. A follow-up profile could pick a baseline format (most likely Cedar) and define carriage on tokens to RS-C audiences. Advances continuity by giving every PDP a deterministic evaluation surface, and proof by making the policy version hashable. - **Tool-manifest wire-shape standardization (C, P).** Beyond the minimum `{uri, digest}` shape this profile uses, define signature support, version labels, and content-type negotiation for manifests. Advances continuity by detecting drift before it broadens authority, and proof by binding the manifest digest into receipts. - **PDP discovery (C).** AuthZEN-standard `.well-known/authzen-configuration`, or a Mission-Bound-specific discovery surface that locates the PDP for a given `mission.origin`. Advances continuity by making PDP wiring interoperable across deployments. - **Per-decision audit receipt format (P).** Concrete W3C Verifiable Credentials 2.0 substrate for portable, third-party-verifiable receipts that bind `mission.id`, `proposal_hash`, compiled policy version, decision, constraint clauses, and `act` chain. Pure proof-of-authority work. ## Then: Runtime Enforcement + attestation - **RATS PTV composition (C, P).** Bind the Mission `cnf` to a [Prove-Transform-Verify](https://datatracker.ietf.org/doc/draft-anandakrishnan-rats-ptv-agent-identity/) attested agent identity for high-assurance Mission classes. The PDP MAY require fresh attestation evidence on every consequential decision under the highest risk tiers. Advances continuity by letting high-assurance Missions keep running across attested-environment changes, and proof by including attestation evidence in receipts. - **WIMSE Workload Identity composition (P).** Attest the execution environment of the orchestrator and any sub-agents; the PDP consumes the workload identity alongside the `act` chain when evaluating policy. Strengthens proof of authority at the workload layer. ## Later: governance extensions - **Governed `mission_intent.purpose` registry standardization (C).** Today this profile requires a registry but does not specify its operator, namespace, or interop. Candidates: IETF namespace (purposes registered with IANA), OpenID Foundation namespace, or an industry-body registry. Cross-organizational interop may require federation between registries. Advances continuity by letting any IBAC AS validate any registered purpose. - **Risk-tier and assurance-level constraint catalog (C, P).** Standardize the `assurance_level` and `risk_tier` values on `mission_intent.context` that the governed purpose registry references. Advances continuity by making escalation rules consistent, and proof by recording the evaluated risk tier on receipts. - **Multi-tenant purpose registry interop (C).** When a Mission crosses tenant boundaries, the purpose URI semantics MUST be consistent across the tenants. A registry federation profile would address this. Advances continuity across tenants. ## Long-term - **Cryptographic actor-chain verification (P).** Extend [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) with a Verified Full Disclosure mode for high-assurance Mission classes: each `act` hop signs a commitment over the previous hop so the PDP can verify the chain end to end, not only inspect it. Strengthens proof of authority for sub-agent attribution. - **Cross-AS audit-receipt federation (P).** Audit receipts from multiple ASes under one Mission, joinable by `mission.id` plus `proposal_hash`, retrievable through a federated query API. Closes the cross-AS proof-of-authority loop. - **Real-time policy update propagation (C).** When a Mission's compiled policy version changes (Mission Expansion, in-place amendment), notify subscribing PDPs and Resource ASes before stale evaluations occur. CAEP-like semantics scoped to policy-version changes. Advances continuity by preventing stale-policy refusals after legitimate authority updates. # Implementation Checklist A deployment claims Runtime Enforcement Profile compliance when it meets the MVP [Implementation Checklist](/notes/mission-bound-oauth-mvp/#implementation-checklist) plus the following. **Authorization Server (additional under Runtime Enforcement):** - [ ] Compiles the approved `authorization_details` array into an evaluable policy artifact at Mission activation; compilation is deterministic and reproducible. (Intent-to-Policy Compilation) - [ ] Stores the compiled artifact on the Mission record with a version or fingerprint. (Intent-to-Policy Compilation) - [ ] Binds each approved action to a manifest-identified tool identifier at approval time. (Tool and Action Binding) - [ ] Surfaces the compiled-policy version on introspection responses. (Mission Introspection Profile) - [ ] Issues every Mission-bound token (not only sub-agent paths) with a full `act` chain identifying orchestrator, sub-agents, tool/workflow steps, and human approvers. (Actor and Provenance Chain) - [ ] Maintains a governed registry of `mission_intent.purpose` URIs with declared bounds, risk class, escalation rules, display language, and reauthorization cadence. (Governed Purpose Registry) **PDP (Policy Decision Point):** - [ ] Exposes AuthZEN Access Evaluation endpoint at `/access/v1/evaluation` per the AuthZEN Authorization API. (Wire example above) - [ ] Evaluates every consequential request against the Mission's compiled policy plus local rules. (Resource-Side Enforcement Contract) - [ ] Refuses on unknown constraint (stricter than MVP's "preserve or refuse"). (Standard Subset Semantics per RAR Type) - [ ] Returns denials with an AuthZEN Access Request handle when the denial is in-policy-expandable. (Runtime Denial and Escalation) - [ ] Produces a per-decision evidence record for every consequential action: `mission.id`, `mission.origin`, `proposal_hash`, compiled policy version, decision, constraint clauses, `act` chain, optional expansion request. (Decision Evidence Records) - [ ] Validates that any tool identifier presented on a request is in the approved manifest-bound set. (Tool and Action Binding) **Resource Server (RS-B or higher required):** - [ ] Consults the PDP for every consequential request, evaluating against the Mission's approved bounds covering resource, action, constraints, actor, tenant, time, risk, and purpose. (Resource-Side Enforcement Contract) - [ ] Refuses requests whose `act` chain does not match the approved chain. (Actor and Provenance Chain) **Orchestrator:** - [ ] MUST NOT execute consequential local actions inline; consults the PDP before tool invocations, file writes, payment confirmations, and other side-effecting operations. (Local-Action Boundary) - [ ] Presents tool identifiers on every derivation and request for the PDP to validate against the manifest binding. (Tool and Action Binding) **Discovery (proposed):** - [ ] AS or Resource Server advertises PDP endpoint via `.well-known/authzen-configuration` per the AuthZEN Authorization API. (See Gaps; PDP-discovery normative shape is open.) - [ ] AS metadata advertises Runtime Enforcement Profile compliance via `mission_profiles_supported` including `"runtime_enforcement"`. (See Gaps.) # References - [AuthZEN Authorization API 1.0](https://openid.github.io/authzen/) — the wire protocol for PDP queries. - [AuthZEN Access Request](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) (AuthZEN WG draft) — requestable-denial extension. - [draft-mcguinness-oauth-actor-profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) — Actor Profile. - [draft-mcguinness-oauth-client-instance-assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) — Client Instance Assertion. - [draft-mcguinness-oauth-actor-receipts](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts) — Actor Receipts. - [draft-cecchetti-oauth-rar-cedar](https://www.ietf.org/archive/id/draft-cecchetti-oauth-rar-cedar-02.html) — Cedar-in-RAR (optional AS-to-RS policy carriage). - [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) — OAuth 2.0 Token Introspection (extended response under Runtime Enforcement). - [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) — OAuth 2.0 Protected Resource Metadata (for tool-manifest references). - [Mission-Bound OAuth MVP](/notes/mission-bound-oauth-mvp/) — the underlying profile this one strengthens.