Mission-Aware Agent Harnesses for OAuth 2.0

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 1 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] governs the authority under which an agent acts. The runtime profile [I-D.draft-mcguinness-oauth-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.¶

2. Scope

This document defines:¶

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

• resume-time checks (Section 5);¶

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

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

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

• harness evidence (Section 12); and¶

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

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-oauth-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, Mission-bound token, and Mission state from [I-D.draft-mcguinness-oauth-mission] and [I-D.draft-mcguinness-oauth-mission-status], and Policy Enforcement Point (PEP) and mediated execution from the runtime profile [I-D.draft-mcguinness-oauth-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 lead to a consequential action under a Mission.¶

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

mission_origin:

REQUIRED. The Mission Issuer.¶

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

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

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

6. 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 origin;¶

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

7. Queues and Retries

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

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

8. 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 5; 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.¶

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

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

11. 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-oauth-mission-runtime]). The runtime layer evaluates each action in isolation; it does not see the session as a whole. The harness does: it already tracks session and task-graph history against Mission state. That makes the harness the one layer that can apply a session-level rule against the case where untrusted content drives an agent to exfiltrate within its authority.¶

A governed session is tainted once content the harness did not obtain from the Subject, the Approver, or a source the deployment trusts enters it: a fetched document, a tool result, an inbound message, or similar attacker-influenceable input. A Mission-aware harness SHOULD track taint per governed session.¶

Once a session is tainted, before a consequential external-communication or external-commitment action, a Mission-aware harness SHOULD either require a fresh action-bound approval ([I-D.draft-mcguinness-oauth-mission-runtime]) or downgrade that authority for the session (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.¶

This is a coarse session-level control, not information-flow control. It does not track which specific datum reached which action, so it cannot close within-scope data laundering ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-oauth-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 and the resulting downgrade or approval in Harness Evidence (Section 12).¶

12. Harness Evidence

A Mission-aware harness MUST emit evidence when it suppresses, pauses, terminates, or resumes governed work due to Mission state. The evidence record SHOULD contain:¶

• event_id;¶

• the mission object (id, origin, 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 mission_origin of Mission Binding (Section 4) are a binding key, whereas the evidence record mirrors the claim shape.¶

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

{
  "event_id": "hrn_7pQ4mN9s",
  "event_type": "resume_suppressed",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "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-02T08:16:00Z"
}

13. 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 5). alice cancelled the Mission at 23:00, so the harness finds it revoked: it does not dispatch, marks cached ERP connections unusable (Section 8), 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. That email is untrusted content, so the session is now tainted (Section 11). When the agent, steered by text in that email, tries to send an external message, the harness does not let the egress proceed on the strength of the fetched content: it requires a fresh action-bound approval first. The runtime layer would gate the call against the Mission regardless; the harness adds the session-level rule that untrusted input cannot, by itself, drive an egress alice never directed.¶

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

• prevent sub-agent authority by session ancestry;¶

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

• document its staleness bounds and stop behavior.¶

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

15. Security Considerations

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

17. IANA Considerations

This document makes no IANA request.¶

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