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. The other five layers exist to make this one trustworthy.

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

That sentence is the handbook’s hardest claim, and this part is where it is enforced rather than asserted.

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.

The gap issuance leaves open

The issuance core 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, authority_hash) and an Authority Set in its authorization_details. A Resource Server validates the token, checks audience and scope, and serves the request. That is governance. 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. A compromised, drifted, or prompt-injected agent can spend the whole Authority Set, with whatever parameters it likes, 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), 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 inputs against the action, and a deny on any one is terminal for that action:

• Authority. The action’s resource and invoked tool identity must be within an applicable authorization_details entry the token carries, or that is otherwise available to the PEP or PDP for that token under the issuance profile (through introspection, when the authority is not inline), under the subset rule. The PEP asserts the capability identity it will invoke. The PDP refuses an identity outside the approved actions. A catalog-sourced capability is further bound to the source-content digest recorded at derivation (covered by authority_hash). If a tool definition is later redefined or poisoned, the current source digest differs from the recorded one and the decision fails closed as capability_drift.
• 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).
• 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.
• 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.

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.

Price the model honestly, 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 the protocol MVP is the wedge: they should come from running systems, not from this page.

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

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.

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 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: the gateway and MCP host give broad coverage cheaply, the Resource Server rows give depth where the objects live, the harness row covers what only the runtime can see, and the broker row exists for the classes where agent compromise is the threat model. The enforcement-scope statement is the honest record of which rows a deployment 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.

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 deployment MUST also define an idempotency key: a re-permit of the same normalized action under the same key is refused, or routed to a fresh action-bound approval, while the prior outcome is unresolved or completed. And these classes MUST carry an execution lease or a published maximum execution duration, so run-to-completion is bounded too.

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), 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 decision_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.

Honesty about the topology is required. 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 stable path.

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

The permit binds the request, not the world. 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. 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. Committing resource version, policy version, and decision time in the permit itself is a candidate for the high-assurance end of what the community still has to standardize.

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. Token lifetime is the bound only for paths outside PDP gating.

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, because a non-active Mission derives and refreshes nothing. 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: issuer token introspection or the Mission Status surface as the fail-closed source, with Lifecycle Signals as push acceleration that falls back to polling when the stream goes quiet (Mission Lifecycle and Change).

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.

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.

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. Mission-bound tokens are sender-constrained. Whoever holds the private key the token’s cnf binds can present the token. Mediated execution uses this. For the classes a deployment mediates, 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).

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: 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 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, all five hold:

1. The sender-constraint key sits in the mediating PEP.
2. Governed work runs under a conforming harness whose published execution-environment scope statement covers the mediated classes, so there is no unmediated path.
3. Each such action requires an action-bound approval.
4. The disclosure the approver decides on is rendered from the bound parameters by a component isolated from the agent, never composed by the agent.
5. The state source is an active freshness mechanism.

Active freshness is already a MUST in the base profile for these classes, and the harness condition makes its no-unmediated-path rule a MUST. 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 may still claim base runtime conformance, but not this.

The decision contract and its AuthZEN binding

The runtime profile 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, and it defines the Mission Receipt, the portable per-action evidence of a material action taken under a Mission, only by its name and minimum binding, deferring the portable schema. It defines what a deployment MUST satisfy when it claims runtime Mission enforcement, and nothing about the bytes on the PEP–PDP wire.

That keeps the contract substrate-independent. But it means two conforming deployments do not thereby interoperate at the PEP–PDP boundary. The interoperable wire surface is supplied by a separate document. The AuthZEN Profile binds the abstract contract to the OpenID AuthZEN Authorization API. The division of labor is strict and worth stating plainly:

The runtime profile 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, actor, credential, parameters, audience, and freshness ride in AuthZEN’s open-ended context object as context.mission, context.actor, and so on. A subtlety the profile is careful about: the approved entry’s resource (the audience URI) is matched against context.audience, not against AuthZEN’s own resource member, which carries the finer-grained object identity used only for resource-policy evaluation.
• Two concrete evidence objects. The runtime profile requires per-action evidence. The AuthZEN profile gives it a shape. Decision Evidence is emitted by the PDP: what it evaluated, integrity-protected with a jws-compact envelope, chained back to the Mission via authority_hash (and intent_hash only when the PDP has direct Mission-record access). The intent_hash rides in neither the mission claim nor introspection, so most deployments anchor on authority_hash alone. Execution Evidence is emitted by the PEP after the outcome is known, linked by decision_id, recording whether the permitted action was attempted, completed, failed, or suppressed. 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 is the settlement input that commits actual use and releases the reservation. The split matters. 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 denial_reason from a closed set (out_of_authority, mission_inactive, stale_state, parameter_violation, quota_exceeded, capability_drift, and the rest), not a transport error. An out_of_authority or action_approval_required denial MAY be marked requestable, composing with the AuthZEN Access Request and Approval Profile 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). For an agent in an open world, this is the front door: a tool or resource discovered mid-task arrives as a requestable denial, the beginning of the discovery loop, not the end of the task.

Bringing the binding in this way is the point. The runtime profile is the architecture, the AuthZEN profile is the interoperability layer, and neither duplicates the other.

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 validation 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 is honest about 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 classes are fully mediated, with the egress channels enumerated. 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 honesty 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. Price that honestly. Content evaluation runs per action at runtime cost, 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.

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 PDP interface, one evidence shape, one set of invariants. Page count is the wrong axis to read priority from.

For any deployment whose agents touch consequential writes or external side effects, the runtime layer is doing the load-bearing safety work, not the governance envelope.

A Mission you cannot enforce at the point of use is an audit trail, not a control. The other five layers exist to make this one trustworthy. The Mission Is the Missing Abstraction gives the durable approved task the PDP evaluates against. From a Request to an Approved Mission makes the approval that anchors it trustworthy. Mission-Bound Authority gives the instance identity and act chain the actor check evaluates. Mission Lifecycle and Change gives the active freshness source the high-consequence classes require. And The Agent Runtime and Audit establishes the mediated execution environment and makes the evidence tamper-evident. 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 two drafts: the Runtime Enforcement profile (the invariants) and the AuthZEN Profile (the wire binding).

• 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 core, 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.