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 8 January 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).¶

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 consumes these substrate primitives: the Mission identifier; the lifecycle state space with its only-active-permits rule and the deployment's freshness sources; the Mission-bound credentials the harness holds or mediates, with their sender-constraint custody, when the binding in use provides them; and the evidence integrity conventions imported from the runtime profile. The Mission-bound credential primitive is binding-dependent: under a binding without Mission-bound credentials, the harness binds governed work items to the externally established Mission reference of the runtime profile's Mission binding establishment step ([I-D.draft-mcguinness-mission-runtime]), and the custody duties of Section 10 apply to whatever acting credentials the deployment uses. The issuance profile [I-D.draft-mcguinness-oauth-mission] is this version's normative substrate; every OAuth artifact named in this document enters through it. Another substrate that provides the same primitives can host this profile unchanged.¶

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 it states the isolation mechanism that confines governed work (for example a container, virtual machine, or network egress policy) and names the unmediated paths excluded from the claim. For each mediated class the statement MUST also enumerate the secondary egress channel classes the environment offers, at minimum DNS resolution, log and error output, and shared stores another process reads, stating for each whether it is mediated, excluded by the isolation mechanism, or outside the claim. The statement also declares the deployment's taint policy (Section 14). Verifying that no unmediated path exists is a deployment audit obligation, not a protocol property: this profile fixes what the statement declares, not how a deployment proves it.¶

Mediation governs the agent's outputs; the same duty applies to its inputs. A Mission-aware harness SHOULD surface to the agent only the context the active Mission needs: the tool catalog and schemas scoped to the Mission's Authority Set, memory and retrieved content admitted per the taint policy (Section 14), and cached credentials and connections keyed per Section 10.1. This applies the runtime profile's least-exposure rule ([I-D.draft-mcguinness-mission-runtime]) at the harness, the layer that assembles the agent's context.¶

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

7. Resume Checks

Before resuming governed work, a Mission-aware harness MUST establish that the Mission is active within the deployment's staleness bound. 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.¶

 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 and 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, but 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.¶

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

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

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 remains a coarse control, not information-flow control, though source classing and parameter provenance give it discriminating power: it gates the egress whose inputs derive from untrusted content and leaves trusted-provenance egress ungated, instead of gating every egress in any session any content entered. Data-plane provenance does not survive model inference, so a value the agent paraphrases rather than copies can shed its taint, and the control cannot close within-scope data laundering ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-mission-runtime]); it raises the bar by forcing a human or a fresh approval between untrusted input and egress. 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).¶

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

{
  "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: the bound parameters carry tainted provenance, so 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¶

• document a staleness bound per action class and its stop behavior.¶

The runtime profile's non-normative freshness table ([I-D.draft-mcguinness-mission-runtime]) is the calibration reference for these per-action-class 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.¶

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

21. References

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