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

---
title: "Human Emergency Override Protocol (HEOP)"
abbrev: "HEOP"
category: std
docname: draft-heop-human-emergency-override-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
  - human override
  - emergency stop
  - agentic workflows
  - HITL
  - execution context

author:
  -
    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 {#mapping}

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 {#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 {#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 {#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)

~~~json
{
  "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

~~~json
{
  "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 {#compliance}

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:

~~~json
{
  "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 {#broadcast}

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 {#dead-mans-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.