Abstract

On the spine: Part 6 specifies the Enforcement step, independent of substrate. The Mission and Authority steps (Parts 3, 4, 5) produce the inputs this profile evaluates; the Intent step (Part 2) is upstream.

The Mission is the Missing Abstraction for Agents made the conceptual case. The Mission-Bound OAuth Profile adds a durable governance layer to OAuth. Mission-Bound AAuth composes that governance model with AAuth’s already-defined native Mission. This post adds runtime enforcement on top of either projection, with per-action evaluation and per-decision evidence. Least-Privilege MCP Tool Calls Need a Mission applies the stack to MCP. The Mission Authority Server Profile moves shared governance to a MAS when needed; the runtime contract remains the same, with mission.origin resolving to the state authority.

This profile is substrate-independent at its Core boundary. The PDP receives a Mission projection, current state, applicable Authority Set entries, authenticated subject and actor context, resource, action, parameters, tenant, and current policy context. OAuth and AAuth adapters obtain those values from their native credentials and protocol artifacts. Decision evidence binds to the Mission projection and mission.origin; pairwise identifiers are resolved by authorized auditors.

The governance profiles control what authority can be issued and derived. This profile controls how that authority is exercised.

What Runtime Enforcement Adds

Execution continuity. A long-running task stays within the user’s approved bounds across actions, delegated actors, hops, and time. Every consequential action is evaluated against current Mission state, applicable authority, and resource policy. An in-bounds action may still fail because of resource state, risk, concurrency, or availability. A request outside current Mission authority may become a governed Mission Expansion only when registration and deployment policy permit it.

Decision accountability. Every consequential action produces an evidence record bound to the Mission, authority commitment, policy version, decision, relevant constraints, authenticated actor context, and delegation chain when present. Core requires locally integrity-protected evidence. Portable third-party-verifiable proof requires the optional receipt module.

Mission-Bound Authorization becomes Intent-Based Access Control (IBAC) when the Mission is not only a credential-bounding object but a required input to runtime decisions for consequential actions. Current resource policy remains authoritative for the final permit or deny result.

This companion profile is optional for the wider architecture and required for any deployment claiming request-time Mission enforcement.

What the Governance Profiles Give You

Readers who just finished the OAuth Profile or Mission-Bound AAuth can skim this section. It is a reference for readers landing on Part 6 directly. The governance profiles already define or map:

• A Mission record at an OAuth AS, an AAuth Person Server, or a MAS.
• A canonical Authority Set committed by authority_hash. OAuth-only deployments may use the approved authorization_details array as their single-substrate representation.
• A substrate-native Mission reference: the OAuth mission claim, AAuth’s (approver, s256) reference with an optional governance projection, or a future substrate equivalent.
• A per-entry, per-type subset rule for derivation against the approved Authority Set: requested entries MUST be subsets of approved entries of the same type. Unknown constraints may pass through only to a known enforcement point required to enforce them; otherwise derivation is refused.
• Cross-substrate and cross-AS derivation that preserves an authenticated Mission binding (OAuth Token Exchange and ID-JAG; AAuth’s substrate-native derivation). OAuth carries mission.id and mission.origin; AAuth preserves (approver, s256) and resolves the governance mapping when this composition profile is in use.
• 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 credential-issuance 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 committed authority bounds and current Resource policy, 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 under Part 8. Interoperable Level 5 claims require the relevant optional-module specifications; implementing the sketches in this post locally is not enough.

Core sections (required for Runtime Enforcement Profile compliance):

• Mission-to-Policy Materialization: the state authority or a trusted compiler reproducibly materializes the approved Mission tuple as a versioned, evaluable policy view.
• Resource-Side Enforcement Contract: PDP evaluates every consequential request against approved bounds; RS-D required within the claimed scope.
• Standard Subset Semantics: per-authority-type subset rules with refusal on unknown machine-enforceable constraints.
• Runtime Denial and Escalation: denials caused specifically by missing but policy-eligible Mission authority are requestable Mission Expansions via AuthZEN Access Request (MUST). Resource-state, risk, concurrency, and other local denials remain ordinary denials.
• Mission Status and Runtime Context: authenticated Mission state, policy version, actor context, and audience-filtered Authority Set projection, separate from credential introspection when the state authority did not issue the credential.
• Local-Action Boundary: the component controlling a consequential non-OAuth action acts as PEP and obtains an AuthZEN Access Evaluation before execution.
• Decision Evidence Records: every consequential decision produces evidence bound to the Mission, authority commitment, actor context, policy version, and request. Portable cryptographic receipts are an Optional Module.

Optional module sketches (independently adoptable only with a deployment-defined binding):

Each module corresponds to a section below. These sections identify composition contracts and future standards work; they do not yet define portable interoperability profiles. A deployment may implement one through a local binding, but cannot claim cross-vendor module conformance from this post alone. Everything else is Core.

Threat Impact Relative to the OAuth Profile

Several threats in the OAuth Profile’s Privacy and Security section are mitigated more strongly under IBAC than under the OAuth Profile alone.

• Silent constraint loss is reduced from “preserve verbatim or refuse” during derivation to “understand and enforce or refuse” at runtime for every machine-enforceable constraint in the applicable Authority Set or policy view.
• Downstream over-granting is constrained at request time, not only at token issuance, because RS-D and the runtime policy gate evaluate every consequential request against the approved bundle.
• Confused deputy through sub-agents is bounded more tightly because the PDP evaluates the RFC 8693 act chain whenever delegation is present and always evaluates the authenticated client or client instance.
• Stale Mission state is reduced by bounded freshness checks at each consequential decision, though it is not eliminated. Audience replay remains a credential-validation concern and is unchanged by this profile.

Key Use Cases

Five concrete cases that Runtime Enforcement newly enables on top of the OAuth Profile. Where that profile already gives a partial answer, Runtime Enforcement 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.
• OAuth Profile gives: not standardized. A deployment can use the Mission record as local-policy input, but the OAuth Profile does not define PDP consultation for non-OAuth actions.
• Runtime Enforcement delivers: the component controlling a consequential local action acts as PEP and MUST consult the PDP before execution. Every PDP decision produces evidence bound to the Mission, policy version, decision, relevant constraints, and authenticated actor context.
• Enabling features: AuthZEN Access Evaluation, a versioned Mission policy view, per-decision evidence, and AuthZEN Access Request for authority-expandable denials.

Capability-drift detection

A Resource Server deploys a new tool that an existing approved scope now covers. The user approved against an older capability catalog.

• Today: the AS validates scope and the RS validates scope; the new tool is reachable; the agent gains capability the user never saw. This is especially dangerous in regulated or high-risk environments.
• OAuth Profile gives: tool-bounded narrowing is useful deployment practice, but the OAuth Profile does not standardize capability binding.
• Optional Tool Binding Profile delivers: the validating server binds approved actions to operations in a versioned capability source, such as an MCP tools/list snapshot or OpenAPI document. Governed requests present the stable capability identifier, and the PDP validates it. Drift after approval causes refusal or Mission Expansion.
• Enabling features: source identifier, operation reference, source digest, and refusal on drift when the module is enabled.

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.
• OAuth Profile gives: standard Mission Intent constraints and preservation/refusal rules for deployment-defined constraint keys. A deployment can define budget keys and count derivations, but the OAuth Profile does not standardize budget semantics.
• Runtime Enforcement delivers: the PDP evaluates each consequential request against a machine-enforceable budget in the policy view. The authoritative counter performs an atomic reserve or charge so concurrent permits cannot independently overspend the same remaining balance. Crossing the cap refuses the action at the execution boundary.
• Enabling features: AuthZEN Access Evaluation, a standardized or deployment-defined budget constraint, atomic Mission-scoped counters, and evidence recording the budget delta.

Per-decision evidence with 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.
• OAuth Profile gives: lifecycle audit records keyed on mission.id with proposal_hash, authority_hash, and consent_rendering_hash, but no per-decision evidence or policy version.
• Runtime Enforcement delivers: each consequential PDP evaluation produces append-only, integrity-protected evidence bound to the Mission, policy version, permit or deny result, relevant constraints, authenticated actor context, delegation chain when present, and any Mission Expansion request.
• Enabling features: versioned policy view, authenticated Mission Status or issuer-provided equivalent, per-decision evidence, and authenticated actor 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.
• OAuth Profile gives: an act chain on sub-agent derivation paths. It supports attribution after the fact but not selective revocation.
• Runtime Enforcement delivers: every decision identifies the authenticated client or client instance. When authority was delegated, the token MUST carry the RFC 8693 act chain and the PDP MUST evaluate it. Tools, workflow steps, human approvers, and execution environments are not OAuth actors and are recorded through the Optional Actor Provenance Profile. This actor model is the foundation for a future revoke_actor profile (see Gaps) that evicts a compromised delegated actor while leaving the Mission active.
• Enabling features: mandatory authenticated actor context, act on delegation paths, the optional Actor Provenance Profile, PDP actor evaluation on every decision.

Worked Example

The OAuth Profile’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 OAuth Profile’s 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 that example glossed:

• Mission activation also materializes the approved tuple as a versioned policy view, such as Cedar, OpenFGA tuples, or a canonical input bundle.
• 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.
• Authority-expandable requests (the finance-data step in the OAuth Profile example) produce a MUST-level requestable denial with a Mission Expansion handle. Denials caused by current resource state, risk, or local policy do not become expansion requests.
• Every consequential PDP decision produces evidence bound to the Mission, policy version, result, relevant constraints, authenticated actor context, and delegation chain when present. Audit is per-decision, not only per-lifecycle-event.

The diagram shows two separate execution boundaries. The orchestrator acts as PEP for a local tool; the Resource Server acts as PEP for its own API request. A single action is evaluated once at the component that can prevent its execution, not redundantly by both components.

Core

The following sections define the enforcement contract required for Runtime Enforcement Profile compliance. They apply to any supported substrate; OAuth-specific rules are identified where needed.

Mission-to-Policy Materialization

Before a Mission can govern runtime decisions, the deployment MUST materialize a versioned policy view from the approved Mission tuple. That tuple consists of the Approved Mission Intent, the canonical Authority Set committed by authority_hash, tenant binding, approved actor bounds, enabled capability bindings, and versioned deployment-policy inputs. In an OAuth-only deployment, the Authority Set may be the AS-derived authorization_details; under a MAS or cross-substrate deployment it is the typed Authority Set defined by Part 5.

The policy view may be a compiled Cedar policy, OpenFGA tuples, another engine-native artifact, or a canonical input bundle evaluated directly by the PDP. The compiler MAY run at the AS, PS, MAS, or a trusted policy service. It MUST produce a stable policy_version or fingerprint over the complete versioned input set and compiler identity so the decision can be reproduced. Rebuilding identical inputs with the same compiler version MUST produce an equivalent policy view.

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
33
34
35
36
37
38

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Content-Type: application/json

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "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",
    "mission": {
      "mission_id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
      "mission_origin": "https://as.example.com",
      "proposal_hash": "fS8h4w7Z3Lq...",
      "authority_hash": "o2j2..."
    },
    "actor": {
      "client_id": "subagent.example.com",
      "instance_id": "inst_42",
      "act_chain": [
        { "client_id": "agent.example.com" },
        { "client_id": "subagent.example.com", "instance_id": "inst_42" }
      ]
    }
  }
}

The context.mission and context.actor members are proposed MBO extensions carried in AuthZEN’s open-ended context object; the base Authorization API does not define them. The AuthZEN subject remains the principal for whom the decision is requested. The substrate adapter at the PEP translates authenticated native Mission and actor context into these extensions.

The translation between shapes:

1
2
3
4
5
6
7
8
9

{
  "sub": "alice@example.com",
  "act": {
    "sub": "sub-agent-finance-v3",
    "act": {
      "sub": "orchestrator-instance-7f3a"
    }
  }
}

becomes, in the AuthZEN evaluation request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "context": {
    "actor": {
      "act_chain": [
        { "sub": "orchestrator-instance-7f3a" },
        { "sub": "sub-agent-finance-v3" }
      ]
    }
  }
}

The flat array is ordered root-to-leaf: the original actor is first and the current delegated actor is last. The PEP MUST validate the credential and its issuer, then translate the authenticated nested act claim. The nested actors are not independently signed merely because they appear in act; the flat array is a serialization convenience, not a separate authority claim.

Response on permit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "decision": true,
  "context": {
    "policy_version": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1#v1",
    "decision_id": "dec_01J2K7...",
    "decision_evidence_id": "evid_01J2K8...",
    "parameter_digest": "sha256:base64url-digest",
    "expires_at": "2026-06-01T15:00:10Z"
  }
}

Illustrative denial response for the MBO/AuthZEN binding. The base AuthZEN evaluation response does not itself standardize these context.access_request members:

 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-09-05T20:25:00Z",
      "binding_token": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC0xIn0..."
    }
  }
}

Resource-Side Enforcement Contract

Runtime Enforcement deployments require RS-D for every consequential Resource Server in the claimed scope, per Part 8’s Resource Server Tiers. Every consequential request MUST be evaluated against the Mission’s approved bounds, covering: resource, action, constraints, authenticated client or client instance, the act chain when delegation exists, tenant, time (within mission_expiry and any time-based constraints), risk signals (deployment-defined), and purpose when the Mission defines one. Lower tiers can participate in the deployment, but they remain outside the Level 4 claim.

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 profile does not mandate a mode. The requirement is that a PEP at each consequential execution boundary can reach an applicable PDP. AuthZEN Authorization API 1.0 defines PDP metadata, including policy_decision_point and access_evaluation_endpoint, obtained through /.well-known/authzen-configuration. Mission-Bound deployments still need local or profile-defined rules for selecting the correct PDP when several are advertised or when governance spans trust domains.

Standard Subset Semantics by Authority Type

The OAuth Profile’s per-entry, per-type subset rule applies to each request against its approved Mission projection. Other substrates apply the equivalent rule for their Authority Set types; this profile does not impose OAuth scope semantics on AAuth chaining. Runtime Enforcement adds:

• 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 enforcement. Every machine-enforceable constraint in the applicable Authority Set or compiled policy view MUST be evaluated by the PDP. An unknown constraint at this layer MUST cause refusal. User-language Mission Intent constraints influence compilation but are not independently interpreted at request time unless a profile gives them machine semantics.
• Conflict handling. When approved entries overlap, the owning authority type MUST define how they compose. If the PDP cannot compute a type-defined safe intersection, it MUST refuse rather than guess which constraint is more restrictive.

Mission Status and Runtime Context

Credential validation alone does not supply enough context for a Mission-aware decision. The PEP MUST validate the native credential and provide the PDP with:

• The substrate-native Mission reference plus its authenticated governance projection: state, and when active, expiry, purpose when present, proposal_hash, and authority_hash. OAuth uses id and origin; an AAuth adapter resolves (approver, s256) through the Part 4 composition mapping before constructing this view.
• The Authority Set entries relevant to the requesting audience. In an OAuth-only deployment these are the applicable authorization_details.
• Tenant and subject projections appropriate to the substrate and PDP trust domain. They may differ from identifiers used at earlier hops.
• Authenticated client or client-instance context, plus the act chain when delegation is in effect.
• The policy artifact version or fingerprint (policy_version), so the PDP can identify the exact policy view evaluated.

When the state authority issued the credential, an authenticated issuer endpoint MAY combine credential introspection and Mission status. When mission.origin identifies a separate MAS, credential validation remains with the issuer and Mission Status comes from the MAS. The PDP MUST NOT infer that mission.origin is also the credential issuer.

Policy Freshness Rules

The freshness model is a lease pattern. Issued tokens, cached Mission Status, and current policy views all act as leases on Mission authority: each is valid for a bounded window before it MUST be refreshed against the state authority or, on the consequential-action path, fail closed. The lease window is per-RS-tier — token TTL bounds RS-A audiences, a bounded cache or current SSF stream bounds RS-B and RS-C, and RS-D evaluates per request. The Resource Server Tiers in Part 8 describe each tier’s effective lease behavior. The rules below specify what every PDP MUST enforce within its chosen lease window.

PDPs that evaluate against cached Mission state or a cached policy view MUST respect the following freshness rules:

• Cache TTL. Each deployment profile MUST publish a maximum staleness bound by action class and risk. A high-risk profile might choose 30 seconds; this specification does not impose one universal value. A current SSF stream may extend the cache lifetime only while stream health and event processing remain within the published bound.
• policy_version coherence. Every PDP decision MUST record the policy_version evaluated. When the PDP receives fresher Mission Status or issuer context 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 within the published staleness bound, it MUST fail closed for every action classified as consequential. A deployment may classify low-risk reads as non-consequential or allow a bounded cached permit, but it must not label a read consequential and then bypass its PDP gate.
• Policy update propagation. Mission Expansion creates a successor Mission and new authority_hash. Rebuilding a policy view without changing approved authority MAY update policy_version only when the result is semantically equivalent under the same committed tuple. State authorities SHOULD emit an SSF event so subscribing PDPs can invalidate caches.

Runtime Denial and Escalation

A denial is authority-expandable only when the requested resource, action, audience, constraint relaxation, budget, or lifetime is absent from the current Mission but could be approved under requester registration and deployment policy. Such a denial MUST be representable as an AuthZEN Access Request. Denials caused by resource state, fraud or risk policy, concurrency, availability, malformed input, or an absolute policy prohibition MUST NOT be mislabeled as Mission Expansion. The orchestrator MAY initiate expansion from the requestable-denial signal.

The classification gate is load-bearing: a runtime-eligible local denial (resource state, risk signal, malformed input) must never be turned into a Mission Expansion handle, and a missing-but-policy-eligible authority must never be silently denied as if it were terminal. The PDP makes that classification; the orchestrator’s role is only to initiate the Access Request when the denial is marked requestable.

Local-Action Boundary

The OAuth Profile leaves non-OAuth local actions outside its wire contract. Runtime Enforcement brings them into scope. The component that can prevent a consequential local action acts as the PEP and MUST obtain an AuthZEN Access Evaluation before execution. When the orchestrator directly controls a tool invocation, file write, payment confirmation, or other side effect, the orchestrator is that PEP. A permit checked elsewhere in the workflow does not replace enforcement at the actual execution boundary.

Action Classification

The boundary between “consequential” and “not consequential” is deployment policy, but IBAC defines a default classification that deployments SHOULD adopt:

Deployment policy MAY further restrict a class for specific purpose URIs. For example, a purpose=urn:example:mission:research Mission may classify writing to a project document as a Consequential Write, while a financial-settlement purpose may classify a similar operation as an External Commitment. A purpose can raise the required class; it MUST NOT silently downgrade an operation below the resource owner’s minimum classification.

Parameter Binding and TOCTOU Protection

A permit for an operation does not authorize arbitrary parameter values. For consequential writes, irreversible actions, external commitments, and privileged administration, the PDP MUST bind its permit to the normalized action parameters through a parameter_digest. The digest is base64url-no-pad SHA-256 over the RFC 8785 JCS serialization of the normalized parameter object. The operation profile MUST define default insertion, omitted optional fields, and the semantics of set-like arrays before canonicalization.

The permit MUST also bind the Mission reference, subject, actor context, action, resource, policy_version, and a short validity window or single-use decision identifier. The executing PEP verifies those bindings and recomputes the parameter digest immediately before acting. This closes the Time-Of-Check-To-Time-Of-Use (TOCTOU) gap and prevents a permit from being replayed for a different request. Consequential reads do not require a parameter digest by default, but the complete evaluation request still appears in the evidence record or through a privacy-preserving request digest.

Decision Evidence Records

Every PDP decision on a consequential action MUST produce a decision evidence record containing the Mission reference, proposal_hash, authority_hash, subject and authenticated actor context, action, resource, policy_version, decision, relevant constraint identifiers, request time, and any resulting Mission Expansion request. It also contains parameter_digest when parameter binding is required; otherwise it SHOULD contain a privacy-preserving digest of the complete evaluation request. Delegated paths include the authenticated act projection. Raw parameters MAY be retained only in separately access-controlled evidence when policy requires them. Records MUST be append-only and integrity-protected in deployment-defined storage.

This strengthens the lifecycle audit-record shape described in the OAuth Profile’s Operational Requirements: the OAuth Profile 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 Module Sketches

The following sketches compose on top of Core. A deployment claims Core compliance without them. Conformance Level 5 is a target for future interoperable module specifications, not a claim created merely by implementing these sketches locally.

Tool Binding Profile

A deployment adopting this module binds approved authority to concrete tools, OpenAPI operations, MCP tool identifiers, or workflow steps. The validating server MUST resolve each approved action against a versioned capability source, such as an MCP tools/list snapshot, OpenAPI document, PRM-linked catalog, or equivalent. It records the source identifier, media type, operation reference, and source digest with the approved binding. Governed requests MUST present the stable capability identifier, and the PDP MUST validate that it remains in the approved set. Capability drift after approval MUST cause refusal or Mission Expansion; it MUST NOT silently broaden authority.

Tool binding does not change the OAuth Profile’s resource_access.actions string-array schema. It adds a sibling action_bindings array whose entries refer to names already present in actions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

[
  {
    "type": "resource_access",
    "resource": "https://docs.example.com",
    "actions": ["documents.read", "documents.write"],
    "action_bindings": [
      {
        "name": "documents.read",
        "tool_id": "docs.example.com:documents.read@v1.2",
        "operation_ref": "#/paths/~1documents~1{id}/get",
        "source_uri": "https://docs.example.com/openapi.json",
        "source_digest": "sha256:3Yk..."
      },
      {
        "name": "documents.write",
        "tool_id": "docs.example.com:documents.write@v1.2",
        "operation_ref": "#/paths/~1documents/post",
        "source_uri": "https://docs.example.com/openapi.json",
        "source_digest": "sha256:3Yk..."
      }
    ]
  }
]

Every action_bindings[].name MUST appear in actions. When tool binding is in effect, tool_id, operation_ref, and source_digest are required; the binding also identifies the source and media type. Unless the source format defines canonicalization, the digest covers the exact retrieved representation. The PDP validates the inbound tool_id against a freshly validated or freshness-bounded source snapshot; it need not retrieve the source synchronously for every call.

When a request bears a tool_id outside the approved set, the PDP MUST refuse. When the current source digest differs from the approved digest, the validating server MUST treat the change as drift and either refuse the action and new derivations or require Mission Expansion.

Decision Receipt Profile

When third-party verification across organizational or trust-domain boundaries is required, a future Decision Receipt Profile can define a portable cryptographic receipt that an external auditor verifies without access to the originating server’s storage. W3C Verifiable Credentials Data Model 2.0 is one candidate envelope, not a Core-selected substrate.

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

Core requires authenticated actor context on every decision. An OAuth adapter supplies client_id, client-instance context, and RFC 8693 act when delegation occurred. An AAuth adapter supplies the agent identifier, Agent Provider, Person Server, proof-of-possession key, and auth-token or upstream-token chain. The Optional Actor Provenance Profile adds richer attribution around that neutral core.

Provenance beyond the delegation chain (tools, workflow steps, human approvers, execution environments) is recorded separately, not inside act. The Mission Status response and per-decision evidence records carry these in dedicated fields:

• tool / tool_id for the source-bound capability 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 the substrate’s delegation chain lets the PDP and audit layer attribute every dimension of provenance. OAuth deployments MAY compose with Actor Receipts; support is not a Core requirement for deployments that do not adopt that module.

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 credential sender key or authenticated execution context to an attested agent identity or environment. The PDP consumes attestation evidence alongside the actor chain and Mission record. The substrate may compose with RATS PTV (Prove-Transform-Verify) or WIMSE Workload Identity. The Mission object itself does not define a cnf claim.

Policy Projection Profile

This future module would define a state-authority-to-PEP/PDP wire shape for carrying a policy view to capable Resource Servers. AuthZEN is the evaluation API, not a policy language. A general profile needs a typed policy-view entry and substrate-specific carriage rules. This post names the composition point but does not define a claimable module.

Architectural Challenges

IBAC is more ambitious than the OAuth Profile 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 short-lived, policy-version-bound permits for identical low-risk operations, while still enforcing request binding and producing evidence for each execution.
• 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. This section adds the runtime control layer on top of the OAuth Profile’s Lethal Trifecta Boundary, which bounds derivation but not execution; Part 7 walks the same boundary at the MCP tool-call layer.

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 OAuth Profile. The OAuth Profile 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

The OAuth Profile’s “preserve or refuse” rule for unknown constraints becomes “refuse” under IBAC. The OAuth Profile’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 vocabulary is coordinated before evaluation. The Tool Binding Profile addresses actions by binding them to source-identified capabilities. Brittleness is most acute when deployments combine independently defined constraint and action vocabularies without a shared profile.

State Synchronization at Scale

The OAuth Profile’s State Synchronization Scale challenge becomes load-bearing because every consequential action goes through the PDP. The Policy Freshness Rules require maximum staleness bounds by action class and risk, with fail-closed behavior after the bound for all consequential actions. The worst-case window depends on cache TTL, event-delivery lag, and outage behavior. Cross-domain Mission state federation can accumulate lag across hops. Runtime Enforcement promises bounded staleness, not real-time consistency.

Capability-Source Fragmentation

The Tool Binding Profile relies on a digest over a versioned capability source. No single industry format covers OpenAPI documents, MCP tools/list results, A2A Agent Cards, and proprietary workflow graphs. Their identity and canonicalization rules differ, so a digest over one representation does not prove semantic equivalence with another.

The module therefore defers source format and canonicalization to the deployment. Single-format deployments can apply it now. Cross-vendor deployments need format-specific adapters or a future capability-catalog interoperability profile before drift detection is portable.

Standards Composition

These rows describe what IBAC additionally requires or strengthens beyond the OAuth Profile.

The profile turns credential-bound Mission governance into a runtime authority model: the Mission is a required input to every consequential decision. Current resource policy remains authoritative for the final permit or deny result.

Gaps and Open Issues

☐ Policy-view format. Should a later profile define a portable policy-view format, or leave engine-native artifacts and canonical input bundles deployment-specific?

☐ Capability-source binding. The Optional Tool Binding Profile requires source-identified capability binding but does not standardize source identity, canonicalization, signatures, or version labels across MCP, OpenAPI, and other formats.

☐ PDP selection and trust binding. AuthZEN defines PDP metadata and /.well-known/authzen-configuration. Mission-Bound deployments still need a rule for selecting among multiple PDPs and binding the selected PDP to the resource, tenant, Mission origin, and trust domain.

☐ Policy-version drift across distributed PDPs. When Mission Expansion creates a successor Mission, or when a semantically equivalent compiled artifact is rebuilt after a deployment-policy refresh, distributed PDPs may evaluate against stale versions. The profile requires policy_version on every decision evidence record, but does not specify the propagation mechanism. Composes with CAEP-style change events; the wire shape is unspecified.

☐ Parameter normalization profiles. This profile pins canonical JSON to JCS, but each operation vocabulary still needs rules for default values, omitted fields, and arrays whose semantics are set-like rather than ordered.

☐ Fail-closed semantics during state-authority unavailability. When the Mission state authority is unreachable, the PDP cannot refresh Mission state. The profile requires a published staleness bound and fail-closed behavior for consequential actions after that bound, but interoperable action-class defaults and outage signaling remain open.

☐ Cross-PDP evidence consistency. A multi-PDP deployment produces evidence at each resource domain. Joining records is possible after authorized pairwise Mission-identifier resolution at mission.origin, but a portable schema, canonicalization rule, and event-ordering model are still needed for external verification.

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:

• Reproducible policy materialization over the complete approved Mission tuple, by the state authority or a trusted compiler.
• Mandatory representation of authority-expandable denials via AuthZEN Access Request.
• Local-action policy gate via AuthZEN Access Evaluation for non-OAuth actions.
• Runtime-context contract combining credential validation with Mission Status (policy version, integrity hashes, authenticated actor context, tenant, subject projection, and audience-relevant Authority Set entries).
• Authenticated client or client-instance evaluation on every decision, with act required and evaluated only when delegation is present.
• Per-decision evidence bound to the Mission, authority commitment, policy version, decision, relevant constraints, request, and actor context.
• Parameter binding for consequential writes and higher-risk action classes.

Optional modules can add Tool Binding, Purpose Registry, Actor Provenance, Decision Receipt, Attestation, and Policy Projection. Later profiles can add per-actor revocation and key-compromise lifecycle events without changing the governance or enforcement contracts.

Mission-Bound Authorization becomes IBAC when the Mission is a required input to runtime decisions for consequential actions. Execution continuity comes from evaluating each action against current Mission bounds and resource policy. Decision accountability comes from recording each decision; portable receipts add third-party-verifiable proof where required.

Standards Ask

A focused list of what this post asks of the standards community.

Standardize now (Runtime Enforcement Profile Core):

• Reproducible policy materialization by the state authority or trusted compiler, with policy_version surfaced through authenticated runtime context.
• Resource-Side Enforcement Contract: RS-D required within the claimed scope; PDP evaluates every consequential request against approved bounds covering resource, action, constraints, actor, tenant, time, risk, purpose.
• Standard Subset Semantics per authority type, with refusal on unknown machine-enforceable constraints.
• Runtime Denial and Escalation: AuthZEN Access Request as MUST for authority-expandable denials.
• Mission Status and Runtime Context: credential validation plus state-authority status with policy version, integrity hashes, authenticated actor context, tenant, subject projection, and audience-relevant Authority Set entries.
• Policy Freshness Rules: deployment-published staleness bounds by action class, optionally supported by a current SSF/CAEP subscription; fail closed for consequential actions after the applicable bound.
• 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 1.0, including Access Evaluation and PDP metadata discovery, plus the AuthZEN Access Request draft.
• RFC 7662 introspection extended with Mission state when the credential issuer is also the state authority; Mission Status otherwise.
• A future portable receipt profile; W3C Verifiable Credentials Data Model 2.0 is one candidate envelope.
• Actor Profile and Client Instance Assertion for authenticated actor context and act on delegation paths.
• RFC 9728 PRM, MCP tools/list snapshots, and OpenAPI documents as capability sources.

Defer to optional modules:

• Tool Binding Profile (source identity, signatures, canonicalization, version labels, and media-type negotiation).
• Decision Receipt Profile (portable cryptographic receipts cross-domain).
• Purpose Registry Profile (governed Mission Intent purpose URIs with declared bounds).
• Actor Provenance Profile (keeps act limited to delegation and adds separate tool, workflow_step, approver, and execution_environment fields).
• Attestation Profile (RATS PTV, WIMSE Workload Identity).
• Policy Projection Profile (state-authority-to-PEP/PDP policy-view carriage).

Roadmap

The Runtime Enforcement Profile ships in step with the OAuth Profile and inherits its dependency stack. The ordering below is about runtime-enforcement-specific work that follows the base profile. Each phase is tagged (C) for execution continuity or (A) for decision accountability.

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 OAuth Profile. Composes with AuthZEN Authorization API and AuthZEN Access Request. Delivers both (C) and (A) at the baseline.

Next: Closing the Open Runtime Questions

• Standardized policy-view format (C, A). Today the profile permits Cedar, OpenFGA tuples, canonical input bundles, or another internal representation. A follow-up profile could select a baseline format and define carriage to RS-D audiences.
• Capability-source binding (C, A). Standardize source identity, canonicalization, signature support, version labels, and media-type negotiation across MCP, OpenAPI, and other catalogs.
• PDP selection and trust binding (C). Profile how a PEP uses AuthZEN metadata to select the PDP authorized for a resource, tenant, Mission origin, and trust domain.
• Per-decision audit receipt format (A). Select and define a portable, third-party-verifiable receipt envelope that binds the Mission, policy version, decision, constraints, and authenticated actor context.

Then: Runtime Enforcement and Attestation

• RATS PTV composition (C, A). Bind the credential sender key or authenticated execution context to a Prove-Transform-Verify attested agent identity for high-assurance Mission classes.
• WIMSE Workload Identity composition (A). Attest the execution environment of the orchestrator and sub-agents; the PDP consumes the workload identity alongside the act chain.

Later: Governance Extensions

• Governed Mission Intent purpose registry standardization (C). The optional module does not specify its operator, namespace, or interoperability model. Candidates include an IETF namespace, OpenID Foundation namespace, or industry registry. Cross-organizational use may require registry federation.
• Risk-tier and assurance-level constraint catalog (C, A). Standardize the assurance_level and risk_tier values that governed purpose profiles reference.
• 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 (A). Extend Actor Profile so a PDP can verify the chain end to end rather than only inspect it.
• Cross-AS audit-receipt federation (A). Make receipts from multiple ASes joinable through canonical or origin-resolved pairwise Mission identifiers.
• Real-time policy update propagation (C). When a successor Mission activates or a semantically equivalent compiled artifact changes version, 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 applicable governance profile’s checklist (including the OAuth Profile Implementation Checklist for OAuth deployments) plus the following.

State authority (the AS, PS, or MAS that holds the Mission record; additional under Runtime Enforcement):

• Materializes the complete approved Mission tuple as a reproducible, evaluable policy view. (Mission-to-Policy Materialization)
• Stores or references the policy view with a stable policy_version or fingerprint covering versioned inputs and compiler identity. (Mission-to-Policy Materialization)
• Exposes authenticated Mission Status containing Mission state, integrity hashes, policy_version, and the audience-filtered Authority Set projection. When the state authority also issued the credential, an authenticated issuer endpoint may combine this view with credential introspection; otherwise the two remain separate. (Mission Status and Runtime Context)

PDP (Policy Decision Point):

• Implements AuthZEN Access Evaluation and advertises its endpoint through AuthZEN PDP metadata. (PDP Deployment Modes)
• Evaluates every consequential request against the Mission policy view and current local rules. (Resource-Side Enforcement Contract)
• Refuses when a machine-enforceable constraint in the applicable Authority Set or policy view is unknown. (Standard Subset Semantics by Authority Type)
• Returns denials with an AuthZEN Access Request handle when the denial is in-policy-expandable. (Runtime Denial and Escalation)
• Produces an evidence record for every consequential decision, including Mission binding, integrity hashes, subject, actor context, action, resource, policy version, decision, relevant constraints, request time, parameter or request digest, and any expansion request. (Decision Evidence Records)

Policy Enforcement Point (orchestrator, Resource Server, or execution host):

• Validates the native credential and obtains authenticated Mission status before constructing the AuthZEN request. (Mission Status and Runtime Context)
• Supplies authenticated subject, client or client-instance context, and act only when delegation is present. (Mission Status and Runtime Context)
• Enforces the PDP result at the component that can prevent execution. (Local-Action Boundary)
• For parameter-bound actions, verifies the decision binding, validity window or single-use identifier, and recomputed parameter_digest immediately before execution. (Parameter Binding and TOCTOU Protection)

Resource Server (RS-D required within the Runtime Enforcement claim):

• 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 authenticated client/instance is outside approved bounds or whose act chain, when present, does not match approved delegation. (Actor Context)

Orchestrator:

• When it controls a consequential local action, acts as the PEP and obtains a PDP permit before execution. (Local-Action Boundary)

Optional module implementations (deployment-defined until the follow-on profiles exist):

• Tool Binding: binds each approved action to a source-identified capability, requires the identifier on governed requests, and refuses capability drift.
• Purpose Registry: maintains governed purpose URIs with declared bounds, risk class, escalation rules, display language, and reauthorization cadence.
• Actor Provenance: records tool, workflow step, approver, and execution environment separately from the RFC 8693 act chain.
• Decision Receipt: wraps Core evidence records in portable, verifiable receipts.

Discovery and profile advertisement:

• PDP publishes AuthZEN metadata through /.well-known/authzen-configuration, including its Access Evaluation endpoint.
• Deployment policy binds the selected PDP to the relevant resource, tenant, Mission origin, and trust domain.
• AS metadata advertises Runtime Enforcement Profile compliance via mission_profiles_supported including "runtime_enforcement". (See Gaps.)

References

• AuthZEN Authorization API 1.0: the final specification for PDP queries and metadata discovery.
• 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 capability-source references).
• Mission-Bound OAuth Profile: the underlying profile this one strengthens.