ietf-draft-analyzer/workspace/drafts/new-drafts/draft-heop-human-emergency-override-00.md

fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com

normative: RFC7519: RFC7515: RFC9110: RFC8615: I-D.nennemann-wimse-ect: title: "Execution Context Tokens for Distributed Agentic Workflows" target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/ I-D.nennemann-agent-dag-hitl-safety: title: "Agent Context Policy Token: DAG Delegation with Human Override" target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

informative:

--- abstract

This document defines the Human Emergency Override Protocol (HEOP), the runtime enforcement mechanism for human intervention in autonomous AI agent operations. HEOP is the "how" to ACP-DAG-HITL's "when": where the Agent Context Policy Token defines conditions that require human decision, HEOP defines the wire protocol for override commands, agent compliance, and acknowledgment. HEOP specifies four override levels (pause, constrain, stop, takeover), a mandatory agent compliance endpoint, and records every override as an ECT DAG node for tamper-evident audit. Override levels map directly to ACP-DAG-HITL actions.

--- middle

Introduction

As AI agents gain autonomy in critical infrastructure, the ability for humans to intervene quickly and reliably becomes essential. The current ratio of autonomous capability drafts to human oversight drafts in the IETF is roughly 7:1.

The Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}} defines a policy language for human-in-the-loop safety: trigger conditions, required roles, and permitted actions (pause, escalate, abort). But it does not define the runtime protocol for how overrides are transmitted to agents, how agents acknowledge them, or how the intervention is recorded. HEOP fills this gap.

HEOP draws from industrial safety: the emergency stop button on factory equipment, the circuit breaker in electrical systems, the kill switch in robotics. The override mechanism must be simpler and more reliable than the system it controls.

Every override command and acknowledgment is recorded as an ECT {{I-D.nennemann-wimse-ect}}, linking into the workflow DAG. At L3, this provides the tamper-evident audit trail that regulated environments (FDA, MiFID II, EU AI Act) require for human intervention records.

Conventions and Definitions

{::boilerplate bcp14-tagged}

Override:

A human-initiated command that alters an agent's autonomous operation, taking precedence over the agent's own decision-making.

Operator:

A human user authorized to issue override commands, corresponding to a required_role in ACP-DAG-HITL policy.

Override Level:

One of four escalating intervention types, each with deterministic agent behavior requirements.

Mapping to ACP-DAG-HITL Actions

HEOP override levels are the runtime realization of ACP-DAG-HITL actions:

ACP-DAG-HITL action	HEOP Level	Behavior
pause	1 (PAUSE)	Suspend autonomous actions, hold state
(no equivalent)	2 (CONSTRAIN)	Restrict to allowed action subset
abort	3 (STOP)	Cease all actions, enter inert state
escalate	4 (TAKEOVER)	Transfer control to human operator
{: #fig-mapping title="ACP-DAG-HITL to HEOP Mapping"}

Level 2 (CONSTRAIN) extends beyond ACP-DAG-HITL's current action vocabulary. When a HITL rule triggers with action: "pause" and override_action: "continue", the operator MAY continue with HEOP Level 2 constraints rather than full resumption.

Override Levels

Level 1 -- PAUSE

The agent MUST suspend all autonomous actions and hold its current state. It MUST NOT initiate new actions but MAY complete in-progress actions if stopping mid-execution would cause harm. The agent resumes when a RESUME command is received.

Level 2 -- CONSTRAIN

The agent MUST restrict its actions to a specified subset defined in the override command. The agent MUST reject any action not on the allowlist.

Level 3 -- STOP

The agent MUST immediately cease all autonomous actions, abandon in-progress actions where safe, and enter an inert state. It MUST NOT act until explicitly restarted. This is the e-stop.

Level 4 -- TAKEOVER

The agent MUST transfer operational control to the human operator, entering pass-through mode where it executes only explicit operator commands. The agent's sensors and outputs remain available to the operator as tools.

Override Command Format

Override commands are HTTP POST requests to the agent's well-known endpoint, carrying an ECT in the Execution-Context header:

POST /.well-known/heop/override HTTP/1.1
Content-Type: application/json
Authorization: Bearer <operator-jwt>
Execution-Context: <override-ECT>

{
  "override_id": "urn:uuid:...",
  "level": 3,
  "reason": "Agent blocking legitimate traffic",
  "operator_id": "spiffe://example.com/human/alice",
  "scope": "*",
  "constraints": null,
  "ttl": null
}

{: #fig-override title="Override Command"}

Field definitions:

level:

Integer 1-4. MUST be present.

reason:

Human-readable text. MUST be present and logged.

scope:

Which agent functions to override. "*" means all. MAY be a list of function identifiers for partial overrides.

constraints:

For Level 2 only. JSON array of permitted action types, e.g., ["read", "monitor", "report"].

ttl:

Optional duration in seconds. If set, the override expires automatically and the agent resumes its prior mode.

Resume and Lift

POST /.well-known/heop/resume HTTP/1.1
{"override_id": "urn:uuid:...", "operator_id": "..."}

POST /.well-known/heop/lift HTTP/1.1
{"override_id": "urn:uuid:...", "operator_id": "..."}

{: #fig-resume title="Resume and Lift Commands"}

ECT Integration

Override ECT

The operator (or operator's tooling) MUST produce an ECT for every override command:

• exec_act: "heop:override"
• par: the jti of the HITL trigger ECT (if the override was triggered by ACP-DAG-HITL policy) or empty (if manually initiated)

{
  "ext": {
    "heop.level": 3,
    "heop.reason": "Agent blocking legitimate traffic",
    "heop.operator_id": "spiffe://example.com/human/alice",
    "heop.scope": "*"
  }
}

{: #fig-override-ect title="Override ECT Extension Claims"}

Acknowledgment ECT

The agent MUST produce an acknowledgment ECT:

• exec_act: "heop:ack"
• par: the jti of the override ECT

{
  "ext": {
    "heop.status": "accepted",
    "heop.prior_state": "autonomous",
    "heop.current_state": "stopped",
    "heop.effective_at": "2026-03-01T12:00:00.123Z"
  }
}

{: #fig-ack-ect title="Acknowledgment ECT Extension Claims"}

Decision Record Alignment

The override/ack ECT pair serves as the ACP-DAG-HITL Decision Record {{I-D.nennemann-agent-dag-hitl-safety}}. The required Decision Record fields map as follows:

Decision Record field	ECT source
decision_id	Override ECT jti
token_jti	HITL trigger ECT jti (from par)
rule_ids	From HITL trigger context
human_id	heop.operator_id
human_role	From operator JWT claims
decision	Derived from heop.level
time	Override ECT iat
{: #fig-decision-record title="Decision Record Mapping"}

At L3, both ECTs are recorded in the audit ledger, providing a tamper-evident record of every human intervention.

Agent Compliance Requirements

Every HEOP-compliant agent MUST:

1. Implement the /.well-known/heop/override endpoint.

2. Process override commands within 1 second of receipt. The override path MUST be independent of the agent's main processing loop.

3. Produce an acknowledgment ECT for every override.

4. If the agent cannot fully comply (e.g., hardware limitation), it MUST respond with heop.status: "partial" and a description. An agent MUST NOT respond with "rejected".

5. Expose current override status at:

GET /.well-known/heop/status

Response:

{
  "agent_id": "spiffe://example.com/agent/firewall-mgr",
  "override_active": true,
  "current_level": 3,
  "override_ect_jti": "550e8400-e29b-41d4-a716-446655440055",
  "since": "2026-03-01T12:00:00Z",
  "operator_id": "spiffe://example.com/human/alice"
}

{: #fig-status title="Override Status"}

Broadcast Overrides

For environments with many agents, HEOP supports broadcast. An operator sends a single command to a management endpoint:

POST /heop/broadcast HTTP/1.1
{
  "override_id": "urn:uuid:...",
  "level": 3,
  "reason": "Coordinated emergency stop",
  "targets": ["spiffe://example.com/agent/a1", "spiffe://example.com/agent/a2"]
}

{: #fig-broadcast title="Broadcast Override"}

The broadcast endpoint produces a parent ECT with exec_act: "heop:broadcast", and each per-agent override ECT references it via par.

Dead Man's Switch

Agents SHOULD support a heartbeat-based safety net: the agent periodically pings an operator heartbeat endpoint. If the heartbeat is missed for a configurable duration, the agent automatically enters Level 1 (PAUSE) and produces a self-override ECT with exec_act: "heop:dead_mans_switch".

This provides safety when network connectivity to the operator is lost.

Security Considerations

Override commands are high-privilege operations. All override endpoints MUST require authentication via signed JWTs with the heop_override scope. The JWT MUST include the operator's identity, a timestamp, and be signed using an asymmetric algorithm.

Override commands MUST be transmitted over TLS 1.3.

To prevent replay, agents MUST reject overrides with timestamps more than 30 seconds in the past. The override_id MUST be unique; agents MUST reject duplicates.

Deployments SHOULD implement multi-operator approval for Level 4 (TAKEOVER), requiring two independent operator JWTs.

The override endpoint SHOULD be served on a separate port or network interface from the agent's main API to ensure availability during overload.

The ECT DAG provides tamper-evident audit of all overrides. At L3, the audit ledger prevents override records from being deleted or modified after the fact.

IANA Considerations

This document requests the following IANA registrations:

1. Well-known URI registrations for heop/override, heop/resume, heop/lift, and heop/status per {{RFC8615}}.

2. Registration of exec_act values heop:override, heop:ack, heop:broadcast, heop:dead_mans_switch in a future ECT action type registry.

3. Registration of the heop_override OAuth scope.

--- back

Acknowledgments

{:numbered="false"}

This document is the runtime enforcement companion to the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}, which defines the HITL policy language, and builds on the Execution Context Token {{I-D.nennemann-wimse-ect}} for audit and tracing.