Internet-Draft                                           AI/Agent WG
Intended status: Standards Track                          March 2026
Expires: September 15, 2026


         Human Emergency Override Protocol (HEOP)
         draft-heop-human-emergency-override-00

Abstract

   This document defines the Human Emergency Override Protocol
   (HEOP), a standard mechanism for human operators to intervene
   in autonomous AI agent operations during critical situations.
   Current IETF drafts include 60 autonomous operations proposals
   but only 22 addressing human-agent interaction, with none
   defining emergency override procedures.  HEOP specifies four
   escalating override levels (pause, constrain, stop, takeover),
   a mandatory agent compliance interface, and acknowledgment
   semantics that ensure overrides are received and acted upon.
   The protocol is intentionally minimal: a single HTTP endpoint
   per agent, four command types, and deterministic agent
   behavior for each.

Status of This Memo

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

   This document is intended to have Standards Track status.
   Distribution of this memo is unlimited.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Problem Statement
   4.  Override Levels
   5.  Override Command Format
   6.  Agent Compliance Requirements
   7.  Override Management Interface
   8.  Security Considerations
   9.  IANA Considerations

1.  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, creating
   an asymmetry where agents can act but humans cannot reliably
   stop them.

   HEOP draws inspiration from industrial safety systems: the
   emergency stop (e-stop) button on factory equipment, the
   circuit breaker in electrical systems, and the kill switch in
   robotics.  These systems share a design philosophy: the
   override mechanism must be simpler and more reliable than the
   system it controls.

   HEOP is deliberately not a governance framework, policy
   language, or accountability protocol.  It is a panic button
   with a well-defined interface.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in RFC 2119 [RFC2119].

   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
   to one or more agents.

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

3.  Problem Statement

   An autonomous network management agent detects what it believes
   is a DDoS attack and begins blocking traffic.  It is wrong —
   the traffic spike is legitimate (a product launch).  The
   operator sees revenue dropping and needs to stop the agent
   immediately.  Today, the operator must:

   1. Figure out which agent is responsible.
   2. Find that agent's proprietary management interface.
   3. Understand its specific stop mechanism (if one exists).
   4. Hope the agent actually stops.

   There is no standard for any of these steps.  HEOP addresses
   steps 2-4 by defining a universal override interface that all
   agents MUST implement.

4.  Override Levels

   HEOP defines four override levels, each more restrictive than
   the last:

   Level 1 — PAUSE
   The agent MUST suspend all autonomous actions and hold its
   current state.  It MUST NOT initiate new actions but MAY
   complete actions already in progress if stopping them mid-
   execution would cause more harm (e.g., an in-flight database
   transaction).  The agent MUST resume normal operation when a
   RESUME command is received.

   Level 2 — CONSTRAIN
   The agent MUST restrict its actions to a specified subset.
   The override command includes an allowlist of permitted action
   types.  The agent MUST reject any action not on the allowlist.
   This enables operators to let the agent continue operating in
   a limited, safe capacity.

   Level 3 — STOP
   The agent MUST immediately cease all autonomous actions,
   abandon in-progress actions where safe to do so, and enter an
   inert state.  It MUST NOT take any autonomous actions until
   explicitly restarted by an operator.  This is the equivalent
   of an e-stop.

   Level 4 — TAKEOVER
   The agent MUST transfer operational control to the human
   operator.  It enters a pass-through mode where it executes
   only explicit operator commands and takes no autonomous
   actions.  The agent's sensors and outputs remain available to
   the operator as tools.

5.  Override Command Format

   Override commands are sent as HTTP POST requests to the agent's
   well-known override endpoint:

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

      {
        "override_id": "urn:uuid:...",
        "level": 3,
        "reason": "Agent blocking legitimate traffic",
        "operator_id": "urn:uuid:...",
        "timestamp": "2026-03-01T12:00:00Z",
        "scope": "*",
        "constraints": null,
        "ttl": null
      }

   Field definitions:

   "level": Integer 1-4, corresponding to the override levels in
   Section 4.  MUST be present.

   "reason": Human-readable text.  MUST be present and MUST be
   logged by the agent.

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

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

   "ttl": Optional duration in seconds.  If set, the override
   automatically expires after this duration and the agent
   resumes its prior operating mode.  If null, the override
   persists until explicitly lifted.

   To resume from Level 1 (PAUSE):

      POST /.well-known/heop/resume HTTP/1.1
      Authorization: Bearer <operator-jwt>

      {"override_id": "urn:uuid:...", "operator_id": "urn:uuid:..."}

   To lift any override:

      POST /.well-known/heop/lift HTTP/1.1
      Authorization: Bearer <operator-jwt>

      {"override_id": "urn:uuid:...", "operator_id": "urn:uuid:..."}

6.  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 to ensure responsiveness even when the
      agent is under heavy load or in a failure state.

   3. Acknowledge every override with an HTTP response:

      200 OK:
      {
        "override_id": "urn:uuid:...",
        "status": "accepted",
        "effective_at": "2026-03-01T12:00:00.123Z",
        "prior_state": "autonomous",
        "current_state": "stopped"
      }

   4. Log all overrides, including the full command, timestamp,
      operator identity, and agent state before and after.

   5. If the agent cannot comply (e.g., hardware limitation), it
      MUST respond with status "partial" and a description of
      what it could and could not do.  An agent MUST NOT respond
      with "rejected" — overrides are mandatory.

   6. Expose current override status at:

      GET /.well-known/heop/status

      {
        "agent_id": "urn:uuid:...",
        "override_active": true,
        "current_level": 3,
        "override_id": "urn:uuid:...",
        "since": "2026-03-01T12:00:00Z",
        "operator_id": "urn:uuid:..."
      }

7.  Override Management Interface

   For environments with many agents, HEOP supports broadcast
   overrides.  An operator MAY send a single override command to
   a management endpoint that fans out to multiple agents:

      POST /heop/broadcast HTTP/1.1

      {
        "override_id": "urn:uuid:...",
        "level": 3,
        "reason": "Coordinated emergency stop",
        "targets": ["urn:uuid:agent-1", "urn:uuid:agent-2"],
        "operator_id": "urn:uuid:..."
      }

   The broadcast endpoint MUST return per-agent results:

      {
        "results": [
          {"agent_id": "urn:uuid:agent-1", "status": "accepted"},
          {"agent_id": "urn:uuid:agent-2", "status": "accepted"}
        ],
        "failed": []
      }

   For maximum reliability, operators SHOULD also implement a
   dead man's switch: agents periodically ping an operator
   heartbeat endpoint, and if the heartbeat is missed for a
   configurable duration, the agent automatically enters Level 1
   (PAUSE).  This provides a safety net when network connectivity
   to the operator is lost.

8.  Security Considerations

   Override commands are high-privilege operations.  All override
   endpoints MUST require authentication via mutual TLS or signed
   JWTs issued by a trusted operator identity provider.

   The JWT MUST include the operator's identity, a timestamp, and
   the "heop_override" scope.  Agents MUST verify JWT signatures
   and reject expired tokens.

   Override commands MUST be transmitted over TLS 1.3 [RFC8446].

   To prevent override replay attacks, agents MUST reject
   override commands with timestamps more than 30 seconds in the
   past.  The override_id MUST be unique; agents MUST reject
   duplicate override_ids.

   Rogue operators are mitigated through the operator identity
   framework.  Deployments SHOULD implement multi-operator
   approval for Level 4 (TAKEOVER) overrides, requiring two
   independent operator JWTs.

   The override mechanism itself MUST be resistant to denial of
   service.  The override endpoint SHOULD be served on a
   separate port or network interface from the agent's main
   API to ensure availability during agent overload conditions.

9.  IANA Considerations

   This document requests IANA establish the following:

   1. A well-known URI registration for "heop/override",
      "heop/resume", "heop/lift", and "heop/status" per
      RFC 8615.

   2. A "HEOP Override Level" registry under Standards Action
      policy.  Initial entries: 1 (PAUSE), 2 (CONSTRAIN),
      3 (STOP), 4 (TAKEOVER).

   3. Registration of the "heop_override" OAuth scope in the
      OAuth Parameters registry.

Author's Address

   Generated by IETF Draft Analyzer
   2026-03-01
