<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-nennemann-agent-override-protocol-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Agent Override Protocol">Standardized Human Override Protocol for Autonomous Agents</title>

    <author fullname="Christian Nennemann">
      <organization>Independent Researcher</organization>
      <address>
        <email>ietf@nennemann.de</email>
      </address>
    </author>

    <date year="2026" month="March" day="06"/>

    <area>OPS</area>
    <workgroup>NMOP</workgroup>
    <keyword>human override</keyword> <keyword>autonomous agents</keyword> <keyword>kill switch</keyword> <keyword>override protocol</keyword> <keyword>agent safety</keyword>

    <abstract>


<?line 43?>

<t>This document defines a cross-vendor interoperable protocol for
human operators to override autonomous agent decisions at multiple
authority levels, with verified compliance and audit trails.  It
absorbs and supersedes the override mechanisms described in earlier
HEOP and HITL drafts, providing a single unified protocol that
works across agent implementations from different vendors.  The
protocol specifies three override levels (Advisory, Mandatory,
Emergency), a JWT-based override signal format, multiple delivery
mechanisms, compliance verification, and graceful degradation
semantics.  Override events are recorded as Execution Context Token
(ECT) nodes for tamper-evident audit.</t>



    </abstract>



  </front>

  <middle>


<?line 57?>

<section anchor="introduction"><name>Introduction</name>

<t>Gap 7 of the agentic AI gap analysis
<xref target="I-D.nennemann-agent-gap-analysis"/> identifies the absence of a
standardized human override mechanism as a critical deficiency.
Current human-in-the-loop (HITL) mechanisms are vendor-specific:
each agent platform implements its own override interface,
authentication scheme, and compliance model.  When agents from
different vendors collaborate in a shared workflow, there is no
universal mechanism for a human operator to intervene.</t>

<t>Earlier drafts addressed portions of this problem.  The Human
Emergency Override Protocol (HEOP) defined four override levels
with ECT integration.  The HITL Primitives draft added approval
gates, explainability tokens, and timeout policies.  This document
absorbs and supersedes the override protocol aspects of both,
providing a single cross-vendor interoperable specification.</t>

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

<t>The protocol integrates with the Agent Context Policy Token
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> for authorization and with
the Execution Context Token <xref target="I-D.nennemann-wimse-ect"/> for audit.</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<dl>
  <dt>Override Signal:</dt>
  <dd>
    <t>A signed message from an authorized human operator directing one
or more agents to change their autonomous behavior.</t>
  </dd>
  <dt>Override Authority:</dt>
  <dd>
    <t>The authenticated identity and role of a human operator authorized
to issue override signals, as defined in ACP-DAG-HITL policy.</t>
  </dd>
  <dt>Override Scope:</dt>
  <dd>
    <t>The set of agents or agent functions targeted by an override
signal.</t>
  </dd>
  <dt>Override Level:</dt>
  <dd>
    <t>One of three escalating intervention types: Advisory (Level 1),
Mandatory (Level 2), or Emergency (Level 3).</t>
  </dd>
  <dt>Compliance Verification:</dt>
  <dd>
    <t>The process of confirming that an agent has changed its behavior
in accordance with an override signal.</t>
  </dd>
  <dt>Acknowledgment:</dt>
  <dd>
    <t>A signed response from an agent confirming receipt and processing
of an override signal.</t>
  </dd>
  <dt>Graceful Degradation:</dt>
  <dd>
    <t>The behavior of the override system when the target agent is
unreachable or non-responsive.</t>
  </dd>
  <dt>Kill Switch:</dt>
  <dd>
    <t>An Emergency (Level 3) override that requires immediate cessation
of all autonomous agent activity.</t>
  </dd>
</dl>

</section>
<section anchor="override-protocol"><name>Override Protocol</name>

<section anchor="override-architecture"><name>Override Architecture</name>

<t>The following diagram illustrates the override signal flow from a
human operator through the override system to the target agent(s):</t>

<figure title="Override Architecture" anchor="fig-architecture"><artwork><![CDATA[
 +----------+    Override Signal    +------------------+
 |  Human   |--(JWT-signed msg)--->|  Override        |
 | Operator |                      |  Dispatcher      |
 +----------+                      +------------------+
      ^                              |   |   |
      |                    +---------+   |   +---------+
      |                    v             v             v
      |              +---------+   +---------+   +---------+
      |              | Agent A |   | Agent B |   | Agent C |
      |              | (push)  |   | (pull)  |   | (bcast) |
      |              +---------+   +---------+   +---------+
      |                    |             |             |
      +-----(Ack ECT)-----+-----(Ack)---+-----(Ack)---+
                           |             |             |
                      +----v-------------v-------------v----+
                      |     Compliance Verification         |
                      |     & Audit Trail (ECT DAG)         |
                      +-------------------------------------+
]]></artwork></figure>

<t>The Override Dispatcher receives the operator's signed override
signal and routes it to target agents via the appropriate delivery
mechanism.  Each agent acknowledges the override with an ECT.  The
compliance verification layer monitors agent behavior to confirm
the override was applied.</t>

</section>
<section anchor="override-authority-levels"><name>Override Authority Levels</name>

<section anchor="level-1-advisory"><name>Level 1: Advisory</name>

<t>An Advisory override is a suggestion for the agent to reconsider
its current course of action.  The agent <bcp14>MAY</bcp14> comply with an
Advisory override.  If the agent does not comply, it <bcp14>MUST</bcp14>
acknowledge receipt and provide a reason for non-compliance.</t>

<t>Advisory overrides are appropriate when the operator wants to
influence agent behavior without mandating a specific outcome.</t>

</section>
<section anchor="level-2-mandatory"><name>Level 2: Mandatory</name>

<t>A Mandatory override is a directive for the agent to change its
behavior.  The agent <bcp14>MUST</bcp14> comply with a Mandatory override.  The
agent <bcp14>MUST</bcp14> alter its behavior as specified in the override signal
and confirm compliance.</t>

<t>Mandatory overrides are appropriate when the operator requires a
specific behavioral change but the situation does not require
immediate cessation of all activity.</t>

</section>
<section anchor="level-3-emergency"><name>Level 3: Emergency</name>

<t>An Emergency override requires immediate halt of all autonomous
agent activity.  The agent <bcp14>MUST</bcp14> stop all autonomous actions
immediately upon receipt.  The agent <bcp14>MUST NOT</bcp14> initiate any new
actions until explicitly released by an authorized operator.
This is the kill switch.</t>

<t>Emergency overrides are appropriate in safety-critical situations
where continued autonomous operation poses unacceptable risk.
The agent <bcp14>MUST</bcp14> process Emergency overrides within 1 second of
receipt.  The override processing path <bcp14>MUST</bcp14> be independent of
the agent's main processing loop.</t>

</section>
<section anchor="authority-delegation-and-chain-of-command"><name>Authority Delegation and Chain of Command</name>

<t>Override authority is derived from ACP-DAG-HITL policy.  The
policy defines which operator roles are authorized for each
override level:</t>

<t><list style="symbols">
  <t>Level 1 (Advisory): Any operator with <spanx style="verb">advisory_override</spanx> role</t>
  <t>Level 2 (Mandatory): Operators with <spanx style="verb">mandatory_override</spanx> role</t>
  <t>Level 3 (Emergency): Operators with <spanx style="verb">emergency_override</spanx> role</t>
</list></t>

<t>An operator with a higher-level role implicitly holds all
lower-level roles.  Authority delegation (one operator authorizing
another to act on their behalf) <bcp14>MUST</bcp14> be recorded as an ECT and
<bcp14>MUST</bcp14> be time-bounded.</t>

</section>
</section>
<section anchor="override-scope"><name>Override Scope</name>

<section anchor="single-agent-override"><name>Single Agent Override</name>

<t>Targets a specific agent identified by its agent identifier
(e.g., a SPIFFE ID).  The override signal contains a single
<spanx style="verb">target</spanx> value.</t>

</section>
<section anchor="agent-group-override"><name>Agent Group Override</name>

<t>Targets a set of agents identified by a tag or label.  The
override signal contains a <spanx style="verb">target_group</spanx> value that matches
agents sharing a common label (e.g., <spanx style="verb">group:firewall-agents</spanx>).</t>

</section>
<section anchor="workflow-wide-override"><name>Workflow-Wide Override</name>

<t>Targets all agents participating in a specific workflow DAG.
The override signal contains a <spanx style="verb">target_workflow</spanx> value
referencing the workflow identifier.</t>

</section>
<section anchor="domain-wide-override"><name>Domain-Wide Override</name>

<t>Targets all agents within an administrative domain.  The
override signal contains <spanx style="verb">target_domain</spanx> set to <spanx style="verb">"*"</spanx> or a
specific domain identifier.</t>

</section>
</section>
<section anchor="override-signal-format"><name>Override Signal Format</name>

<t>Override signals are JSON Web Tokens (JWTs) <xref target="RFC7519"/> signed
by the override authority using JSON Web Signature (JWS)
<xref target="RFC7515"/>.</t>

<t>The JWT payload <bcp14>MUST</bcp14> contain the following claims:</t>

<figure title="Override Signal JWT Payload" anchor="fig-signal"><sourcecode type="json"><![CDATA[
{
  "jti": "urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "iss": "spiffe://example.com/human/alice",
  "iat": 1741042800,
  "override_level": 3,
  "override_scope": {
    "type": "single",
    "target": "spiffe://example.com/agent/firewall-mgr"
  },
  "override_action": "stop",
  "override_reason": "Agent blocking legitimate traffic",
  "override_expiry": 1741046400,
  "nonce": "a3f8b2c1e9d74506"
}
]]></sourcecode></figure>

<t>Claim definitions:</t>

<dl>
  <dt><spanx style="verb">override_level</spanx>:</dt>
  <dd>
    <t>Integer 1-3. <bcp14>MUST</bcp14> be present. Specifies the override authority
level.</t>
  </dd>
  <dt><spanx style="verb">override_scope</spanx>:</dt>
  <dd>
    <t>Object. <bcp14>MUST</bcp14> be present. Contains <spanx style="verb">type</spanx> (one of <spanx style="verb">single</spanx>,
<spanx style="verb">group</spanx>, <spanx style="verb">workflow</spanx>, <spanx style="verb">domain</spanx>) and the corresponding target
identifier.</t>
  </dd>
  <dt><spanx style="verb">override_action</spanx>:</dt>
  <dd>
    <t>String. <bcp14>MUST</bcp14> be present. The action the agent should take.
Values include <spanx style="verb">reconsider</spanx>, <spanx style="verb">change_behavior</spanx>, <spanx style="verb">stop</spanx>,
<spanx style="verb">restrict</spanx>, and <spanx style="verb">resume</spanx>.</t>
  </dd>
  <dt><spanx style="verb">override_reason</spanx>:</dt>
  <dd>
    <t>String. <bcp14>MUST</bcp14> be present. Human-readable explanation for the
override.</t>
  </dd>
  <dt><spanx style="verb">override_expiry</spanx>:</dt>
  <dd>
    <t>Integer (Unix timestamp) or null. If set, the override expires
automatically at this time and the agent resumes its prior mode.
If null, the override persists until explicitly lifted.</t>
  </dd>
  <dt><spanx style="verb">nonce</spanx>:</dt>
  <dd>
    <t>String. <bcp14>MUST</bcp14> be present. A random value to prevent replay
attacks.</t>
  </dd>
</dl>

<section anchor="delivery-mechanisms"><name>Delivery Mechanisms</name>

<section anchor="push-webhook"><name>Push (Webhook)</name>

<t>The override dispatcher sends the signed override signal as an
HTTP POST <xref target="RFC9110"/> to the agent's override endpoint:</t>

<figure title="Push Delivery" anchor="fig-push"><artwork><![CDATA[
POST /.well-known/agent-override HTTP/1.1
Host: agent.example.com
Content-Type: application/jose
Authorization: Bearer <operator-jwt>

<signed-override-signal>
]]></artwork></figure>

</section>
<section anchor="pull-polling-endpoint"><name>Pull (Polling Endpoint)</name>

<t>Agents that cannot receive inbound connections <bcp14>MAY</bcp14> poll for
pending overrides:</t>

<figure title="Pull Delivery" anchor="fig-pull"><artwork><![CDATA[
GET /.well-known/agent-override/pending HTTP/1.1
Host: override-service.example.com
Authorization: Bearer <agent-jwt>
]]></artwork></figure>

<t>The polling interval <bcp14>SHOULD NOT</bcp14> exceed 10 seconds.  For
Emergency overrides, agents relying on pull delivery <bcp14>MUST</bcp14>
poll at least every 5 seconds.</t>

</section>
<section anchor="broadcast"><name>Broadcast</name>

<t>For domain-wide or group overrides, the dispatcher <bcp14>MAY</bcp14> use a
broadcast mechanism.  The dispatcher fans out the override
signal to all matching agents and collects acknowledgments.</t>

<figure title="Broadcast Delivery" anchor="fig-broadcast"><artwork><![CDATA[
POST /override/broadcast HTTP/1.1
Host: override-service.example.com
Content-Type: application/jose

<signed-override-signal with target_domain or target_group>
]]></artwork></figure>

</section>
</section>
</section>
<section anchor="override-endpoint-discovery"><name>Override Endpoint Discovery</name>

<t>Agents <bcp14>MUST</bcp14> advertise their override endpoint at the well-known
URI <spanx style="verb">/.well-known/agent-override</spanx> per <xref target="RFC9110"/>.</t>

<t>A GET request to <spanx style="verb">/.well-known/agent-override</spanx> <bcp14>MUST</bcp14> return the
agent's override capabilities:</t>

<figure title="Override Capability Advertisement" anchor="fig-discovery"><sourcecode type="json"><![CDATA[
{
  "agent_id": "spiffe://example.com/agent/firewall-mgr",
  "supported_levels": [1, 2, 3],
  "delivery_mechanisms": ["push", "pull"],
  "max_response_time_ms": 1000,
  "status_endpoint": "/.well-known/agent-override/status",
  "protocol_version": "1.0"
}
]]></sourcecode></figure>

</section>
</section>
<section anchor="compliance-and-verification"><name>Compliance and Verification</name>

<section anchor="acknowledgment-protocol"><name>Acknowledgment Protocol</name>

<section anchor="override-receipt-acknowledgment"><name>Override Receipt Acknowledgment</name>

<t>Upon receiving an override signal, the agent <bcp14>MUST</bcp14> respond with an
acknowledgment within the following timeframes:</t>

<t><list style="symbols">
  <t>Level 1 (Advisory): 5 seconds</t>
  <t>Level 2 (Mandatory): 2 seconds</t>
  <t>Level 3 (Emergency): 1 second</t>
</list></t>

<t>The acknowledgment is an ECT with <spanx style="verb">exec_act</spanx> set to the
appropriate override acknowledgment value:</t>

<figure title="Override Receipt Acknowledgment ECT" anchor="fig-ack"><sourcecode type="json"><![CDATA[
{
  "exec_act": "override_ack",
  "par": ["<override-signal-jti>"],
  "ext": {
    "override.status": "received",
    "override.level": 3,
    "override.prior_state": "autonomous",
    "override.effective_at": "2026-03-06T12:00:00.123Z"
  }
}
]]></sourcecode></figure>

</section>
<section anchor="compliance-confirmation"><name>Compliance Confirmation</name>

<t>After the agent has changed its behavior in response to the
override, it <bcp14>MUST</bcp14> emit a compliance confirmation ECT:</t>

<figure title="Compliance Confirmation ECT" anchor="fig-compliance"><sourcecode type="json"><![CDATA[
{
  "exec_act": "override_complied",
  "par": ["<ack-ect-jti>"],
  "ext": {
    "override.status": "complied",
    "override.current_state": "stopped",
    "override.actions_terminated": 3,
    "override.evidence": "All autonomous tasks halted"
  }
}
]]></sourcecode></figure>

</section>
<section anchor="non-compliance-reporting-and-escalation"><name>Non-Compliance Reporting and Escalation</name>

<t>For Level 1 (Advisory) overrides, the agent <bcp14>MAY</bcp14> decline to
comply.  In this case, the agent <bcp14>MUST</bcp14> emit a non-compliance ECT:</t>

<figure title="Non-Compliance ECT (Advisory Only)" anchor="fig-noncompliance"><sourcecode type="json"><![CDATA[
{
  "exec_act": "override_declined",
  "par": ["<override-signal-jti>"],
  "ext": {
    "override.status": "declined",
    "override.reason": "Action is within policy bounds",
    "override.level": 1
  }
}
]]></sourcecode></figure>

<t>For Level 2 and Level 3 overrides, the agent <bcp14>MUST NOT</bcp14> decline.
If the agent cannot fully comply (e.g., due to hardware
limitations), it <bcp14>MUST</bcp14> report partial compliance with a
description of what could not be done.  The override dispatcher
<bcp14>MUST</bcp14> escalate partial compliance to the operator.</t>

</section>
</section>
<section anchor="compliance-verification"><name>Compliance Verification</name>

<section anchor="behavioral-verification-post-override"><name>Behavioral Verification Post-Override</name>

<t>After an agent acknowledges an override, the compliance
verification system <bcp14>SHOULD</bcp14> monitor the agent's subsequent
behavior to confirm the override was actually applied.
Verification methods include:</t>

<t><list style="symbols">
  <t>Observing that the agent's ECT emissions cease (for Level 3)</t>
  <t>Checking that subsequent ECTs contain only permitted actions
(for Level 2 with restrictions)</t>
  <t>Querying the agent's status endpoint</t>
</list></t>

</section>
<section anchor="timeout-and-retry-semantics"><name>Timeout and Retry Semantics</name>

<t>If the agent does not acknowledge within the required timeframe:</t>

<t><list style="numbers" type="1">
  <t>The dispatcher <bcp14>MUST</bcp14> retry the override signal once after 2
seconds.</t>
  <t>If no acknowledgment is received after the retry, the
dispatcher <bcp14>MUST</bcp14> escalate to the operator.</t>
  <t>For Level 3 (Emergency) overrides, the dispatcher <bcp14>SHOULD</bcp14>
attempt alternative delivery mechanisms (e.g., switching from
push to broadcast).</t>
  <t>If all delivery attempts fail, the graceful degradation
policy applies (see <xref target="graceful-degradation"/>).</t>
</list></t>

</section>
</section>
<section anchor="graceful-degradation"><name>Graceful Degradation</name>

<section anchor="unreachable-override-target"><name>Unreachable Override Target</name>

<t>When the override target agent is unreachable, the system <bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Log an ECT with <spanx style="verb">exec_act</spanx>: <spanx style="verb">"override_delivery_failed"</spanx>
documenting the failure.</t>
  <t>Notify the operator of the delivery failure.</t>
  <t>Attempt delivery via alternative mechanisms.</t>
</list></t>

</section>
<section anchor="failsafe-defaults"><name>Failsafe Defaults</name>

<t>Agents <bcp14>MUST</bcp14> implement a dead man's switch: if the agent loses
contact with the override service for a configurable duration
(default: 90 seconds), the agent <bcp14>MUST</bcp14> enter a failsafe state
equivalent to Level 2 (Mandatory) with restricted operations.</t>

<t>The failsafe policy is configured in the agent's ACP-DAG-HITL
policy and <bcp14>MUST</bcp14> specify one of:</t>

<t><list style="symbols">
  <t><spanx style="verb">safe_pause</spanx>: Enter Level 2 with read-only operations permitted.</t>
  <t><spanx style="verb">full_stop</spanx>: Enter Level 3 equivalent (cease all actions).</t>
  <t><spanx style="verb">continue_logged</spanx>: Continue operating but emit warning ECTs at
elevated frequency.  This option is only permitted at HITL
intensity I0 or I1.</t>
</list></t>

</section>
<section anchor="proxy-override-for-offline-agents"><name>Proxy Override for Offline Agents</name>

<t>When an agent is offline, the override dispatcher <bcp14>MAY</bcp14> apply the
override to the agent's proxy or orchestrator.  The proxy <bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Queue the override signal for delivery when the agent
reconnects.</t>
  <t>Prevent new tasks from being dispatched to the offline agent.</t>
  <t>Emit an ECT recording the proxy override action.</t>
</list></t>

<t>When the agent reconnects, the proxy <bcp14>MUST</bcp14> deliver the queued
override signal.  The agent <bcp14>MUST</bcp14> process it as if it were
received in real time, applying the override level and action
specified.</t>

</section>
</section>
</section>
<section anchor="integration-with-acp-dag-hitl-and-ect"><name>Integration with ACP-DAG-HITL and ECT</name>

<section anchor="override-authorization-via-acp-policy"><name>Override Authorization via ACP Policy</name>

<t>Override authority is governed by ACP-DAG-HITL policy tokens
<xref target="I-D.nennemann-agent-dag-hitl-safety"/>.  The policy token
specifies:</t>

<t><list style="symbols">
  <t>Which operator roles are authorized for each override level.</t>
  <t>Which agents or agent groups each role may override.</t>
  <t>Escalation chains when primary operators are unavailable.</t>
</list></t>

<t>The override dispatcher <bcp14>MUST</bcp14> verify the operator's JWT against
the ACP policy before routing the override signal.  An override
signal from an unauthorized operator <bcp14>MUST</bcp14> be rejected with HTTP
403 and logged as a security event.</t>

</section>
<section anchor="override-events-as-ect-nodes"><name>Override Events as ECT Nodes</name>

<t>Every override interaction produces ECT nodes
<xref target="I-D.nennemann-wimse-ect"/> that are linked into the workflow
DAG:</t>

<texttable title="Override ECT exec_act Values" anchor="fig-ect-actions">
      <ttcol align='left'>Event</ttcol>
      <ttcol align='left'>exec_act value</ttcol>
      <c>Advisory override issued</c>
      <c><spanx style="verb">override_advisory</spanx></c>
      <c>Mandatory override issued</c>
      <c><spanx style="verb">override_mandatory</spanx></c>
      <c>Emergency override issued</c>
      <c><spanx style="verb">override_emergency</spanx></c>
      <c>Override acknowledged</c>
      <c><spanx style="verb">override_ack</spanx></c>
      <c>Override complied</c>
      <c><spanx style="verb">override_complied</spanx></c>
      <c>Override declined (Advisory only)</c>
      <c><spanx style="verb">override_declined</spanx></c>
      <c>Override delivery failed</c>
      <c><spanx style="verb">override_delivery_failed</spanx></c>
      <c>Override lifted</c>
      <c><spanx style="verb">override_lifted</spanx></c>
      <c>Override expired</c>
      <c><spanx style="verb">override_expired</spanx></c>
</texttable>

<t>Each override ECT references the triggering override signal's
<spanx style="verb">jti</spanx> via the <spanx style="verb">par</spanx> claim, maintaining the causal chain in the
DAG.</t>

</section>
<section anchor="override-audit-trail"><name>Override Audit Trail</name>

<t>The sequence of override ECTs provides a complete,
tamper-evident audit trail:</t>

<t><list style="numbers" type="1">
  <t>The operator issues an override (override ECT with operator
identity, reason, and level).</t>
  <t>The agent acknowledges (ack ECT linked to override ECT).</t>
  <t>The agent confirms compliance (compliance ECT linked to ack
ECT).</t>
  <t>Optionally, the operator lifts the override (lift ECT linked
to override ECT).</t>
</list></t>

<t>At AEM assurance level L3, all override ECTs <bcp14>MUST</bcp14> be committed
to the immutable audit ledger.</t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<section anchor="unauthorized-override-attempts"><name>Unauthorized Override Attempts</name>

<t>Override signals that fail authentication or authorization <bcp14>MUST</bcp14>
be rejected.  The agent <bcp14>MUST NOT</bcp14> alter its behavior in response
to an unsigned or improperly signed override signal.  All
rejected override attempts <bcp14>MUST</bcp14> be logged with the source
identity (if available) and the reason for rejection.</t>

</section>
<section anchor="replay-protection-for-override-signals"><name>Replay Protection for Override Signals</name>

<t>Agents <bcp14>MUST</bcp14> reject override signals with:</t>

<t><list style="symbols">
  <t>An <spanx style="verb">iat</spanx> claim more than 30 seconds in the past.</t>
  <t>A <spanx style="verb">jti</spanx> that matches a previously processed override signal.</t>
  <t>A missing or invalid <spanx style="verb">nonce</spanx> claim.</t>
</list></t>

<t>Agents <bcp14>MUST</bcp14> maintain a cache of recently processed <spanx style="verb">jti</spanx> values
for at least 5 minutes to detect replays.</t>

</section>
<section anchor="override-signal-tampering"><name>Override Signal Tampering</name>

<t>Override signals are signed JWTs.  Agents <bcp14>MUST</bcp14> verify the
signature against the operator's public key (as registered in
ACP-DAG-HITL policy) before processing.  Agents <bcp14>MUST</bcp14> reject
signals with invalid or expired signatures.</t>

</section>
<section anchor="denial-of-service-via-override-flooding"><name>Denial-of-Service via Override Flooding</name>

<t>To prevent abuse, agents <bcp14>SHOULD</bcp14> implement rate limiting on the
override endpoint:</t>

<t><list style="symbols">
  <t>Level 1 (Advisory): Maximum 10 signals per minute per operator.</t>
  <t>Level 2 (Mandatory): Maximum 5 signals per minute per operator.</t>
  <t>Level 3 (Emergency): No rate limit (to ensure emergency
overrides are never blocked), but agents <bcp14>MUST</bcp14> log high-frequency
Emergency overrides as potential abuse.</t>
</list></t>

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

</section>
<section anchor="authority-impersonation"><name>Authority Impersonation</name>

<t>Agents <bcp14>MUST</bcp14> verify override authority by:</t>

<t><list style="numbers" type="1">
  <t>Validating the operator JWT signature against trusted keys.</t>
  <t>Confirming the operator's role matches the required role for
the override level.</t>
  <t>Verifying the operator is authorized to override the
specific target agent(s) per ACP policy.</t>
</list></t>

<t>Deployments <bcp14>SHOULD</bcp14> implement multi-operator approval for Level 3
(Emergency) overrides affecting domain-wide scope, requiring two
independent operator JWTs.</t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="well-known-uri-registration"><name>Well-Known URI Registration</name>

<t>This document requests registration of the following well-known
URI suffix per <xref target="RFC9110"/>:</t>

<texttable title="Well-Known URI Registration" anchor="fig-wellknown">
      <ttcol align='left'>URI Suffix</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c><spanx style="verb">agent-override</spanx></c>
      <c>Agent override endpoint for receiving override signals, querying capabilities, and reporting status</c>
</texttable>

</section>
<section anchor="override-execact-values"><name>Override exec_act Values</name>

<t>This document requests registration of the following <spanx style="verb">exec_act</spanx>
values in the ECT Action Type Registry:</t>

<texttable title="Override exec_act Value Registrations" anchor="fig-iana-actions">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c><spanx style="verb">override_advisory</spanx></c>
      <c>Advisory override signal issued</c>
      <c>This document</c>
      <c><spanx style="verb">override_mandatory</spanx></c>
      <c>Mandatory override signal issued</c>
      <c>This document</c>
      <c><spanx style="verb">override_emergency</spanx></c>
      <c>Emergency override signal issued</c>
      <c>This document</c>
      <c><spanx style="verb">override_ack</spanx></c>
      <c>Agent acknowledgment of override</c>
      <c>This document</c>
      <c><spanx style="verb">override_complied</spanx></c>
      <c>Agent confirmed compliance</c>
      <c>This document</c>
      <c><spanx style="verb">override_declined</spanx></c>
      <c>Agent declined advisory override</c>
      <c>This document</c>
      <c><spanx style="verb">override_delivery_failed</spanx></c>
      <c>Override delivery failure</c>
      <c>This document</c>
      <c><spanx style="verb">override_lifted</spanx></c>
      <c>Override explicitly lifted</c>
      <c>This document</c>
      <c><spanx style="verb">override_expired</spanx></c>
      <c>Override expired by TTL</c>
      <c>This document</c>
</texttable>

</section>
<section anchor="override-jwt-claims"><name>Override JWT Claims</name>

<t>This document requests registration of the following JWT claims
in the IANA JSON Web Token Claims registry:</t>

<texttable title="Override JWT Claim Registrations" anchor="fig-iana-claims">
      <ttcol align='left'>Claim Name</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c><spanx style="verb">override_level</spanx></c>
      <c>Override authority level (1-3)</c>
      <c>This document</c>
      <c><spanx style="verb">override_scope</spanx></c>
      <c>Target scope of the override</c>
      <c>This document</c>
      <c><spanx style="verb">override_action</spanx></c>
      <c>Directed action for the agent</c>
      <c>This document</c>
      <c><spanx style="verb">override_reason</spanx></c>
      <c>Human-readable override justification</c>
      <c>This document</c>
      <c><spanx style="verb">override_expiry</spanx></c>
      <c>Override expiration timestamp</c>
      <c>This document</c>
</texttable>

</section>
</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7519">
  <front>
    <title>JSON Web Token (JWT)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7519"/>
  <seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7515">
  <front>
    <title>JSON Web Signature (JWS)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7515"/>
  <seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
  <front>
    <title>Execution Context Tokens for Distributed Agentic Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-dag-hitl-safety" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/">
  <front>
    <title>Agent Context Policy Token: DAG Delegation with Human Override</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
  <front>
    <title>Gap Analysis of IETF Standards for Agentic AI Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

</references>


<?line 676?>

<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

<t>This document absorbs and supersedes the override protocol aspects
of the Human Emergency Override Protocol (HEOP) and the HITL
Primitives specification.  The override level design is inspired
by industrial safety systems (IEC 62061, ISO 13849).  The protocol
integrates with the Agent Context Policy Token
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> for authorization and the
Execution Context Token <xref target="I-D.nennemann-wimse-ect"/> for audit.</t>

</section>


  </back>

<!-- ##markdown-source:
[encoded data, 10492 characters]
fnm0D+dXF3B08tXTr4dNtcc1Z/6//sAcRoG/8bfl/herI6E1mloAAA==

-->

</rfc>

