Overview

The layers before this one build the Mission as a governance object. It is approved with integrity (From a Request to an Approved Mission), bound to instances and delegated under a strict subset (Mission-Bound Authority), enforced per action (Mission-Bound Runtime Enforcement), and observed and revoked over its lifecycle (Mission Lifecycle and Change). Each of those guarantees is stated as a contract the Authorization Server, a Policy Decision Point, or a token holder upholds.

A running agent does not honor contracts for free. It is a harness that checkpoints state and resumes after restarts, an orchestrator that sequences many steps over hours, and a producer of signed records that, on their own, only its own auditor can fully trust. Each of those is a place where a stated guarantee can quietly stop holding: the session resumes after the Mission was revoked, the workflow is halfway through a wire transfer when the Mission is suspended, and a signed log can be backdated by whoever holds the signing key.

This part specifies the operational layer that closes those three gaps. It does not introduce a new authority object. It makes the existing one survive a real, long-running, multi-step, possibly-compromised agent. Three drafts answer three questions:

• Sessions are not authority. When an agent recovers a session, what stops it from acting on authority that has since been revoked? The harness profile binds continuity state to Mission state and re-checks before resuming.
• Unwinding work in flight. A Mission can stop after some steps committed and before others run. What happens to the work already moving? The orchestration profile records, before dispatch, how each step will be unwound.
• Evidence anyone can verify. The suite produces signed evidence at every step, but signed is not tamper-evident. How does a party in another trust domain confirm nothing was dropped or backdated? The audit profile registers evidence into a transparency log.

All three are OPTIONAL companions to the issuance core, at different maturity, and optional at the protocol layer does not mean optional for the claim: the harness is required for the governed-agent claim, and orchestration and audit are required by the claims that use them. The harness is part of the governed agent bundle’s recommended set. Orchestration is a newer, experimental profile the bundle grows into as needed. Audit layers onto any bundle. Together they are what makes the difference between a Mission that is governable in principle and one that is governed in a system that is actually running.

Sessions are not authority

Session continuity is not authority.

The Mission Is the Missing Abstraction drew the line. A session can prove the runtime survived a restart. It cannot prove the Mission survived. The separate note Sessions Are Not Missions made the argument in full. The harness profile turns it into a requirement.

An agent harness exists to make work durable. It checkpoints conversation and planning state, persists a task graph, queues background jobs, caches tool connections and OAuth tokens, and tracks sub-agent handles, so the agent can survive a process restart, a device handoff, a scheduled wake-up, a retry, or an asynchronous tool response. Every one of those is a continuation point, a moment where the harness resumes work it saved earlier. And every one of them is a moment where the authority that justified the work may have ended while the runtime state that carries it did not. A task graph can survive a revoked Mission. A warm connection to a tool server can outlive the condition that authorized it. A child agent can keep running after its parent Mission is suspended.

The design move is a single one applied everywhere. The harness binds every governed session and task-graph node to a Mission binding: the Mission’s id and issuer, the authority_hash when known, the last-known state and its source, freshness information (when status was last checked and when that check expires), and, for governed work, a required stop policy. The binding grants nothing. It is the pointer that tells the harness which Mission state it must re-establish before it continues. The rule that follows:

Before resuming governed work, the harness MUST establish that the Mission is active within the deployment’s staleness bound, even when the OAuth credentials in the session are still valid.

It establishes that state through one of the lifecycle surfaces from Mission Lifecycle and Change: a Mission Status query, an event-driven state cache fed by Lifecycle Signals, a runtime PDP decision that itself checks current state, or another deployment-defined source with equivalent freshness semantics. If it cannot establish active state, it does not resume. If the state is anything else (revoked, expired, suspended, completed, superseded, or a state a newer profile added that this harness has never heard of), it stops. That last case matters. The harness inherits the suite’s forward-compatibility rule, treating any state other than active as non-active, so an unknown state fails safe rather than slipping through.

“Stop” is not a single action. The harness picks from four stop behaviors based on the Mission state and the action class:

• suppress: do not dispatch the queued or resumable work. Preserve it for audit or operator review.
• pause: hold the work pending an authorized lifecycle transition such as a resume.
• terminate: end the task graph and release its runtime resources.
• handoff: escalate to a human or governance workflow without taking any further governed action.

A revoked or completed Mission means suppress or terminate. A suspended one means pause or suppress. An unknown or stale state means suppress or pause. For irreversible actions, external commitments, and privileged administration, handoff or orchestration handling (the next section) is preferred over a blunt stop. And a handoff is not open-ended. The review outcome is approve, reject, or expire, a parked item carries a maximum age, and approved work re-enters the resume algorithm, because review approval is not itself a Mission-state check.

The same discipline extends to the things harnesses quietly reuse. A cached credential or tool connection is not evidence the Mission is still active. Before reusing one for governed work, the harness re-checks the Mission and the action. Connections are keyed by Mission, authority hash, audience, actor, and sender-constraint key, so a connection opened for one Mission never becomes ambient authority for another. (The one sanctioned reuse is a connection that carries no authority at all, where every consequential use is separately authorized under the target Mission.) A warm connection to a tool server is not a permit to call a tool. And a sub-agent never inherits authority by descending from a parent session. It gets an explicit child-Mission or delegation binding (Mission-Bound Authority), and when the parent Mission goes non-active the harness propagates the stop to dependent children.

A concrete moment, on the series running example. An agent preparing the Q3 board packet runs as a long-running overnight job, so its session outlives the user’s attention. At 02:00 it resumes a queued task graph to continue the packet draft. The board meeting was cancelled and the Mission revoked at 23:00. The harness re-reads the Mission state before dispatching anything, finds revoked, declines to dispatch, marks the cached docs.example.com connection unusable, and emits evidence:

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

{
  "event_id": "hrn_7pQ4mN9s",
  "event_type": "resume_suppressed",
  "mission": {
    "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
    "issuer": "https://as.example.com",
    "authority_hash": "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY"
  },
  "session_id": "sess_agent_42",
  "work_item": "draft_board_packet_section_3",
  "state": "revoked",
  "state_source": "signal",
  "decision": "suppress",
  "reason": "mission_not_active",
  "occurred_at": "2026-10-01T02:00:00Z"
}

The session was fully recoverable. The authority that justified it was gone. The harness let the Mission, not the session, decide.

The mediated execution environment

The harness profile carries one requirement that does not look like continuity management but is the structural complement to Mission-Bound Runtime Enforcement. Its high-assurance tier puts the sender-constraint key in the enforcement point’s custody, not the agent’s, so a compromised agent cannot act off the enforced path. That guarantee is empty if the agent has an off-path route to the resource in the first place (a debug shell, a direct socket, an unsanctioned egress, a connector that skips the gate). Custody is moot if the agent can reach the resource around the PEP.

Establishing the closed environment is the harness’s job. The draft names this Mission Mediation:

For the action classes a deployment mediates, the harness MUST run governed consequential work in an execution environment whose only path to those actions is through the mediating PEP, and MUST NOT leave an unmediated route to a mediated class.

This is where the harness and the runtime profile meet. The runtime layer holds the key. The harness guarantees there is no door without a lock, and the key must not live behind the same door. A deployment claiming compromise-resistant enforcement isolates the mediating PEP and its key custody from the agent-facing harness components, by process, host, or service separation, because a harness that both faces the agent and holds the sender-constraint key defeats mediated custody the moment it is compromised. The claim is also published, not implied. The harness publishes an execution-environment scope statement naming, for each mediated class, the isolation mechanism that confines governed work and the unmediated paths excluded from the claim. Verifying that no unmediated path exists is a deployment audit obligation, not a protocol property. A harness that cannot guarantee a closed environment for an action class MUST NOT represent work in that class as runtime-enforced, the same enforcement-scope honesty the runtime profile requires.

The harness profile adds one more session-level control that no per-action check can: taint tracking. The runtime PDP evaluates each action in isolation. It never sees the session as a whole. The harness does. Once attacker-influenceable content (a fetched document, a tool result, an inbound message) enters a governed session, the session is tainted, and before a consequential egress the harness should require a fresh action-bound approval or downgrade that authority. This is plan-then-execute. Untrusted content may inform the agent’s planning, but it must not, on its own, drive an egress the user never directed. The draft is candid that this is a coarse control. It does not track which datum reached which call, so it cannot close within-scope data laundering, but it forces a human or a fresh approval between injected input and an external side effect. Least Exposure Is Broader Than Least Privilege makes the general case: the exposure surface, not just the action surface, is what a Mission should bound.

A harness check never replaces the PEP at the last controllable boundary. The two compose. The harness decides whether a unit of work may continue at all. The runtime layer still gates every consequential action.

Unwinding work in flight

Mission runtime enforcement can refuse the next action. It cannot un-send the last one.

The runtime layer is a gate in front of each action, so revoking a Mission reliably stops everything that has not happened yet. But a long-running workflow is a sequence, and a Mission can stop in the middle of it. After a journal entry posted, before the reviewer was notified. After a payment was dispatched, before anyone can prove it cleared. Denying the next step does nothing about the steps already in motion. Mission termination is not just an access-control denial. It is a question about execution state. The orchestration profile answers it.

The move is to plan the unwinding before the work runs, not to improvise it after a Mission stops. Two pieces make that possible.

First, every consequential step is assigned a reversibility class before it executes:

• read_only: observes data, no external effect. Suppression prevents future exposure, but prior disclosure cannot be undone.
• reversible_write: changes state and has a known compensation that can restore or materially offset it.
• irreversible_action: cannot be reliably undone once completed.
• external_commitment: commits to an external party: a sent message, a started payment, a signature, a filing, an order.
• privileged_administration: changes policy, access, configuration, or security posture.

The last three are deliberately the same-named action classes from Mission-Bound Runtime Enforcement. read_only and reversible_write are the finer distinction this profile adds for the sake of deciding what can be compensated. A step’s reversibility class must be consistent with, and no lower than, the runtime action class for the same operation, and the orchestrator MUST NOT lower it at runtime to dodge review. That is the same can’t-talk-yourself-down floor the runtime layer enforces, and for the same reason. The class comes from a trusted source (resource policy, an operation profile, a reviewed workflow definition). An agent’s plan, model output, or tool description may suggest a class, but it is never the sole authority for lowering one.

Second, before dispatching a consequential step, the orchestrator records an unwind plan for it. The plan states what happens to the step at each phase of trouble: what to do if the Mission is already non-active before the step starts, what to do if it stops while the step is in flight, and, for everything but a pure read, what to do after the step has completed. A worked plan for the riskiest kind of step:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "step_id": "notify_reviewer_audit_committee",
  "mission_id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
  "reversibility": "external_commitment",
  "pre_start_behavior": "human_review",
  "in_flight_behavior": "wait_then_review",
  "post_completion_behavior": "human_review",
  "review_queue": "audit-committee-review",
  "evidence_policy": { "link_runtime_evidence": true, "retain_for": "mission_audit_horizon" }
}

The plan is also committed, not just recorded. The step’s first Orchestration Evidence record carries an unwind_plan_hash over the plan, so an auditor can detect any later alteration of the plan a step ran under. And every member of the plan (the compensation action, the review queue, the safe point) derives from a trusted source. Model output MUST NOT define them.

When the orchestrator learns a Mission is no longer active (from a status poll, a signal, a PDP denial, a harness stop, or an operator), it stops dispatching new steps, suppresses queued work, evaluates every in-flight step, and runs the post-completion behavior for completed steps whose plan requires it. The hard part is the in-flight step, and the profile forces the honest distinction:

• not_dispatched: not yet at the PEP or external system. Suppress or pause it.
• dispatched_not_committed: sent, but still cancellable. Attempt cancellation if the plan says so.
• committed: the effect occurred, or the system cannot prove it did not. Apply post-completion behavior.
• unknown: the orchestrator cannot tell whether it committed. Treat it as requiring human review.

That unknown row is the point. Distributed systems frequently cannot prove whether an in-flight action committed, and treating “I don’t know” as “it didn’t happen” is how audit gaps form. For an irreversible action, an external commitment, or a privileged change, an unknown outcome must not be quietly filed as success or as harmless suppression. It goes to review. Cancellation acceptance by an upstream queue is not proof the external action did not occur.

When a completed step does need to be walked back, that compensation is itself governed work. A refund, a reversing entry, a cancellation message. Each can be as consequential as the action it offsets. So the profile refuses to let Mission termination become a backdoor to unauthorized remedial action. Compensation under a Mission that has already gone non-active requires one of exactly two documented authority bases: the resource’s own policy (a remediation the resource authorizes for itself, such as a local rollback) or a narrow, pre-provisioned remedial Mission that is still active. An operator may gate either basis, but operator approval is not itself an authority basis. It does not create authority a PEP would enforce over a terminated Mission. If neither basis applies, the orchestrator does not compensate. It hands off to a human.

Like the harness, the orchestrator does not replace the PEP. A runtime permit obtained just before revocation might still arrive at the PEP afterward. The orchestrator stops dispatching such work, and the PEP still enforces its own permit freshness and Mission-state check. The harness decides whether a unit of work may continue. The orchestrator decides how in-flight workflow state is unwound. The runtime layer gates each action. Three checks, three questions, none subsuming the others.

Evidence anyone can verify

Every layer of this suite signs its evidence. Signed is not the same as tamper-evident.

By the time a Mission completes, the suite has produced a trail: the approval event, every lifecycle transition, the consent rendering the user saw (From a Request to an Approved Mission), the per-action decision and execution evidence (Mission-Bound Runtime Enforcement), and the harness and orchestration evidence from this part. Each record is signed, which makes it attributable and tamper-evident in isolation.

It does not make the record set trustworthy. Whoever holds the signing key can backdate a record, drop an inconvenient one, or show different histories to different auditors. And nothing a relying party holds detects it. A compliance auditor in another company is worse off still. They have only the issuer’s word that its own logs are complete. A bare signature over a narrowed token cannot give a cross-domain party offline confidence that nothing was reordered or omitted.

The audit profile closes that gap by registering Mission evidence into a SCITT Transparency Service. The transparency substrate is not speculative. The SCITT architecture is ratified as RFC 9943, so this profile builds on a published standard. A producer (the Authorization Server, a PDP, a harness) registers a record as a Signed Statement. The service appends it to a verifiable, non-equivocating log and returns a Receipt that proves inclusion. The Signed Statement plus its Receipt is a Transparent Statement that any party can verify offline. This record was registered, at a committed time, in a log that cannot later drop or reorder it.

Two design choices make it practical, and they are the ones worth carrying out of this section:

The Mission is the statement subject. Every Signed Statement about a Mission uses the same sub, a fixed URI built from the Mission’s issuer and id (<issuer>/missions/<id>). Because the construction is fixed, independent producers in different domains all compute the same subject, and they share one feed when they register with the same Transparency Service, which cross-domain deployments should. An auditor who enumerates that subject (the deployment supplies the enumeration, since the substrate defines no feed query) gets the records that were registered, in order, append-only (approval, consent, decisions, lifecycle), as a single narrative under sub = https://as.example.com/missions/msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1:

Two caveats keep that honest. Transparency proves what was registered, not that everything was, so completeness is only checkable against an expected schedule. A deployment registers on a predictable cadence so an omission stands out as a gap. And “see it identically” holds against equivocation only if you either trust the single Transparency Service not to show different auditors different histories, or register with multiple independent services.

Statements commit by hash, never in the clear. The Signed Statement carries a COSE hash envelope whose payload is the digest of the retained evidence record as issued, not the record itself. A transparency log is append-only and may be widely readable. Nothing in it can be redacted later. So the sensitive task data stays out of the log entirely, retained separately under access control, and a relying party retrieves it and checks it against the committed digest. The log proves a specific record was registered at a time. The content is verified out of band. Even the committed metadata leaks, though. The sub construction is fixed and does not expose the Subject directly, but it is a durable per-Mission correlator whose existence and registration cadence are observable in a shared log, so a deployment should weigh whether a Mission’s mere existence and timing are sensitive before registering in a widely readable service, and what its issuer and id reveal.

That split also sharpens what verification means. The profile separates an integrity failure (a bad signature, a bad Receipt, a broken inclusion proof, or a hash that does not match the retrieved evidence) from an audit failure, where the evidence, or a producer or service trust anchor, cannot be retrieved or resolved in the access window. An integrity failure is rejected. Among its causes, only the hash mismatch means the retained record itself was altered. The others mean the statement or the log cannot be trusted. An audit failure means you have proven the record was registered and not reordered but cannot confirm its content, which is not proof of tampering, and must not be treated as such.

Two precise notes on what this profile is for, because it is easy to oversell:

This layers onto any bundle without changing it. It defines no new evidence object. It registers the records the suite already produces. A deployment that keeps its evidence without a Transparency Service is fully conformant and unaffected.

And it buys accountability, not prevention. Transparency makes a registered record impossible to silently backdate, drop, or reorder, and gives a cross-domain party offline verification. It does not make a dishonest producer honest. A producer can still register a false record. Transparency only makes that false record permanent, attributable, and visible to every auditor. And it proves only that a record was registered, not that the action the record describes actually occurred or was authorized. That is the evidence’s own semantics, not something the log can vouch for.

Run the whole Q3 board-packet task through this operational layer and the three checks land in order, just as the examples above show them. The board meeting is cancelled and the Mission is revoked mid-draft. Because the harness bound the agent’s session, task graph, and queues to Mission state, it finds the Mission no longer active and stops the paused draft work. Session continuity was recoverable, but it was never the authority. Orchestration then unwinds what was in flight. The half-written board-packet doc is a reversible_write, rolled back or compensated per the reversibility class and unwind plan recorded before it ran. And the Mission’s SCITT feed shows one verifiable, append-only history under the single subject (approval → consent evidence → the permitted Q3 financials read → the denied CRM expansion → the revocation), each committed by hash, so the packet’s financial contents never enter the log.

The six-layer architecture

This is the operational close of the practice series, so it is worth seeing the whole implementation stack at once. The two series specify one durable object and follows it down a single spine (intent becomes a Mission, the Mission bounds authority, enforcement evaluates each action against it) across six layers:

Read it as layers, not publication order. The Mission Is the Missing Abstraction is the only mandatory core. Everything else is an OPTIONAL companion that layers on without changing it, optional to the core and required by the claim that uses it. Parts 1 through 4 each make the Mission trustworthy along one dimension: the approval that creates it, the delegation that fans it out, the action that draws on it, and the state that governs it. This part is different in kind. It does not add a guarantee, it keeps the others from silently lapsing inside a running agent. The harness keeps a recovered session from acting on dead authority. The orchestrator unwinds work the kill switch caught mid-flight. The audit profile makes the whole evidence trail verifiable by someone who trusts none of the producers. They are why the architecture holds up against a long-running, multi-step, possibly-compromised agent rather than only an idealized one.

The series frames adoption as the adoption ladder, and this part fills out the Governed rung:

The Governed rung adds consent evidence (From a Request to an Approved Mission) and the harness (this part), growing with delegation, expansion, and orchestration as the use case arrives. Audit transparency layers onto any rung. Compromise resistance is not a rung of its own: it comes from meeting all four conditions of the high-assurance tier, and the adoption post’s bundles table carries the full what-you-get and what-you-do-not-get map for every rung.

A deployment with no agentic surface and no cross-hop audit need does not need a Mission layer and should not pay its cost. But for the deployments this series is written for (where authorization governs a user-approved durable task that spans many tokens, calls, actors, and a long stretch of time), the through-line is one sentence. The Mission Is the Missing Abstraction argued that the Mission is the missing abstraction because OAuth had no first-class object for the approved task. This part is where that object earns its keep. It is the thing a recovered session must re-check, the thing an in-flight workflow unwinds against, and the subject that ties a Mission’s whole evidence feed together. Session continuity is not authority. The Mission is.

For the full wire-level detail, read the three drafts: Mission-Aware Agent Harnesses, Mission Orchestration and Unwinding, and Mission Audit Transparency. For the full spine applied end to end on a concrete deployment, Least-Privilege MCP Tool Calls Need a Mission walks an MCP server through it. And the story does not end at the operational layer. The Mission Framework maps these layers onto the substrate-neutral framework, and Adopting Mission-Bound Authorization turns them into the staged build: the protocol MVP to ship now, and the roadmap that needs iteration.