The Mission is the Missing Abstraction for Agents made the conceptual case. The 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 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 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). 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):

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. 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 shows how an approved Mission projects to tokens across many Resource ASes. Under IBAC, the same Mission gets runtime enforcement at every consequential action.

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

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:

1
2
3
4
5
6
7
8

{
  "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):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "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.

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 (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:

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

[
  {
    "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) 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) 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:

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

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 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 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 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 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 — the wire protocol for PDP queries.
• AuthZEN Access Request (AuthZEN WG draft) — requestable-denial extension.
• draft-mcguinness-oauth-actor-profile — Actor Profile.
• draft-mcguinness-oauth-client-instance-assertion — Client Instance Assertion.
• draft-mcguinness-oauth-actor-receipts — Actor Receipts.
• draft-cecchetti-oauth-rar-cedar — Cedar-in-RAR (optional AS-to-RS policy carriage).
• RFC 7662 — OAuth 2.0 Token Introspection (extended response under Runtime Enforcement).
• RFC 9728 — OAuth 2.0 Protected Resource Metadata (for tool-manifest references).
• Mission-Bound OAuth MVP — the underlying profile this one strengthens.