Mission-Aware Agent Harnesses

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") governs the authority under which an agent acts. The runtime profile [I-D.draft-mcguinness-mission-runtime] governs per-action enforcement. Agent harnesses add a separate layer: they preserve execution state so work can resume after process restarts, device handoffs, background scheduling, retries, and sub-agent fan-out.¶

Harness continuity is useful, but it is not authority. A task graph can survive after the Mission that justified it is revoked. A cached tool connection can remain usable after the business condition that authorized it ends. A child agent can keep running after its parent Mission is suspended. This profile defines what a harness must do to avoid treating recoverable runtime state as authorization. That is one of the harness's two duties; the other is establishing the mediated execution environment, in which work in a mediated action class has no path that bypasses the enforcement point (Section 5).¶

Two ledgers coexist by design, and neither mirrors the other. The harness or its workflow engine keeps the execution ledger: task graphs, retry queues, event histories, progress. The Mission Issuer keeps the authorization ledger: the approved task, its lifecycle, and what each decision permitted. They are separated because they sit in different trust domains: the execution ledger lives with the component this profile assumes compromisable, and a kill switch cannot live inside the thing it kills. The only shared key is the Mission Binding's reference (Section 6); every obligation this profile places on a harness is a consume-and-gate check at a boundary the engine already has, never a copy of Mission state into engine state or of engine state into the Mission record (Appendix A).¶

2. Scope

This document defines:¶

• the mediated execution environment the harness establishes (Section 5);¶

• the Mission binding a harness records on sessions and task graph nodes (Section 6);¶

• resume-time checks (Section 7);¶

• queued work and retry behavior (Section 9);¶

• cached credential and tool-connection handling (Section 10);¶

• sub-agent handle requirements (Section 11);¶

• harness evidence (Section 15); and¶

• conformance for a Mission-aware harness (Section 17).¶

This document does not define a new OAuth token, a new agent protocol, or a replacement for Resource Server enforcement. A harness check does not replace a PEP at the last controllable boundary under [I-D.draft-mcguinness-mission-runtime].¶

3. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms Mission, Mission Issuer, and Mission state from [I-D.draft-mcguinness-oauth-mission] and [I-D.draft-mcguinness-oauth-mission-status]; the term Mission-bound token as defined by the issuance profile [I-D.draft-mcguinness-oauth-mission] and used by the runtime profile [I-D.draft-mcguinness-mission-runtime]; and Policy Enforcement Point (PEP) and mediated execution from the runtime profile [I-D.draft-mcguinness-mission-runtime].¶

Harness:

The runtime system that preserves and resumes agent execution state, including sessions, task graphs, queues, tool handles, and sub-agent handles.¶

Harness session:

A harness-local continuity record. It is distinct from an IdP session, browser session, OAuth authorization session, or access token.¶

Mission binding:

The Mission reference and status freshness information the harness records on a session or task graph node.¶

Governed work:

Harness-managed work that can invoke an action class or execution path in the deployment's declared runtime enforcement scope ([I-D.draft-mcguinness-mission-runtime]). Whether a work item is governed follows from the deployment's documented mapping of work items to that scope: a published artifact, not a per-item reachability judgment.¶

4. Mission Substrate

This profile is defined against the Mission model rather than against OAuth 2.0 mechanics: it is a substrate-neutral consumer, and this section is its consumption declaration under the rule of Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]) that a substrate-neutral profile declare the kernel functions and optional capabilities it consumes.¶

From the contextual-governance kernel it consumes the Mission identifier and issuer, the kernel's Mission Reference and Controller, recorded in every Mission binding (Section 6); and the lifecycle state space with its only-active-permits rule, the kernel's governance gate, which every resume check re-establishes (Section 7). The evidence integrity conventions Harness Evidence imports from the runtime profile ([I-D.draft-mcguinness-mission-runtime]) are a companion dependency of Section 15, not a substrate primitive.¶

It consumes these optional capabilities:¶

The OAuth binding [I-D.draft-mcguinness-oauth-mission] (the issuance profile to its OAuth companions) is this version's reference host: a normative reference for its concrete OAuth surfaces, not the family's substrate (the substrate contract is [I-D.draft-mcguinness-mission-substrate]). It defines each consumed kernel function and capability for OAuth 2.0, and every OAuth artifact named in this document enters through it. A binding that provides the required capabilities above, and whichever conditional capabilities the deployment's governed work relies on, can host this profile. The portability claim is capability-scoped rather than substrate-wide for the reason the substrate's Capability Confusion consideration states: every property this profile requires matches an explicit capability claim and its scope, never the generic statement that a binding supports Missions.¶

5. Mission Mediation

The runtime profile's credential custody and mediated execution ([I-D.draft-mcguinness-mission-runtime]) hold only if the agent has no path to a consequential resource that bypasses the Policy Enforcement Point. Establishing that environment is the harness's responsibility, and it is the complement to the runtime layer holding the sender-constraint key: custody is moot if the agent can reach the resource off-path.¶

For the action classes a deployment mediates ([I-D.draft-mcguinness-mission-runtime]), a Mission-aware harness MUST run governed consequential work in an execution environment whose only path to those actions is through the mediating PEP. It MUST NOT leave an unmediated route to a mediated class, such as:¶

• a debug shell;¶

• a direct network socket;¶

• an unsanctioned egress route; or¶

• a direct connector that does not pass the runtime gate.¶

A harness that cannot guarantee this for an action class MUST NOT represent work in that class as runtime-enforced, matching the enforcement-scope rule of the runtime profile.¶

The harness MUST publish an execution-environment scope statement. For each mediated action class the statement:¶

• states the isolation mechanism that confines governed work (for example a container, virtual machine, or network egress policy);¶

• names the unmediated paths excluded from the claim; and¶

• enumerates the secondary egress channel classes the environment offers.¶

The full channel-class enumeration is MUST where the deployment claims trifecta containment or agent-compromise-resistant enforcement for that class ([I-D.draft-mcguinness-mission-runtime]), and SHOULD otherwise. It covers at minimum:¶

• DNS resolution;¶

• log and error output;¶

• shared stores another process reads;¶

• shared vector stores or long-term memory;¶

• operating-system processes the agent spawns;¶

• provider-side model context;¶

• the inference API itself; and¶

• rendering surfaces that dereference remote references (a rendered image fetch is an egress performed for the agent).¶

For each of these the statement states whether it is mediated, excluded by the isolation mechanism, or outside the claim.¶

A harness MAY realize secondary-channel mediation as a harness-composed egress gate whose authoritative input is the published scope statement. For a channel class the statement marks mediated, the statement MAY name the destination set the channel may reach, so the published claim and the enforced allowlist are the same object. An egress on a channel the statement does not mark mediated, or to a destination outside a named set, MUST be refused and recorded (Section 15.2). The gate applies the same fail-closed Mission state rule as the resume checks (Section 7): work whose Mission is not active does not egress. An in-process gate mediates the agent's egress interface and supports no containment claim. The gate is not the session-taint rule: the taint duties of Section 14 apply independently of the channel and destination check.¶

6. Mission Binding

A Mission-aware harness MUST bind every governed session and governed task graph node to a Mission reference:¶

mission_id:

REQUIRED. The Mission identifier.¶

issuer:

REQUIRED. The Mission's issuer, the Mission Issuer's issuer URL.¶

authority_hash:

REQUIRED when known. The Authority Set commitment from the Mission claim.¶

status_checked_at:

REQUIRED when the harness has checked status. An RFC 3339 timestamp.¶

status_expires_at:

REQUIRED when the harness relies on a status lease. An RFC 3339 timestamp after which the status MUST NOT be used for continuation.¶

state:

REQUIRED when known. The last Mission state established by the harness.¶

state_source:

REQUIRED when state is present. One of status, signal, runtime_decision, harness, operator, or a deployment-defined source: status and signal name the Mission Status and Lifecycle Signals surfaces, runtime_decision a runtime enforcement decision, harness a harness stop decision, and operator a human operator action. This enumeration is the shared state_source value space for Mission-aware execution evidence; the orchestration profile ([I-D.draft-mcguinness-mission-orchestration]) reuses it rather than defining its own.¶

enforcement_scope:

OPTIONAL. A string or object identifying the runtime enforcement scope that applies to this session or node.¶

stop_policy:

REQUIRED for governed work. The policy the harness applies when the Mission is non-active or stale: one of the stop-behavior values suppress, pause, terminate, or handoff (Section 13), or a deployment-defined policy.¶

The Mission binding grants no authority. It is the pointer that tells the harness which Mission state it must check before continuing work.¶

Where governed requests pass through a gateway PEP that is not the harness process, the harness SHOULD attach the Mission reference to each governed request it originates, from this recorded binding, using the Mission Authority Server profile's Mission Reference Propagation channel ([I-D.draft-mcguinness-mission-authority-server]): harness attachment is the stronger attribution provenance that channel names, against agent self-selection among concurrent same-party Missions.¶

7. Resume Checks

Before resuming governed work, a Mission-aware harness MUST establish that the Mission is active within the deployment's staleness bound. The invariant behind every check in this section: freshness MUST be valid at the moment each consequential action is submitted to the runtime gate, not only at the resume boundary. Resume includes:¶

• process restart;¶

• device or worker handoff;¶

• background job wake-up;¶

• retry after failure;¶

• tool-call continuation after an asynchronous response;¶

• loading a saved workspace for further action;¶

• refreshing or reacquiring credentials; and¶

• dispatching a queued task graph node.¶

The harness establishes state through one of:¶

1. a Mission Status operation under [I-D.draft-mcguinness-oauth-mission-status];¶

2. a valid event-driven state cache maintained from [I-D.draft-mcguinness-oauth-mission-signals];¶

3. a runtime PDP decision under [I-D.draft-mcguinness-mission-runtime] that includes a current Mission state check for the action about to run; or¶

4. another deployment-defined state source with equivalent freshness semantics.¶

If the harness cannot establish active state within the bound, it MUST NOT resume governed work.¶

A resume check is a freshness-bound check, not a mandatory network call: within one valid window, a status response inside its fresh_until or a maintained event-driven cache satisfies every resume point that falls inside it, so a harness resuming many items, or continuing many tool calls, pays the wire once per window, not once per resume.¶

 load binding --> establish Mission state --> active?
                                                |  |
                                          no <--+  +--> yes
                                          |            |
                                     stop behavior   continue
                                          |            |
                                          +---> evidence <---+

8. Event-Driven State Cache

This section is OPTIONAL. A harness MAY maintain an event-driven Mission state cache using [I-D.draft-mcguinness-oauth-mission-signals]. The cache entry for a Mission MUST contain:¶

• Mission identifier and issuer;¶

• last observed state;¶

• event identifier or sequence when available;¶

• event issuance time;¶

• cache freshness expiry; and¶

• stream or issuer identity.¶

The harness MUST ignore events whose issuer, audience, signature, or ordering cannot be verified under the Signals profile. If expected events are not received within the deployment's freshness bound, the harness MUST treat the cache as stale and fall back to status polling or stop governed continuation.¶

9. Queues and Retries

A queued work item under a Mission MUST carry the Mission binding of Section 6. Before dispatching it, the harness MUST run the resume check of Section 7.¶

Retries do not inherit authority from the prior attempt. A retry MUST be treated as a new continuation point. It MUST re-check Mission state unless the retry occurs within an unexpired status lease whose use is allowed for that action class.¶

When Mission state is not active, the harness MUST suppress queued items for that Mission. It MAY preserve them for audit or operator review. It MUST NOT dispatch them until a conforming authority path permits continuation.¶

{
  "queue_item_id": "queue_journal_post_7",
  "mission_binding": {
    "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "status_checked_at": "2026-11-01T22:00:00Z",
    "status_expires_at": "2026-11-01T22:05:00Z",
    "state": "active",
    "state_source": "status",
    "stop_policy": "suppress"
  },
  "action_class": "irreversible_action",
  "not_before": "2026-11-02T02:00:00Z",
  "expires_at": "2026-11-02T06:00:00Z",
  "retry_of": "queue_journal_post_6",
  "idempotency_key": "idem_jrnl_2026q3_0042"
}

10. Cached Credentials and Tool Connections

A harness often caches OAuth tokens, MCP sessions, API clients, browser contexts, or connector handles. A Mission-aware harness MUST NOT treat cached access as evidence that a Mission remains active.¶

Before using a cached credential or tool connection for governed work, the harness MUST:¶

1. verify the cached item is still cryptographically and protocol-valid;¶

2. verify the Mission is active under Section 7; and¶

3. verify the action still passes runtime enforcement when the action is consequential.¶

When a Mission becomes non-active, the harness MUST mark cached connections associated with that Mission unusable for new governed work. If the cache can safely close or revoke them, it SHOULD do so.¶

On any stop event (Section 13), the harness MUST also mark unusable any runtime permit and single-use decision identifier ([I-D.draft-mcguinness-mission-runtime]) it holds for the affected Mission. A fresh PDP decision is REQUIRED after any non-active interval. The harness MUST NOT dispatch a consequential action on a permit obtained before that interval.¶

11. Sub-Agent Handles

Sub-agents and child workers MUST NOT inherit Mission authority merely because they descend from a parent session. A harness that starts a sub-agent for governed work MUST bind the sub-agent handle to:¶

• the parent Mission reference;¶

• the actor or client identity of the sub-agent;¶

• the authority or child Mission under which it may act; and¶

• any delegation or child-Mission constraints that apply.¶

If the parent Mission becomes non-active, the harness MUST suppress or terminate child work that depends on it, unless the child has a separate active Mission whose authority does not depend on the parent.¶

When a sub-agent needs authority not already delegated to it, the harness MUST obtain a governed delegation or child Mission. Session ancestry alone MUST NOT be used as authorization.¶

12. Harness Execution States

A governed work item is in one of the following harness execution states. Harness Evidence types prior_harness_state and resulting_harness_state (Section 15.1) against this enumeration.¶

This enumeration is the evidence vocabulary, not an internal state-machine requirement: a harness MAY run any internal execution states, provided each governed item's condition maps onto one of these values when Harness Evidence is emitted.¶

13. Stop Behavior

When a Mission is revoked, expired, suspended, completed, or otherwise non-active under the deployment's lifecycle profile, the harness MUST stop governed continuation. The stop behavior is one of:¶

suppress:

Do not dispatch queued or resumable work. Preserve state for audit or future review.¶

pause:

Suspend work pending an authorized lifecycle transition, such as resume.¶

terminate:

End the task graph and release associated runtime resources.¶

handoff:

Escalate to a human or governance workflow without performing further governed actions.¶

The harness MAY choose among these based on deployment policy and action class, but it MUST NOT continue governed execution while Mission state is non-active.¶

14. Untrusted Content and Egress

A prompt-injected agent is constrained at the point of use by the runtime layer, which gates each action against the Mission ([I-D.draft-mcguinness-mission-runtime]). The runtime layer evaluates each action in isolation; it does not see the session as a whole. The harness does: it mediates tool input and output and tracks session and task-graph history against Mission state. That makes the harness the one layer that can apply a taint rule against the case where untrusted content drives an agent to exfiltrate within its authority.¶

Taint is classed by source. Content from the Subject or the Approver does not taint; the deployment's content trust list extends that baseline to the sources it vouches for, such as first-party tools, its own catalogs, and designated corpora. Content from an unlisted source, or from a source the deployment explicitly marks untrusted (web fetches, inbound messages, third-party documents), is tainted.¶

A store a governed session can write MUST NOT be vouched on the content trust list as trusted by default. When the deployment vouches for a Mission-writable store, content the harness reads back from that store inherits the taint of the session that wrote it. A deployment that does not apply that inherited taint MUST NOT vouch for the store. Otherwise a tainted session launders content across the session boundary by writing it to a vouched store that a later session reads as trusted, defeating the fresh-session reset below.¶

The trigger is parameter provenance where the harness can establish it. Because the harness mediates tool input and output, it SHOULD track at the data plane which tainted source a value derives from. The egress rule below then applies when a bound parameter of a consequential external-communication or external-commitment action derives from tainted content.¶

Session-level taint remains the fallback where provenance is unavailable: the harness applies the rule to every such action in a governed session that tainted content has entered. Session-level taint persists for the governed session's lifetime and clears only with a fresh session or an explicit Subject-directed reset recorded in Harness Evidence (Section 15).¶

Taint follows derivation across session boundaries with the same polarity. A sub-agent session spawned from a tainted session inherits taint, because its task and context were composed there, unless every input the child receives is affirmatively of trusted provenance; and a session seeded with content derived from a tainted session (a compaction summary, carried-over working notes) is not a fresh session and inherits the taint. Where the child runs under its own Mission, the inherited state is what the harness reports at that Mission's adjudications ([I-D.draft-mcguinness-mission-discovery]).¶

The provenance polarity is fixed. In a tainted session, a bound parameter the harness cannot affirmatively trace to sources on the content trust list MUST be treated as tainted. Parameter-granularity provenance therefore only exempts an egress whose bound parameters are all affirmatively of trusted provenance; it never launders inferred or paraphrased content, which is untraceable and so remains tainted.¶

In practice the exemption reaches only verbatim tool-to-tool plumbing, where a value passes from a trusted source into the bound parameter unmodified; once the model transforms, summarizes, or rephrases a value, data-plane provenance is lost and the parameter is tainted. This default-taint polarity is a condition of the runtime profile's trifecta-containment claim ([I-D.draft-mcguinness-mission-runtime]).¶

The rule: the harness SHOULD either require a fresh action-bound approval ([I-D.draft-mcguinness-mission-runtime]) or downgrade that authority (suppress the action), rather than let the agent egress on the strength of injected content. This is the plan-then-execute pattern: untrusted content may inform the agent's planning, but it MUST NOT, on its own, drive an egress the Subject did not direct.¶

A deployment MAY instead route the taint determination through the decision request where the binding carries it ([I-D.draft-mcguinness-mission-authzen]); the PDP then enforces this rule and records the taint context in Decision Evidence.¶

One destination class is carved out. A destination the Approver concretely named at approval, a recipient, endpoint, or audience that appears in the approved Mission Intent or in an Authority Set entry's constraints, is pre-consented egress: a tainted session's send to exactly that destination does not require a fresh human approval on taint grounds alone. Parameter binding, the per-action permit, and every other duty of this profile and the runtime profile still apply, and the destination match is on the concrete approved value, never on content. Anything beyond the named set, a new recipient, an attacker-supplied address, a destination inferred from content, keeps the full taint response above.¶

The carve-out is the rule's default economics, not a weakening of the named claim: it is what keeps a mail agent whose recipients were approved with the Mission from being human-gated per send. Where a deployment claims the runtime profile's trifecta containment for content-derived destinations ([I-D.draft-mcguinness-mission-runtime]), the full taint polarity, every tainted egress human-gated, remains a condition of that claim.¶

The taint policy MUST be declared in the execution-environment scope statement (Section 5): the content trust list, the trigger granularity (parameter provenance, session-level, or both), and the fallback where provenance is unavailable. The claim is then inspectable: an auditor reads what taints, what triggers, and what happens when tracking runs out.¶

This is a coarse control, not information-flow control; its limits, and the cost of its default-taint polarity, are discussed in Section 18.7. A harness that applies it records the taint source class, the provenance where established, and the resulting downgrade or approval in Harness Evidence (Section 15).¶

{
  "tainted": true,
  "granularity": "parameter",
  "source_class": "web_fetch"
}

15. Harness Evidence

A Mission-aware harness MUST emit a Harness Evidence record when it suppresses, pauses, or terminates governed work due to Mission state, and when it reverses a stop decision to resume work. It need not emit a record for every routine continuation. It MAY aggregate or sample resume_allowed records under a documented policy, provided every stop, and every reversal of a stop, remains individually recorded.¶

The Harness Evidence Object (Section 15.1) is the authoritative definition of the record's members. The following is a non-normative summary of what a record carries:¶

• event_id;¶

• the mission object (id, issuer, and, when known, authority_hash), the same shape as the mission claim of [I-D.draft-mcguinness-oauth-mission];¶

• session_id;¶

• task graph node or queue item identifier;¶

• prior and resulting harness state;¶

• Mission state observed;¶

• status source and freshness;¶

• timestamp; and¶

• actor or sub-agent identifier when applicable.¶

A Harness Evidence record carries the Mission as the nested mission object, mirroring the mission claim; the flat mission_id and issuer of Mission Binding (Section 6) are a binding key, whereas the evidence record mirrors the claim shape.¶

Harness Evidence complements runtime enforcement evidence ([I-D.draft-mcguinness-mission-runtime]). It records execution-continuity decisions, not Resource Server authorization.¶

Harness Evidence records are subject to the record integrity and retention requirements of the runtime profile ([I-D.draft-mcguinness-mission-runtime]), imported here by reference: append-only integrity protection under a named mechanism, a per-Mission sequence indicator, no raw parameters in the record, and a retention window no shorter than the Mission's audit horizon.¶

A Harness Evidence record is registrable on the Mission's transparency feed ([I-D.draft-mcguinness-mission-audit]). Its canonical bytes are the record's JCS canonicalization under the imported evidence conventions. Its type identifier is application/mission-harness-evidence+json (a local-use identifier pending registration). A harness that registers its evidence publishes its signing key in the deployment key set alongside the PEP key the runtime profile requires, so a relying party can verify the harness as the record's authoritative producer. Harness and egress evidence emitters satisfy the runtime profile's agent-isolated evidence-emission condition only where the Enforcement Scope Statement names them, and their emission paths, in its declaration of the condition ([I-D.draft-mcguinness-mission-runtime]); carrying this evidence implies nothing about that isolation.¶

That key follows the issuance profile's retired-key rule, extended to this artifact's retention bound ([I-D.draft-mcguinness-oauth-mission]): a retired harness signing key MUST remain resolvable in the published key set for at least the evidence retention window. For a key identified as compromised, verification of harness evidence is governed by the evidence companion's complete compromise-boundary rule ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

{
  "event_id": "hrn_7pQ4mN9s",
  "event_type": "resume_suppressed",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "session_id": "sess_agent_42",
  "work_item": "queue_invoice_retry_9",
  "state": "revoked",
  "state_source": "signal",
  "decision": "suppress",
  "reason": "mission_not_active",
  "occurred_at": "2026-11-02T02:00:05Z"
}

16. Worked Example

An agent reconciling Q3 invoices under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- runs as an overnight background job, so its session outlives alice's attention. Two harness moments matter.¶

At 02:00 the job resumes a queued task graph. Before dispatching any governed work the harness re-reads Mission state (Section 7). alice cancelled the Mission at 23:00, so the harness finds it revoked: it does not dispatch, marks cached ERP connections unusable (Section 10), and emits the suppress evidence shown above. The session was fully recoverable; the authority that justified it was gone, and the harness let the Mission, not the session, decide.¶

Earlier, while still active, the agent fetched a vendor email into its working context to extract an invoice number. Inbound mail is not on the deployment's content trust list, so the harness marks the fetched text tainted and tracks what derives from it (Section 14). Two egress attempts follow. The agent posts a journal entry whose amount and invoice reference derive from ERP records; the ERP connector is a first-party tool on the trust list, so no bound parameter carries taint, and the posting proceeds under the ordinary runtime gate. Then the agent, steered by text in the email, tries to send an external message whose body derives from that text to an address the email supplied: the bound parameters carry tainted provenance and the recipient was never named at approval, so pre-consented egress does not apply (Section 14) and the harness requires a fresh action-bound approval before the egress. The runtime layer would gate both calls against the Mission regardless; the harness adds the rule that untrusted input cannot, by itself, drive an egress alice never directed.¶

17. Conformance

A conforming Mission-aware harness MUST:¶

• bind governed sessions, queued work, and task graph nodes to Mission references;¶

• check active Mission state before resume, retry dispatch, background wake-up, and cached access use;¶

• suppress governed work when Mission state cannot be established or is non-active;¶

• run governed consequential work in a mediated execution environment for the action classes a deployment mediates, and publish the execution-environment scope statement (Section 5);¶

• prevent sub-agent authority by session ancestry;¶

• emit Harness Evidence for stop and resume decisions; and¶

• apply the stop behavior for stale state under the per-action-class staleness bounds the Enforcement Scope Statement declares ([I-D.draft-mcguinness-mission-runtime]).¶

The runtime profile's non-normative freshness table ([I-D.draft-mcguinness-mission-runtime]) is the calibration reference for those bounds.¶

A harness MUST NOT claim conformance for work it cannot suppress. It MAY claim conformance for a documented subset of execution paths if it identifies paths outside the claim.¶

The claims scale down honestly. A single-process harness, one process hosting both the agent loop and its mediation, cannot satisfy the isolation the runtime profile's agent-compromise-resistant claim requires; a harness whose tools include arbitrary code execution it does not egress-confine cannot represent the classes that execution reaches as mediated. Such a harness still conforms for what remains: the Mission binding, resume checks, queue and cache discipline, sub-agent rules, and Harness Evidence hold with no mediation claim at all, and its scope statement says exactly that.¶

18. Security Considerations

19. Privacy Considerations

Harness Evidence and Mission bindings can reveal task graphs, workspace identifiers, tool usage, agent topology, and Mission relationships. Deployments SHOULD minimize retained harness state, control access to evidence, and avoid storing raw workspace content in Harness Evidence unless required for audit.¶

20. IANA Considerations

This document makes no IANA request. The evidence type identifier of Section 15 is local-use pending registration.¶

21. References

Appendix A. Mapping to Durable-Execution Engines

This appendix is informative. Stateful agent stacks commonly run on a durable-execution engine or graph runtime that already keeps transaction logs, retry queues, and execution state; this profile adds no second copy of that state. Ownership splits by ledger: the execution ledger stays with the harness or engine, the authorization ledger with the Mission Issuer and its enforcement plane.¶

Each obligation is discharged at a boundary such an engine already exposes:¶

Workflow or run handle, and the context it carries:

the Mission Binding (Section 6); the reference travels with the work it governs.¶

Activity or tool-call boundary:

the runtime profile's PEP consult, with freshness valid at the moment of submission (Section 7.1).¶

Retry and backoff queue:

the queue rule: re-establish Mission state before release (Section 9).¶

Resume or replay of a suspended run:

the resume checks (Section 7.1).¶

Sub-workflow or child-run spawn:

sub-agent handle binding (Section 11); child authority arrives only by explicit delegation, never by session ancestry.¶

Human-in-the-loop signal or wait point:

carriage of an action-bound approval to the decision ([I-D.draft-mcguinness-mission-runtime]).¶

Compensation or saga rollback:

the orchestration profile's unwind plan ([I-D.draft-mcguinness-mission-orchestration]).¶

Engine event history:

an input to execution evidence; never the authorization record.¶

An integration is complete when each obligation is discharged at the named boundary. Nothing here requires the engine to persist Mission state beyond the binding, or the Mission Issuer to know the engine exists.¶

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 set and defines how agent harnesses keep runtime continuity separate from Mission authority.¶

Author's Address