Mission-Bound Runtime Enforcement

Overview

The Mission Is the Missing Abstraction made the Mission a durable, approval-backed governance object, and From a Request to an Approved Mission made the approval that creates it trustworthy. Those layers say what was approved, by whom, for how long, and within what bounds. They govern issuance and derivation. They do not evaluate an individual action at the moment it runs.

That is the gap this part closes. Mission governance makes authority auditable and revocable. Runtime enforcement is what prevents an active Mission from becoming ambient authority. It is the Enforcement step on the spine, and it is the center of gravity for the whole chapter.

A Mission-bound token is as strong as the Resource Server that enforces its bounds. Per-action, parameter-level, and state-aware checks come from runtime enforcement.

This part specifies those checks.

The model is one sentence. Within a declared enforcement scope, before each consequential action a Policy Enforcement Point (PEP) obtains a permit from a Policy Decision Point (PDP) that evaluates the action against the current Mission. Everything else in this part is what that sentence requires to actually hold.

Read that sentence for what the decision point actually holds, because it is easy to hear “central PDP” and picture a rules engine pricing bare actions. The decision evaluates the action in its undertaking. The Mission carries context no resource request ever does: the committed why, the approved shape of the authority, and, because evidence joins on the Mission, what the undertaking has already done. “Delete database” in isolation is indistinguishable from catastrophe. “Delete database, inside an approved migration whose copy steps are already in the Mission’s evidence” is a priced, checkable step. And the richer inputs stay deterministic: the anchors and the evidence trail are committed facts, not runtime inferences about intent, which is the line between this model and the intent-guessing it rejects. The history consulted is also first-party: the deployment’s own record of what its decision points permitted and its enforcement points executed. That is a different thing from the audit layer’s caution that a registered record proves inclusion to an outside verifier rather than occurrence. The PDP trusts its own ledger the way any database trusts its own writes.

And the order in that sentence carries more weight than the mechanism. Approve the bounded work, then authorize every consequential action against that approved boundary. Per-action authorization alone cannot prevent individually permitted steps from composing into an outcome no one approved: five reads and one send, each valid in isolation, can be an exfiltration pipeline. The approved boundary bounds that composition only where its bounds are the right kind: a destination the approval never granted stops the send, and the cumulative bounds and single-use permits of Consumption Metering carry the quantitative case. What survives inside the boundary is the flow-level residual the trifecta section prices: per-action checks are not information-flow control, and the harness taint rule is the mitigation, not this gate.

The gap issuance leaves open

The issuance profile is deliberately an issuance-and-derivation layer. Its own security considerations say so. It does not evaluate individual runtime actions, so an active Mission still bounds a set of authority an agent may exercise freely within a token’s lifetime.

Concretely, after the approval event the agent holds Mission-bound access tokens. Each token carries the mission claim (id, issuer, and optionally expires_at) and a subset of the Authority Set in its authorization_details. A Resource Server validates the token, enforces the carried authorization_details it understands, and serves the request. That is governance, and for the bounds the Resource Server enforces it is also a control. The token is bound to a kill switch, and the Authority Set is the maximum the token can ever claim. But between approval and the token’s natural expiry, nothing re-checks each concrete action against the current Mission. A compromised, drifted, or prompt-injected agent can spend the whole Authority Set, with any parameters the Resource Server’s own checks admit, as fast as it likes, until the token ages out or someone revokes the Mission.

The runtime layer delivers exactly the four things the issuance profile names as out of scope, plus enforcement of the constraints it carries but does not evaluate:

1. evaluation of a request’s parameters against the Mission at the point of use.
2. per-action evidence for every consequential action.
3. binding the invoked tool or function identity to the Mission’s approved authority.
4. execution-time re-evaluation that closes the approval-to-execution gap.

And, additionally, the fail-closed treatment of the consumption bounds a Mission carries (max_budget, max_calls, max_duration, max_egress_volume), whose definition and metering mechanics live in the experimental Mission Consumption Metering companion.

Mission-bound tokens bound what authority may exist. This profile, the Mission-Bound Runtime Enforcement draft, defines where and how that authority is re-checked before consequential effects occur.

The runtime model

A PEP sits at each consequential execution boundary. Before the action runs, it obtains a decision from a PDP that evaluates the action against the Mission the acting token is bound to.

Two roles do the work, and the spec defines them so the boundary is unambiguous:

• The PEP is the component that can prevent a consequential action and that obtains and enforces a decision before the action runs. Depending on the action it is a Resource Server, an MCP server, an egress proxy, a workflow engine, or the orchestrator itself.
• The PDP evaluates the action against the Mission and returns permit or deny. Its placement is a deployment choice: co-located with the Mission Issuer, embedded in the Resource Server, a tenant-scoped service, or a shared service. The profile mandates none of these. It requires only that a PEP at each consequential boundary can reach an applicable PDP.

The runtime decision evaluates six required inputs against the action, plus an optional seventh, and a deny on any one is terminal for that action:

• Authority. The action must fall within two bounds. The first is the credential’s authority under the subset rule: an applicable authorization_details entry the token carries, or one available to the PEP or PDP for that token through introspection. The second is the Mission’s current Effective Authority Set, the approved set less any discharge or containment. The PDP never substitutes the approved set for a credential’s narrower authority. A narrowed Mission stays active, so the PDP learns the effective set within the staleness bound from a source that reports narrowing, not lifecycle state alone. The PEP asserts the capability identity it will invoke, and the PDP refuses an identity outside the approved actions. A catalog-sourced capability is further bound to the digest of its definition recorded at derivation (covered by authority_hash). If a tool definition is later redefined or poisoned, the digests differ and the decision fails closed as capability_drift, under the extraction rule Mission Capability Binding owns.
• Resource policy. A Mission-bound permit is an upper bound on authority, not a command to perform the action. Object-level authorization, tenant configuration, legal holds, service invariants, and risk policy still apply. The action fails closed unless both Mission authority and Resource policy permit it.
• Parameters. Every constraints value on the applicable entry is evaluated against the concrete parameters. A constraint the PDP cannot understand or enforce causes refusal, never silent pass-through.
• Actor. When delegation is in effect, the PDP evaluates the authenticated act chain and refuses one that is missing or malformed (the delegation chain is Mission-Bound Authority). client_id (the client that obtained the token) and the immediate actor (the current actor in act, or that client when there is no chain) are distinct inputs, and the PDP never treats client_id alone as the immediate actor when a chain is present.
• Time. The PDP refuses an expired token. Because the issuance profile caps a derived token’s exp at expires_at, the exp check transitively enforces Mission expiry. The mission claim can also carry an OPTIONAL expires_at member, a bounding commitment with no liveness: it never extends reliance, and current state still comes from a freshness source.
• State. The PDP refuses unless the Mission is active. This is the handbook-wide rule made operational. Only active permits reliance, and every other state, recognized or not, is non-active.
• History (optional). A deployment may evaluate policy predicates over the Mission’s prior Decision and Execution Evidence, for example that a named action class has completed. History is a decision input, never a grant, and a required predicate the PDP cannot establish within its staleness bound fails closed.

This is the move that makes Intent-Based Access Control practical. The PDP is not reconstructing “what did the user want” from a prompt at enforcement time. It is checking a concrete action against an approved, integrity-anchored Authority Set. The interpretation already happened at consent time (The Mission Is the Missing Abstraction). Current resource policy stays authoritative for the final permit or deny.

The model has a price, because the decision is on the hot path by design. Every consequential action buys a policy evaluation, and the contract’s cost controls are the classification and the lease: non-consequential work is never gated, consequential reads take a decision without parameter binding, permits for reversible writes amortize across a validity window, and only the high-consequence classes pay for single-use permits and reverification on every execution. What the family does not yet have is deployment-scale performance data, and this handbook will not invent it. A deployment should publish its measured decision latency next to its staleness bound, and the absence of those numbers across the industry is one more reason walk ships first: they should come from running systems, not from this page. The classification bet names the erosion to watch while they arrive: a mediated class list that shrinks release over release while the claim name holds.

Which actions are consequential

The PDP gate is not for every action. Reasoning steps and cache reads have no external visibility and need not be gated. The boundary between consequential and non-consequential is deployment policy. But a deployment must not draw it so loosely that nothing is enforced. The profile defines a default classification a deployment SHOULD adopt, and a floor it MUST observe.

The bottom three rows are the high-consequence classes, where a token-lifetime-wide standing authority is least appropriate and the profile’s strictest requirements attach (action-bound approval, mediated custody, active-state freshness, execution-outcome evidence, all below).

One property cuts across the classes. An external-communication action is a consequential action of any class whose effect carries data to a recipient outside the deployment’s trust boundary: sending a message or mail, posting to an external service, publishing. It names the egress property, not a further class. The action keeps its class and that class’s requirements, and the rules stated over external-communication actions (the taint rule, trifecta containment, egress metering) apply to every action that has the property.

Two guardrails keep classification honest. A Mission’s purpose, or deployment policy, MAY raise an action to a stricter class. A financial-settlement purpose may treat a write as an external commitment. It MUST NOT lower an action below the resource owner’s minimum, and MUST NOT classify an irreversible, external-commitment, or privileged-administration action as non-consequential. A deployment cannot evade enforcement by relabeling a high-consequence action as harmless.

The classes are floors drawn from several consequence dimensions, reversibility, exposure, privilege, commitment, and value, with policy taking the maximum across them, because a read of regulated data is irreversible in the only sense that matters once it leaves. And the same operation can cross classes on its parameters: creating a ten-dollar draft is not releasing a million-dollar transfer.

The table’s gate column applies within the declared runtime-enforcement scope. Outside it, an issuance-gated path claims its published worst-case credential-lifetime bound, including the age of any observation used to mint the credential, and a path outside Mission enforcement gains no Mission revocation guarantee (not every resource checks Mission state). Classification is deployment policy above the floor, with one exception for reads: a read already fully constrained by the token’s audience and resource and the Resource Server’s object-level authorization, with no material effect on the resource set or disclosure risk, need not be classed a consequential read, so the profile does not require every read to reach a PDP. The exception concerns classification only; writes and higher classes are gated as the table requires. Neither classification nor a scope exclusion supports a claim for enforcement the path does not provide.

Where the enforcement point sits

The strongest decision logic is void if the PEP is in the wrong place. The same Mission, PDP, and policy view all fail if the permit is checked somewhere the action can route around. The rules are blunt:

• The PEP MUST be at the last controllable boundary before the action. A permit checked further upstream does not survive parameter changes, retries, or routing that happen after the check.
• A token-issuance decision does not replace execution-time authorization. A token-only Resource Server cannot claim runtime enforcement. The issuance gate is governance. The runtime gate is enforcement.
• A tool-catalog filter does not replace per-call authorization. Filtering a tools/list by the caller’s authority is exposure control. Every consequential tools/call still passes the runtime gate.
• An orchestrator’s internal check does not replace a Resource Server’s PEP. Defense in depth is permitted. Substitution is not.
• If no PEP can prevent the action for a class, the deployment MUST NOT claim runtime enforcement for that class, and must name the classes and execution paths it does mediate.

That last rule is why the profile’s conformance is scoped, not global. A deployment conforms only for the resources, action classes, execution paths, and authorization-detail types named in its enforcement scope. An OAuth-protected API call is gated at the Resource Server, a consequential MCP tools/call at the MCP server, a local file write or payment at the orchestrator, external egress at an egress proxy. Where an action can be reached by an unmediated path (a debug shell, an unsanctioned egress route, a direct connector), the profile is simply not enforced for the classes that path reaches, and the claim must say so.

The claim, as a surface a deployment would actually publish:

The parts worth copying are the first-class exclusions, the token-lifetime bounds on issuance-gated classes rather than a pretense of mediation, and the verification suite. One vocabulary note: the mock’s enforcement levels are this deployment’s own declared strength scale, not the Mission Assurance Levels.

The deployment question underneath is what can be centralized and what must live at each boundary. The PDP centralizes: one decision service (or a small fleet) serves every PEP. The PEPs cannot, because a permit is only as good as its placement:

A real deployment mixes rows, and the enforcement-scope statement records which rows it actually runs.

Closing the TOCTOU gap with parameter binding

A permit for an operation does not authorize arbitrary parameter values. If the PDP permits “write to the ledger” and the agent then changes the amount, the permit must not still hold. This is the time-of-check-to-time-of-use (TOCTOU) gap, and parameter binding closes it.

For consequential writes and the high-consequence classes, the PDP binds its permit to the normalized action parameters through a parameter_digest: the SHA-256 of the RFC 8785 JCS serialization of the normalized parameter object, in the issuance profile’s encoded form. The permit also binds the Mission reference, the token issuer when available, the token audience, sub, client_id, actor context, sender-constraint key, action, resource, the authorizing entry (or an entry digest), the policy-view version, and a tight lifetime control.

The executing PEP, not an upstream component, recomputes the digest against the parameters it is about to use, immediately before acting, and verifies every binding. A mismatch refuses. The permit does not authorize the changed parameters. Two consequences follow:

• A permit cannot be replayed for a different request, because the digest mismatches.
• A permit cannot be reused across boundaries. Bound to a specific audience, resource, tenant, and operation, a decision for one is not reusable at another, which is the confused-deputy defense.

What the PEP checks, and how. The AuthZEN permit echoes only the bindings the PEP enforces at each use: the parameter_digest it recomputes; valid_until, never later than the credential’s expiry, the approval’s approved_until, the state’s valid-through time, or the policy maximum; use_limit, whose consumed-identifier store the PEP keeps; the evaluation-context digest, where Evaluation-Context Binding is claimed; and the action phase, where the operation is a phase of a compound action. A condition the PEP does not recognize invalidates the permit. The other bindings (issuer, audience, sub, client_id, actor, key, entry, and policy view) are not echoed. They hold because the PEP built the request from its own validated credential context, and the requester and the executor must be the same enforcement identity on one mutually authenticated channel: a permit is never relayed to another component as a bearer grant, and a cached permit does not serve a request whose cache key differs. The PDP records the authorizing entry or its digest, the policy view, the audience, and, where it tracks one, the state version in Decision Evidence, for audit rather than for the PEP to compare. The drafts specify no field-by-field comparison for the bindings the permit does not echo.

The lifetime control scales with risk. A reversible write may use a single-use decision identifier or a short window plus an idempotency key. An irreversible action, external commitment, or privileged administration MUST use a single-use decision identifier (a validity window alone does not bound how many times such a permit executes), and consumed identifiers are recorded so any second presentation fails closed. A single-use identifier bounds executions of one permit, not permits for one action, so for a non-idempotent operation in these classes the Operation Profile MUST also define an idempotency key, which identifies one intended execution of one normalized request. The PDP claims the key atomically before it permits. A repeat under the same key and the same operation is duplicate_suppressed: transient while the first outcome is unresolved, terminal once it has completed, with the prior result served by the resource rather than executed again. The same key with a different operation is a terminal idempotency_conflict. An intentional re-execution is a new operation under a new key, which an action-bound approval can authorize as such. The claim needs an exact store (a single serializing PDP or a linearizable shared store), so a deployment whose replicas only converge within a bound cannot make it. And these classes MUST carry an execution lease or a published maximum execution duration, so run-to-completion is bounded too. Idempotency support, reversibility, and the lease an operation needs are resource-declared semantics, stated in the Operation Profile the deployment publishes for each operation so the PDP does not guess. The same profiles mark compound actions: an action that crosses more than one boundary (reserve then commit, draft then send) obtains its own Decision for each consequential phase, each permit binds its phase, and a prepare-phase permit never releases a commit.

The Operation Profile. Normalization is the Operation Profile’s job, so that two implementers of one operation bind the same bytes. The digest is computed directly over the normalized parameter object, with no envelope, under the issuance profile’s canonicalization rules: duplicate members rejected, array order significant, and URIs compared byte for byte. The runtime profile requires each Operation Profile to fix:

A deployment that leaves any of these unstated has not specified that operation’s binding. The drafts define no wire format or registry for Operation Profiles, and they set no unit rule beyond keeping unit and currency conversion out of constraint mappings.

Two limits bound what the digest can promise. The binding is only as strong as canonicalization: where a resource resolves material semantics after receipt, the descriptor the PEP hashes is not the descriptor the resource executes, and the binding is to a phrasing rather than an action. And a single-use identifier guarantees single consumption, not single effect. The repair for both moves the binding to the effect: a resource-prepared descriptor authorized and committed exactly once, or a mediating handler that is the transaction’s system of record.

Consequential reads do not require a digest by default. But a binding floor applies. A read whose parameters select a cross-tenant or cross-audience scope, request a bulk or export-like result, or choose the returned fields or destination MUST bind those parameters. An export is not an ordinary read.

The running example. Take the handbook’s running example, the Prepare the Q3 board packet Mission. A query_financials read against finance.example.com is a consequential read. The PDP permits it against the live Mission, no digest required. A notify_reviewer send against workflow.example.com is consequential and externally visible, so its permit is bound to the concrete recipient, the audit-committee group named in the entry’s constraints. Ask to notify a target outside audit-committee and the action is outside the Authority Set’s constraint. The PDP refuses (parameter_violation) and the PEP fails closed. The interpretation happened at consent time. The gate only checks the concrete action against it.

Metering, and fail-closed on everything else

A Mission can carry cumulative consumption bounds (max_budget, max_calls, max_duration, max_egress_volume), and the issuance layer cannot enforce them because it counts derivations, not actions. The bounds and their metering mechanics are defined by the experimental Mission Consumption Metering companion, while the runtime profile keeps the fail-closed posture: an unknown or unmetered bound on an applicable entry refuses. Under the companion, for each consequential action the PDP performs an atomic reserve-or-charge against the remaining balance, increments the named call counter, or accumulates duration, and refuses when a bound would be exceeded.

Metering is a two-phase exchange, not a single decision-time act. For an action of unknown length the PDP reserves a bounded maximum or issues a duration lease, and after execution the PEP reports the measured outcome so the PDP can commit actual use and release the unused reservation. The Execution Evidence record (below) is that commit-or-release signal, keyed to the permit’s evaluation_id. For irreversible actions and external commitments, a deployment must define whether metering is reserved before execution and committed after success, or committed up front. The hardest moment in the exchange is not the check but the timeout after it, when the permit is spent, the resource has not answered, and committedness is unknowable. Evidence records that outcome as unknown rather than guessed, and the unknown has an owner: a named reconciliation against resource state with a deadline, because an unknown nobody owns becomes a committed effect nobody recorded. Reconciliation can resolve an unknown to committed or failed. What it can never do is admit a new effect under a Mission that has since gone non-active.

The topology is part of the claim. Under a single serializing PDP the check-and-decrement is atomic and the bound is exact. Under distributed PDPs an exact global counter is a distributed-counting problem. Such a deployment must publish the consistency bound it actually operates under (per-PDP sub-budgets, a bounded reconciliation window) and must not advertise exactness it cannot meet. Cumulative-bounds enforcement is a newer model, which is why the companion is experimental, with short expiries and per-action constraint checks as the path to start with.

Enforcement is only meaningful if failure is bounded, so the spec fixes the failure behavior. The pattern is uniform. For consequential actions, when the answer is in doubt, refuse. The rows below are the decisive excerpt. The draft’s failure-mode table is longer (a missing mission claim, an unsupported authorization-detail type, an out-of-authority capability identity, and a Resource policy refusal all refuse the same way).

parameter_digest closes the gap between decision and execution for the request’s own fields, and it cannot freeze the target: a document can be revised, a record reclassified, a query can return a different set by the time the action lands. For high-consequence classes, treat that as a named residual unless the deployment claims the extension below. The permit’s tight lifetime is the bound, a retry re-evaluates rather than replaying a stale permit, and where the resource exposes versions or content digests, bind them as request parameters so the parameter_digest carries them. The runtime core also defines an optional Named Assurance Extension, Evaluation-Context Binding, claimed per mediated class: the Operation Profile declares which resource-resolved facts a decision depends on (a revision, or the enumerated resolved values), the PEP captures them from their authoritative source and commits them in an evaluation_context_digest the permit returns as a condition, and the executing PEP re-resolves and recompares them in the same step as the parameter_digest check. A mismatch suppresses the effect and is recorded as target_drift. A reread and comparison earns the extension’s verified property; the enforced property needs the resource to compare atomically with the effect.

Every refusal, and every permit, produces a runtime evidence record sufficient to reconstruct which path produced it.

Fail-closed and active freshness

The “Mission not active” row above carries the most weight, and it has a subtlety the high-consequence classes turn into a hard requirement. A token alone cannot tell the PDP the Mission’s current state. The token was minted at approval time. So the deployment must define a Mission state source it trusts, and the PDP must refuse a consequential action when it cannot establish, within a published staleness bound, that the Mission is active.

A permit is a lease, not a standing grant. Token TTL, cached Mission status, and policy views are all leases on Mission authority, each valid for a bounded window before it must be refreshed against the state source or fail closed. The staleness bound each enforcement scope publishes carries a latency consequence it must publish with it: for a PDP-gated class, a revocation takes effect, worst case, after the staleness bound plus the permit validity window plus the class’s execution bound. For a path outside PDP gating, the bound is the token lifetime where the token’s minting checked current Mission state, and otherwise the token lifetime plus the age of the state observation it was minted from.

The TTL-only end of that dial is a first-class posture, not a fallback. A path that relies on lifetimes alone verifies with local cryptography and a clock, with no state source to couple to and a worst-case exposure equal to the lifetime by construction. What a lifetime cannot do is suspend, complete, or kill now. The two ends are one mechanism read from opposite sides, because a lifetime relocates the freshness check from the verification path to the issuance path.

Read that as a dial, not a doctrine, because most estates will start at the coarse end and should be met there. Short-lived tokens minted under state-gated issuance are a legitimate setting for the classes below high-consequence: the resource validates tokens exactly as it does today, no PDP call, no Mission awareness, and revocation still reaches it within the token lifetime where every issuance, refresh, and exchange path checks Mission state when it mints. A token minted from an earlier observation, such as a grant redeemed later, adds that observation’s age to its lifetime. A legacy resource that will never evaluate Mission state is served that way, or fronted by a gateway or MCP PEP that carries the per-action check on its behalf. The Reference’s revocation matrix prices every setting on the dial, and Adopting carries the deployment shapes. What the dial never permits is pretending: the high-consequence classes require an active freshness mechanism, and a path whose only bound is token lifetime claims exactly that bound, in writing.

For the high-consequence classes the spec is categorical. The state source MUST be an active freshness mechanism that can reflect a revocation within the staleness bound, queried or pushed independently of the token’s own lifetime. On the OAuth 2.0 profile that is token introspection at the Mission issuer, the Mission Status surface, a Mission Status List whose Status List Token TTL is within the staleness bound (the pull floor for consumers relying on many Missions at once), or Lifecycle Signals (Mission Lifecycle and Change). It must also report any discharge or containment narrowing.

Token-lifetime expiry alone is not an acceptable state source for the high-consequence classes. It bounds staleness only by the token lifetime, so a revoked Mission keeps deriving consequence until tokens age out. That is precisely the ambient-authority gap this profile exists to close.

The runtime draft recommends a default freshness posture per class, adopted absent a documented, consequence-specific analysis:

A deployment justifies any looser value for a high-consequence class in its enforcement-scope statement. These are targets for the freshness of the state a decision reads; the worst-case revocation bound adds the permit and execution windows above. The reference target the drafts repository builds first configures 300 seconds for reads and writes, 60 for external commitments, and 30 for irreversible actions and privileged administration (its deployment record).

This is where the handbook-wide rule “only active permits reliance” stops being a governance statement and becomes a wire requirement. A suspended or revoked Mission produces a runtime denial regardless of policy, and for the actions that matter most, the deployment must be able to learn the revocation fast enough to act on it.

Where the PDP gets the narrowed set. The PDP may evaluate a materialized policy view or the Mission’s recorded authority, but mutable state, including every narrowing of the Effective Authority Set, comes from a state source within the staleness bound, never from that representation. A source that reports only lifecycle state does not qualify, because a narrowed Mission stays active. On the OAuth 2.0 profile the qualifying sources are full Mission Status or introspection carrying containment_version, and Lifecycle Signals carrying the overlay change. A Status request that names an audience returns the entries relevant to that audience after every narrowing. One that omits it is state-only, which is all the harness needs at 02:00 and not enough for a PDP evaluating authority. The AuthZEN profile defines no member that carries the evaluated set.

The high-assurance level

Everything above bounds what any agent can do. The high-assurance level raises the bar for a compromised agent, one that has been prompt-injected or taken over but still presents correct credentials. The issuance and runtime gates do not make the agent trustworthy. They bound what it can do. This level shrinks that bound further by not letting the agent hold the authority whose misuse is unacceptable, and by requiring a fresh independent approval for the highest-consequence acts.

Mediated custody. For any class a deployment mediates, and for every high-consequence class, the acting credential must be sender-constrained, so that only the holder of the private key its cnf binds can present it. For the mediated classes, the PEP holds the sender-constraint private key, not the agent. The agent cannot present the credential directly. To act, it asks the mediating PEP, which runs the decision and only then uses the key. No new token type or wire protocol, just a custody-and-placement property of the existing key. The token is unchanged, the agent remains the principal of record (client_id still attributes the action), and no act entry is added. Two properties follow: a credential exfiltrated from a compromised agent is unusable without the key, and a compromised agent cannot reach a mediated action without passing the per-action check, because it never holds a usable credential for that class. This depends on the agent having no unmediated path to the resource, which the agent harness establishes (The Agent Runtime and Audit).

The drafts do not specify which component makes the token request. In one shape they describe, the PEP is itself the attested instance that obtained the token, with the key generated in the PEP or its HSM, and the declared path scope leaves the agent no token, refresh, or exchange path to a usable credential of its own.

Action-bound approval. The Mission’s approval event consents to the task and its authority bound. It does not consent to a specific action’s concrete parameters. For the high-consequence classes a deployment can require a second, action-bound approval (and an Authority Set entry can demand it through the requires_action_approval Common Constraint the Resource Access Profile defines): a fresh approval bound to the concrete action and parameters the PEP is about to permit, obtained from an independent approver, never self-issued by the agent. Because it is bound to the parameters, it is reverified under the same TOCTOU rules. A parameter change after approval invalidates it. It carries a maximum age the deployment publishes, and may carry an absolute approved_until; past the earlier of the two it is stale and the PEP refuses. The surface that resolves it must not be invocable from the agent’s tool plane or any channel the agent drives: the agent may observe an approval’s state and request one, but never resolve one. The runtime core leaves the workflow that obtains the approval to bindings: the AuthZEN profile composes with ARAP, and the experimental Mission Transaction Authorization profile defines a cross-domain workflow whose transaction token is restricted to its one recorded transaction. However obtained, the approval is decision input, not a bearer grant. The runtime decision stays authoritative, and persisting authority beyond the single action is a Mission Expansion (Mission Lifecycle and Change), not a property of the approval.

“Protects against agent compromise” is a verifiable claim, not a label. A deployment claims agent-compromise-resistant enforcement only when, for the high-consequence classes, four conditions hold:

1. The sender-constraint key is generated and held in the mediating PEP or its HSM, never transferred from the agent. Gateway custody is the shape that realizes this today.
2. Each such action requires an action-bound approval.
3. The disclosure the approver decides on is rendered from the bound parameters by a component isolated from the agent, never composed by the agent.
4. The state source is an active freshness mechanism.

The claim’s fifth term is the path scope: governed work has no unmediated path to the mediated classes, and no token, refresh, or exchange path by which the agent obtains a fresh usable credential for them under a key it controls. No protocol can verify that term, so the deployment declares it in its Enforcement Scope Statement and audits it, with negative tests as the observable check. Each condition is also bound to named evidence: Entity Attestation Tokens for key custody, the isolation boundary, and the measured workload, and signed configuration, service evidence, or audit for the rest, with the scope statement itself attested.

Active freshness is already a MUST in the base profile for these classes. Mediated custody and action-bound approval are the claim’s upgrades from SHOULD to MUST, and the agent-isolated approval rendering is stated only by this claim, so a deployment that skips any of them, or leaves the path scope undeclared, may still claim base runtime conformance, but not this.

What sits outside the agent’s reach. Every guarantee in this part bounds what an untrusted agent can achieve, so each holds only while certain components stay out of the agent’s control. The family’s security model names that trusted base and how each component’s compromise degrades the guarantees. The components this part relies on are:

• the Authorization Server (the Mission Issuer), which derives authority, gates issuance, and is the root of trust;
• the PDP and every PEP, including the mediating PEP that holds the sender-constraint key;
• the Mission state source;
• the harness, which keeps governed work off unmediated paths and enforces the taint rule;
• the consent rendering layer, which shows the Approver what is being approved;
• the access-request and approval workflow, wherever requestable denials or action-bound approvals are used;
• metering state, where consumption metering is used.

The action class comes from resource policy, an operation profile, or a reviewed workflow, never from the agent’s plan. An agent that can reach any of these can move its own bounds.

The decision contract and its AuthZEN profile

The runtime core specifies enforcement invariants, not a wire protocol. It deliberately does not standardize a PDP decision API, an enforcement-scope discovery format, or a Mission Status endpoint. It defines the Mission Receipt, the portable projection of runtime evidence about a material action taken under a Mission, only by its name and minimum binding. It defines what a deployment MUST satisfy when it claims runtime Mission enforcement.

That keeps the contract substrate-independent. But it means two conforming deployments do not thereby interoperate at the PEP–PDP boundary. Three companion documents supply the rest. The OAuth 2.0 profile maps validated token claims and introspection results onto the runtime inputs, names the OAuth mechanisms that observe Mission state, and lets a protected resource publish its classification floors in its metadata. Mission Runtime Evidence defines the records: the Decision Evidence Object, the Execution Evidence Object, the Refusal Record, and the Mission Receipt, so every decision-API binding emits the same ones. And the AuthZEN Profile binds the decision contract to the OpenID AuthZEN Authorization API, as a Decision Base plus six optional feature profiles (Transaction Assurance, Runtime Evidence, Obligations, ARAP, History, and Batch). A deployment using the OAuth profile does not need AuthZEN; the decision API is a separate choice. The division of labor is strict:

The runtime core owns the enforcement semantics. The AuthZEN profile binds the contract to a wire. It does not restate the semantics. It carries only the binding deltas.

Those deltas are:

• Mapping the inputs onto the AuthZEN envelope. The Mission reference, actor, and credential ride in AuthZEN’s context object as context.mission, context.actor, and context.credential, and a PEP-supplied state observation rides as context.mission_state_observation (state, mode, and freshness_at). The normalized parameters and their digest ride as action.properties.parameters and action.properties.parameter_digest, with an idempotency_key where required. The audience rides as resource.properties.audience. The approved entry’s resource URI is matched against that audience, not against the AuthZEN resource object’s type and id, which carry the finer-grained object identity used only for resource-policy evaluation.
• Permits that carry their binding. A permit returns an evaluation_id and its decision conditions: the parameter_digest it is bound to, a valid_until that never outlives the credential, the approval, or the state observation, and use_limit: 1 for the high-consequence classes.
• Three evidence records. The AuthZEN profile’s Runtime Evidence feature profile says which response members flow into the records Mission Runtime Evidence defines. Decision Evidence is emitted by the PDP: what it evaluated, integrity-protected with a jws-compact envelope, and chained back to the Mission by its id and issuer plus either the PDP’s policy_view_id or, for a PDP that evaluates the Mission’s recorded authority directly, authority_hash with the PDP’s own pdp_policy_version. Neither anchor rides on the mission claim, so a PDP records intent_hash only where it has direct Mission-record access. Execution Evidence is emitted by the PEP after the outcome is known, linked by evaluation_id, recording whether the permitted action completed, failed, or was suppressed. The Refusal Record covers a refusal that happens before any PDP decision. Decision (and refusal) evidence is required for every consequential action. The matching Execution Evidence record is a MUST for the high-consequence classes, where it is the basis for one-to-one reconciliation against the permit, and for any duration-metered action, where its measured_duration settles the reservation. Decision Evidence is not proof an action occurred. An auditor must treat orphaned Decision Evidence (a permit with no matching Execution Evidence inside the deployment’s published reconciliation window) as undetermined-outcome or, per deployment policy, as action-attempted, and never as proof of action.
• Carrying denials in an AuthZEN decision. A runtime denial is a successful evaluation, so it is decision: false with a context.reason (out_of_authority, mission_inactive, stale_state, parameter_violation, quota_exceeded, duplicate_suppressed, and the rest), not a transport error, and Decision Evidence records the same value as its denial_reason. The set is extensible by specification, and a consumer treats any value it does not recognize as a deny: capability_drift is one such extension, registered by Mission Capability Binding. A denial can carry a next_action of retry, request, or none. An out_of_authority or approval_required denial MAY be marked requestable with a context.access_request, composing with the AuthZEN working group’s Access Request and Approval Profile (ARAP) so the agent can start narrow and request the authority it discovers it needs. If granted durably, that becomes a Mission Expansion (Mission Lifecycle and Change). A tool or resource an agent discovers mid-task thus arrives as a requestable denial, the start of the discovery loop rather than the end of the task.

The lethal trifecta at execution time

The handbook treats the agent lethal trifecta (private-data access, untrusted-content ingestion, and external-write authority in one loop) as a first-order design constraint, and this section is its canonical treatment at the wire (Splitting the Lethal Trifecta, in the fourth chapter, carries the whole story against the threat model in one place). The governance layers give the common object: the approved task, its bounds, its derivation gate, its audit binding. That is necessary but not sufficient. The runtime layer is what keeps the bundle split at execution time: private reads, untrusted inputs, and external writes stay separately typed, separately evaluated, and separately auditable under the same canonical Mission.

The defense against the dangerous leg (exfiltration) is architectural, not a claim that the agent is injection-proof. External communication is a consequential action, so every attempt is checked against the Authority Set, bound to parameters, metered, and (under mediated custody) made unreachable to an agent that does not hold the egress credential. The injected agent cannot widen the authority the gate checks against.

The profile names two limits. First, the defense is exactly as strong as PEP-placement completeness. Every channel an agent runtime offers (DNS, logs, error strings, a write another process reads) must be mediated, and the profile gates the channels routed through a PEP but cannot prove a deployment enumerated them all. Second, it provides no information-flow control. Each action is evaluated in isolation, so a sequence of individually-authorized steps can compose into an exfiltration no single check catches. A coarse session-level mitigation (downgrading egress authority once untrusted content has entered a session) lives at the harness layer, and raises the bar without being information-flow control. The profile names the composite as a claim: trifecta containment holds only when least exposure is applied, the harness taint rule is enforced rather than advisory (under its default-taint polarity, a parameter in a tainted session that cannot be affirmatively traced to a trusted source stays tainted, so paraphrase sheds nothing), and the external-communication and external-commitment actions are fully mediated, with the egress channels enumerated. Like the agent-compromise claim, it requires execution-environment attestation of the Enforcement Scope Statement. Where the decision binding carries taint context, the PDP enforces the rule and fails closed when the context is missing. The generalization of that discipline, bounding what the agent may see as deliberately as what it may do, is Least Exposure Is Broader Than Least Privilege.

The same discipline applies to the structural-versus-semantic line. Everything this profile enforces is structural: typed actions, bound parameters, metered consumption, current state. None of it can judge whether an in-bounds email body leaks intellectual property. A deployment that wants semantic evaluation in the loop has a place to put it: the decision contract’s context carries deployment-defined inputs, so DLP verdicts, content classifications, or an LLM judge’s assessment of whether an action’s content fits the Mission can ride into the PDP alongside the structural checks. The profile fixes how one composes: the verdict enters the decision as Resource policy and only ever narrows, and its rubric is the recorded Mission Intent, verifiable against intent_hash, not a free-floating policy. The bill is real: content evaluation runs per action, and a judge model reading attacker-influenced content is itself a prompt-injection surface. The structural floor is what the profile can promise deterministically. Semantic controls layer above it at the deployment’s option, raise the bar, and inherit none of its determinism, which is why the classes where content is the harm belong under action-bound approval rather than under a smarter policy engine.

One tension in that assignment deserves its own paragraph, because two of this handbook’s commitments collide on it. For an agent whose primary job is external communication, routing the content-harm classes through action-bound approval degenerates to human-per-send, the exact posture the fatigue budget rejects as a security boundary. What the model actually offers that agent is narrower structure, not more approvals: recipients and destinations bound at admission so the structural check carries the volume, the taint downgrade for the sessions that touched untrusted content, content verdicts composing as narrowing inputs, and action-bound approval spent only where content is the harm and the volume is low. One caveat rides with the recipient bound: an entry naming audit-committee binds the group’s identity, not its membership, and membership is state another system owns. A deployment that pins enumerated recipients at derivation for its high-consequence classes buys the bound it thinks it has. One that resolves the group at send time should say so in its enforcement-scope statement, because the residual is real.

Why this is the center of gravity

Read the handbook and you will find more posts about the governance envelope than about runtime. That is not a statement of priority. The governance envelope projects onto many wire surfaces (issuance, consent evidence, status, signals, expansion, delegation, audit), so it takes more pages. The runtime contract is comparatively compact: one set of invariants in the runtime core, an OAuth 2.0 profile for its inputs, one decision-API binding, and one family of evidence records. Page count is the wrong axis to read priority from.

For any deployment whose agents make parameter-bound writes, act on bounds finer than the receiving Resource Server enforces, or take external side effects, the runtime layer does the safety work the governance envelope cannot.

Where nothing enforces a Mission’s bounds at the point of use, the Mission is only an audit trail. The other five layers exist to make this one trustworthy, and the next section names what each contributes. Take any one away and the runtime gate gets weaker. That is what it means to be the center of gravity.

Where this sits in the handbook

This is the Enforcement step. The concrete answer is four drafts: the runtime core (the invariants), its OAuth 2.0 Profile (the token-to-input mapping), the AuthZEN Profile (the decision-API binding), and Mission Runtime Evidence (the records).

• The Mission (the architecture chapter). The durable approved task and Authority Set the PDP evaluates against.
• Part 1: From a request to an approved Mission. Approval-time integrity: the consent that anchors what the PDP enforces.
• Part 2: Mission-bound authority. The instance identity and act chain the runtime actor check consumes.
• Part 4: Lifecycle and change. Status, signals, and expansion: the active freshness source and the durable home for an approved escalation.
• Part 5: The agent runtime and audit. The mediated execution environment this layer relies on, and tamper-evident evidence.

Least-Privilege MCP Tool Calls Need a Mission walks this enforcement boundary at the MCP tool-call layer.

If you adopt one part beyond the issuance profile, adopt this one. Containment is where the other four laws become enforceable, and the permit is where the handbook’s whole argument cashes out: not that the Mission exists, but that every consequential action still belongs to it.