Independent Submission B. Morrison Internet-Draft Alter Meridian Pty Ltd Intended status: Informational 3 July 2026 Expires: 4 January 2027 Consented and Attributable Agent Authority for Operational-Technology Control Actions draft-morrison-ot-command-authority-00 Abstract This memo specifies a binding profile by which a control action issued to an operational-technology (OT) or industrial control system on the authority of a software agent is refused unless it carries a verifiable statement of who the agent is, which human principal it acts for, whether that principal consented to this specific action on this specific asset, whether a human authorised the action where the action's risk class requires it, and an append-only record sufficient to attribute the action afterward. The profile does not invent new cryptography or a new identity mechanism. It composes primitives defined elsewhere, DNSSEC-rooted agent discovery, scoped and revocable consent, a human-in-the-loop binding moment, and a provenance-labelled audit record, into a single structure, the Command Authority Envelope, that an OT conduit evaluates and, on any missing or invalid binding, refuses. The profile is availability- first and fails closed on authority, never on safety: it MUST NOT be placed in the trip path of a safety function. The memo maps the profile onto the identification, use-control, and audit requirements that [IEC62443] and [NERCCIP] state but do not give a wire mechanism for. The methods by which a principal's identity is inferred are out of scope by construction. 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." Morrison Expires 4 January 2027 [Page 1] Internet-Draft OT Command Authority July 2026 This Internet-Draft will expire on 4 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. The Command Authority Envelope . . . . . . . . . . . . . . . 4 3.1. Agent identity . . . . . . . . . . . . . . . . . . . . . 4 3.2. Principal reference . . . . . . . . . . . . . . . . . . . 5 3.3. Consent grant . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Binding moment . . . . . . . . . . . . . . . . . . . . . 5 3.5. Audit record . . . . . . . . . . . . . . . . . . . . . . 5 4. Conduit Evaluation and Fail-Closed Behaviour . . . . . . . . 6 5. Risk Classes . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Safety Carve-Out . . . . . . . . . . . . . . . . . . . . . . 7 7. Encoding and Transport Binding . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Two bodies of standards work are moving quickly in parallel, and they do not meet. Morrison Expires 4 January 2027 [Page 2] Internet-Draft OT Command Authority July 2026 One is agent identity for the enterprise cloud. A software agent that acts for a person or an organisation is being given a verifiable identity and a way to authenticate itself, composing existing web and workload-identity primitives. The [WEBBOTAUTH] effort standardises how an automated agent authenticates itself over HTTP, and its charter deliberately declines to bind that key to a human principal. This work is real and useful, and it is scoped to general information systems. It does not address operational technology. The other is operational-technology security. Frameworks such as [IEC62443], [SP80082], and the [NERCCIP] reliability standards govern the industrial control systems that run the electric grid, water, pipelines, and manufacturing. They require that actors be identified (the identification and authentication control family), that use be controlled (the use-control family), and that consequential actions be auditable. They state these as requirements. They do not specify a wire mechanism by which an agent-originated command carries the proof that satisfies them, and the installed base of control protocols (Modbus, DNP3, and their peers) authenticates a command largely by its position on the network rather than by anything the sender proved. The gap between the two is specific and, at present, unserved: there is no interoperable way for a command issued to a control system on the authority of an agent to carry a revocable, auditable, principal- bound statement of the authority under which it is issued, such that a conduit can refuse the command when that statement is absent or invalid. An agent that can write a setpoint to a turbine, open a breaker, or change a treatment dose is a workload whose authority to do so must be provable, scoped, revocable, and attributable after the fact, at stakes where a wrong action is a physical event rather than a corrupted record. This memo specifies that binding. It introduces no new identity mechanism. It composes primitives specified in separate memos into one envelope, the Command Authority Envelope (CAE), that accompanies an agent-originated OT control action, and it specifies the fail- closed behaviour of a conduit that evaluates it. 2. 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 following terms. Morrison Expires 4 January 2027 [Page 3] Internet-Draft OT Command Authority July 2026 Agent: A software actor that issues a control action to an OT system. An agent is a workload with a discoverable identity, not a human. Principal: The human, or the organisation acting through a human, on whose authority the agent issues an action. Control action: A request that changes, or commands the change of, the state of a physical process or of a device that governs one: a setpoint write, a breaker operation, a mode change, a dose change. A read-only observation is not a control action for the purposes of this memo, though a deployment MAY apply the profile to reads. Conduit: In the sense of [IEC62443], the communication path between zones across which a control action travels, and the point at which this profile is enforced. Command Authority Envelope (CAE): The structure defined in this memo that a control action MUST carry to be accepted by a conduit that implements this profile. Risk class: The category assigned to a control action by its potential physical consequence, which determines which bindings the CAE MUST carry. Safety function: A function whose purpose is to bring or hold the process in a safe state, including a safety-instrumented system (SIS). Safety functions are explicitly outside the authority path of this profile (Section 6). 3. The Command Authority Envelope A control action issued on the authority of an agent to a conduit that implements this profile MUST carry a Command Authority Envelope. The CAE is a signed structure carried alongside the control action. Its encoding and transport binding are specified in Section 7. The CAE binds five things. 3.1. Agent identity The CAE MUST identify the issuing agent by a discoverable identifier whose key material is resolvable and verifiable independently of the conduit. A deployment reachable from public DNS SHOULD resolve the agent identifier per [MCPDNS], for which verification is DNSSEC- rooted and fails closed when DNSSEC is absent. The agent's request signature MUST be verifiable per [RFC9421], consistent with [WEBBOTAUTH]. This binding answers "which machine issued this", and nothing more; on its own it is insufficient, which is the gap Morrison Expires 4 January 2027 [Page 4] Internet-Draft OT Command Authority July 2026 [WEBBOTAUTH] leaves open by design. 3.2. Principal reference The CAE MUST carry a reference to the principal on whose authority the agent acts. The reference is a resolvable identity handle, not a bare string. This binding is the one the agent-authentication layer deliberately omits: it names the human behind the machine. A control action whose CAE names no principal MUST be treated as principal-less and refused at any risk class above the lowest (Section 5). 3.3. Consent grant The CAE MUST carry a reference to a scoped, revocable consent grant, per [CONSENT], issued by the principal, that covers this action. The grant MUST name the specific asset (the zone, conduit, device, or point) and the specific control verb it authorises, and it MUST carry an expiry. A grant that names a broader scope than the action does not satisfy this requirement more strongly; it satisfies it exactly to the overlap, and a conduit MUST evaluate coverage against the specific action, not against the grant's breadth. Consent is captured against the action, not inferred from an operator's one-time enrolment. 3.4. Binding moment For a control action whose risk class requires it (Section 5), the CAE MUST carry a binding-moment envelope, per [BINDINGMOMENT], recording that a human authorised this action, with the two-way veto that memo specifies: neither the agent nor the human can railroad the other. The binding moment records a human decision at the moment of consequence; it is distinct from the consent grant, which records a prior, standing authorisation of a scope. 3.5. Audit record The CAE MUST carry, or commit to, an append-only audit record of the action, labelled with a provenance term from the closed vocabulary of [PROVENANCE]. The record MUST be sufficient to attribute the action afterward: which agent, on which principal's authority, under which consent grant, with which binding moment if any, against which asset, at which time per [RFC3339]. The audit record is the artefact that the evidence requirements of [IEC62443] and [NERCCIP] ask for and that no agent-authentication layer today produces. Morrison Expires 4 January 2027 [Page 5] Internet-Draft OT Command Authority July 2026 4. Conduit Evaluation and Fail-Closed Behaviour A conduit that implements this profile MUST evaluate the CAE of every agent-originated control action before the action reaches the process, and MUST refuse the action if any binding required for the action's risk class is absent, malformed, expired, revoked, or unverifiable. Refusal is the default and the safe state for authority. A conduit MUST NOT accept a control action on the ground that the CAE could not be evaluated (for example because a revocation status could not be reached); an unevaluable authority is a refused authority. This is the same posture as the [COMPUTELOC] gate: the conduit refuses the request rather than attempting to prove, cryptographically, that the agent lacked authority. That is an honest and contestable trust boundary, and Section 8 states it as such. Refusal of a control action on authority grounds MUST NOT itself be able to prevent, delay, or gate a safety function (Section 6). The authority path and the safety path are separate, and the profile lives only in the former. 5. Risk Classes A conduit assigns each control action a risk class by its potential physical consequence. The mapping from action to class is a property of the deployment and its process hazard analysis, not of this memo; this memo specifies only which bindings each class requires. A deployment SHOULD align its classes with the Security Levels of [IEC62443]. Three classes are defined; a deployment MAY define finer gradations between them. Observe (lowest): A read of process state. The CAE, if required at all, MUST carry agent identity and an audit record. Principal reference, consent, and a binding moment are OPTIONAL. Adjust (middle): A change within a bounded, pre-authorised safe envelope, for example a setpoint move within an interlocked range. The CAE MUST carry agent identity, principal reference, a consent grant covering the asset and verb, and an audit record. A binding moment is RECOMMENDED and MAY be required by the deployment. State-change (highest): A change of process or device state with Morrison Expires 4 January 2027 [Page 6] Internet-Draft OT Command Authority July 2026 safety or reliability consequence, for example a breaker operation, a mode change, or a change that leaves an interlocked envelope. The CAE MUST carry all five bindings, and the binding moment MUST be present and valid. A conduit MUST refuse a State-change action whose CAE lacks a valid binding moment, without exception, and MUST NOT downgrade an action's class to avoid a binding requirement. 6. Safety Carve-Out This is the requirement the profile refuses to compromise, and it is stated first among the security considerations because it is the one an OT engineer will test first. A safety function MUST NOT be gated on any binding in this profile. A safety-instrumented system, an emergency shutdown, a hardware interlock, a protective relay operating on its own criteria: none of these is an agent-originated control action in the sense of this memo, and none of them MAY be made to depend on the resolution, verification, or revocation status of a CAE. A safety action that a plant would take autonomously MUST remain takeable when every network, every DNS resolver, and every consent endpoint is unreachable. The profile constrains who may command a process to move. It has no authority over the process's own right to protect itself. A design that allowed an identity check to block a trip would be a safety regression introduced in the name of security, and this memo forbids it. 7. Encoding and Transport Binding [This section is deliberately thin in this -00 and is the first place a co-author with OT protocol depth is invited to shape the work.] The CAE is a signed structure. This memo does not mandate a single encoding; it states the requirements an encoding MUST meet and lists the bindings a deployment is expected to specify. An encoding MUST be verifiable offline against a cached trust anchor, because many OT environments are segmented from public networks for long, declared intervals (Section 8). An encoding MUST carry a freshness element (a nonce and an [RFC3339] timestamp with a declared maximum age) to bound replay. An encoding SHOULD ride above, and MUST NOT weaken, the transport security of the underlying session; where the session is [OPCUA], the CAE rides above the OPC-UA secure channel, which proves the channel while the CAE proves the authority. Morrison Expires 4 January 2027 [Page 7] Internet-Draft OT Command Authority July 2026 Transport bindings for specific control protocols are out of scope for this revision and are the natural content of a companion document or a future revision. 8. Security Considerations This section is written to be attacked. Several of the boundaries below are honest and contestable rather than closed, and they are marked as such. Independent review from an operational-technology and critical- infrastructure background is the review this document most needs. Availability over authentication. In OT the priority order is availability, then integrity, then confidentiality, the inverse of the usual information-systems order. This profile is built to that order: it fails closed on authority and never on safety (Section 6), and it refuses rather than blocks. The reviewer should test whether any path in a deployment could let an authority check stall a time- critical control loop; if one exists, the deployment has mis-placed the gate. Refuse, do not prove. A conduit refuses an action whose authority it cannot verify. It does not prove the agent lacked authority. This is a deliberate, contestable boundary inherited from [COMPUTELOC]. An adversary who can make a valid CAE unevaluable can cause refusal, which in an availability-first setting is itself a denial-of-control concern; the mitigation is the offline-verifiable trust anchor and cached revocation state below, and the reviewer is invited to find the residue. Revocation latency versus plant time. A consent grant revoked mid- session MUST stop future actions it covered within a bounded, declared latency. In a plant, that latency competes with real-time control constraints and with intervals of network segmentation. The trade between revocation freshness and offline operability is real and is not fully closed here; a deployment MUST declare its revocation latency budget and its maximum trust-anchor staleness, and MUST NOT let either gate a safety function. Morrison Expires 4 January 2027 [Page 8] Internet-Draft OT Command Authority July 2026 Key distribution in segmented plants. DNSSEC-rooted discovery per [MCPDNS] assumes the resolver is reachable. A segmented or air- gapped plant is not. This profile therefore requires offline verification against a cached trust anchor with a declared staleness bound. The management of that anchor, its rotation, and its revocation across a fleet of long-lived devices is the same lifecycle problem that current OT security guidance identifies as largely unsolved, and this memo does not claim to solve it; it requires only that a deployment state its bound and fail closed on authority when the bound is exceeded. Confused deputy and compromised agent. A valid CAE proves authority, not intent. A compromised agent holding a valid grant can issue any action the grant covers. The mitigations are scope minimality (a grant naming the exact asset and verb, Section 3.3), the binding moment for consequential classes (Section 3.4), and the audit record (Section 3.5) that makes the action attributable after the fact. None of these prevents a first malicious action within scope; they bound its blast radius and guarantee its attribution. Operator as adversary. Consistent with the wider architecture this profile belongs to, the operator of the identity and consent infrastructure is treated as a potential adversary. The consent grant, the audit record, and the standardised, independently verifiable bindings exist so that no single operator is structurally required and every action is visible and attributable, rather than trusting the operator to behave. Scope and the deliberate omission. This memo specifies only the binding and refusal semantics over already-specified discovery, consent, binding- moment, and provenance primitives. The methods by which a principal's identity or trustworthiness is inferred are out of scope by construction, and no such method is described, referenced in detail, or required here. A reviewer does not need those methods to judge the trust model, the fail-closed behaviour, or the safety carve-out, which are the parts that matter for this document. 9. IANA Considerations This document has no IANA actions in this revision. A future revision that specifies a concrete CAE encoding is expected to register a media type and MAY request registries for binding types and risk-class identifiers, per [RFC8126]. Morrison Expires 4 January 2027 [Page 9] Internet-Draft OT Command Authority July 2026 10. Implementation Status This section records the status of known implementations per [RFC7942]. There are no interoperable implementations at the time of this revision. An independent implementation of CAE evaluation at a conduit, against one concrete control-protocol binding, is the strongest near-term signal this document could receive and is explicitly solicited. 11. Contributors A named co-author with chartered-engineer standing in operational technology and critical-infrastructure cybersecurity is being invited to shape the transport binding (Section 7), the risk-class mapping (Section 5), and the security considerations (Section 8). That invitation is open and pending the invitee's consent; no such person is listed as an author of this revision. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . 12.2. Informative References [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Morrison Expires 4 January 2027 [Page 10] Internet-Draft OT Command Authority July 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", 2026, . [CONSENT] Morrison, B., "Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments", 2026, . [BINDINGMOMENT] Morrison, B., "The Binding-Moment Envelope: A Machine- Checkable Shape for Returning a Consequential Decision to a Human Principal", 2026, . [PROVENANCE] Morrison, B., "A Closed Vocabulary for the Provenance of Machine-Generated Statements", 2026, . [COMPUTELOC] Morrison, B., "The Compute-Location Gate: Constraining Where an Identity Inference May Run by the Provenance of Its Input", 2026, . [WEBBOTAUTH] IETF web-bot-auth Working Group, "Web Bot Authentication", 2026, . [IEC62443] International Electrotechnical Commission, "IEC 62443, Security for Industrial Automation and Control Systems", 2018. [NERCCIP] North American Electric Reliability Corporation, "NERC Critical Infrastructure Protection (CIP) Reliability Standards", 2026. Morrison Expires 4 January 2027 [Page 11] Internet-Draft OT Command Authority July 2026 [SP80082] National Institute of Standards and Technology, "NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security", 2023. [OPCUA] OPC Foundation, "OPC Unified Architecture, Part 2: Security Model", 2022. Author's Address Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com Morrison Expires 4 January 2027 [Page 12]