Consented and Attributable Agent Authority for Operational-Technology Control Actions

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."¶

This Internet-Draft will expire on 4 March 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

Two bodies of standards work are moving quickly in parallel, and they do not meet.¶

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 web-bot-auth effort [WEBBOTAUTH] specifies how an automated agent authenticates itself over HTTP using HTTP Message Signatures [RFC9421], and it 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 an enforcement point 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 an enforcement point that evaluates it.¶

Applicability. The operating condition this profile is written for is a plant that must keep its critical services running through a sustained loss of external connectivity, whether that loss is permanent by design or produced by an isolation event. This is the assumed case rather than an exception the profile tolerates. Nothing in the envelope requires a network path beyond the conduit at the moment of evaluation: an encoding MUST be verifiable offline against cached trust anchors with declared staleness bounds (Section 7), which covers the agent key material, the approver directory and the transparency-log checkpoint alike (Section 8). Where a bound is exceeded the enforcement point fails closed on authority, and never on safety (Section 6).¶

Scope. The actions this profile is written for are those requiring an auditable point in time that ties the user, the command and the authorisation together: an emergency stop, a setpoint pushed outside normal operating parameters, the starting or stopping of a process. More generally, it addresses deployments where traditional control protocols are in use but additional controls on the authorisation of commands are required. It is not a general mechanism for machine-to-machine communication within a plant operating inside its set boundaries.¶

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.¶

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. The principal is the party that issues the authorisation grant (Section 3.3) under which the agent acts.¶

Approver:

A named, accountable human who signs off on a specific control action at the moment of consequence, per [EPRECEIPTS]. The approver need not be the principal, and for a consequential action SHOULD NOT be the agent that initiated the 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. Where a deployment elects to apply this profile to reads, it does so under the Observe class (Section 5).¶

Conduit:

In the sense of [IEC62443], the communication path between zones across which a control action travels. This profile is enforced at the conduit, by the evaluating function this memo calls the enforcement point.¶

Enforcement point:

The function, resident on or at the boundary of a conduit, that evaluates the CAE of an agent-originated control action and refuses the action on any missing or invalid binding. This memo gives the function its own name because [IEC62443] uses "conduit" for a channel grouping rather than for an evaluating function, and the two need to be distinguishable in a sentence. The enforcement point is the conduit's evaluating function; it is not a different place.¶

Command Authority Envelope (CAE):

The structure defined in this memo that a control action MUST carry to be accepted by an enforcement point that implements this profile.¶

Authorisation grant:

A scoped, revocable object, signed by the principal, that authorises a named agent to perform a named control verb on a named asset until a stated expiry (Section 3.3).¶

Binding moment:

A named human's signed authorization of one exact control action at the moment of consequence, carried as human-authorization evidence (Section 3.4). The evidence is the receipt; the interaction that produces it MAY be delivered through the briefing-and-binding envelope of [BINDINGMOMENT].¶

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 an enforcement point that implements this profile MUST carry a Command Authority Envelope. The CAE is a signed structure carried alongside the control action. The bindings it carries are listed below; the mapping from each binding to the composed artefact that supplies its concrete fields is in Section 7. The CAE binds five things.¶

4. Enforcement-Point Evaluation and Fail-Closed Behaviour

An enforcement point 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. An enforcement point 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 enforcement point 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.¶

Evaluation before the action yields one of two outcomes, accept or refuse. The action itself yields a third. Where an enforcement point has accepted a CAE, dispatched the action, and cannot determine from the process whether the action took effect, the outcome is unresolved. An enforcement point MUST NOT report an unresolved outcome as performed, and MUST NOT report it as refused. Reporting it as refused is the worse of the two, because a refusal asserts that nothing reached the process.¶

An unresolved outcome carries no authority forward. Retrying the action is a new control action, requiring its own CAE and, where the action's risk class requires a binding moment, its own binding moment (Section 5). An enforcement point MUST NOT re-present the artefact of an unresolved action, and MUST NOT resolve the outcome by asking the agent what happened.¶

Section 3.4 requires that a binding-moment artefact MUST NOT be usable more than once, and the enforcement point is what makes that hold. An enforcement point MUST record each artefact it accepts as spent, and MUST refuse any later action presenting an artefact already recorded. The record MUST survive a restart of the enforcement point. Spend state held only in volatile memory makes the requirement once per uptime rather than once, and a power cycle is an ordinary event in an OT deployment rather than an exceptional one. An artefact dispatched against an unresolved outcome is spent.¶

Single spend holds only where one enforcement point evaluates every agent-originated control action for a given asset. Where more than one enforcement point can admit an action for the same asset, no single enforcement point can hold the spend record that Section 3.4 requires, and a deployment MUST either scope each asset to a single enforcement point or refuse the action, on the same ground as an unreachable revocation status.¶

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

An enforcement point 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, carried under this profile only where a deployment has elected to apply the profile to reads (Section 2). Where it applies, the CAE MUST carry agent identity and an audit record. Principal reference, an authorisation grant, 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, an authorisation 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 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.¶

An enforcement point 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.¶

Where a State-change action's outcome is unresolved (Section 4), a retry is a new action of the same class. Its binding moment MUST be present and valid in its own right, which means a human decides again.¶

6. Safety Carve-Out

This is the requirement the profile refuses to compromise, and it is stated here, ahead of 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.¶

This is where this profile and [SHARIFICS] part (Section 1.1). A design that rejects a safety-classified command because the issuing agent presented an insufficient trust level has placed an identity check in the safety path. This memo forbids that placement. 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 maps each CAE binding to the composed artefact that supplies its concrete fields. It stops there deliberately. This memo does not mandate, and this revision does not specify, a single outer CAE encoding or a novel wire structure of its own. Where the profile needs a field, it takes it from a primitive already specified elsewhere; where a concrete encoding decision remains, it is named as such and left to a later revision.¶

The CAE is a signed structure. Each binding is filled as follows.¶

An encoding of the CAE MUST meet the following requirements, which are properties the OT environment imposes and are independent of the field map above.¶

An encoding MUST be verifiable offline against cached trust anchors, because many OT environments are segmented from public networks for long, declared intervals (Section 8). The offline-verifiable authorization receipt of [EPRECEIPTS] and the offline COSE inclusion proof of [RFC9942] are chosen for this reason. 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.¶

Transport bindings for specific control protocols are out of scope for this revision. [SHARIFICS] specifies per-protocol signed envelopes for Modbus/TCP, OPC UA, MQTT, and CoAP, and a deployment MAY carry a CAE within such an envelope; the two are complementary below the safety boundary (Section 1.1). The concrete outer encoding of the CAE, how the five bindings above are serialised together into one structure, is 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.¶

Command integrity and diverse-channel confirmation. The CAE binds authority to a control action and makes the action attributable; it is not, on its own, an integrity mechanism for the command value on the wire. The profile requires that an encoding ride above and not weaken the transport security of the underlying session (Section 7), so the command value is protected to the integrity the session provides, and no further. Where a corrupted or spoofed command value is itself a hazard, and in particular where the controlled function carries a safety-integrity requirement at SIL 2 or above in the sense of [IEC61508] and [IEC61511], the transport integrity of a single command path is not sufficient by itself: a deployment SHOULD confirm the commanded state over a channel independent of the command path, for example an independent read-back of the achieved process state, and SHOULD treat a discrepancy as a fault for the process's own safety logic to handle rather than for this profile to handle. Providing such a diverse channel, and meeting a stated SIL target for the end-to-end control function, is a functional-safety engineering task governed by [IEC61508] and [IEC61511]; it is substantial work, it is a property of the deployment and its safety case, and it is out of scope for the authority binding this memo specifies. This memo neither supplies nor weakens that integrity: a diverse-channel confirmation composes beneath the authority profile, and, like every mechanism here, it MUST NOT be placed where it can gate a safety function (Section 6).¶

Refuse, do not prove. An enforcement point 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.¶

Binding-moment forgery and the human-in-the-loop. The gravest failure this profile must exclude is a State-change that executes on no human decision. The requirement that the binding moment be an authorization receipt carrying the approver's own signature over the action digest, verifiable offline and not usable more than once (Section 3.4), is what excludes it: an agent cannot manufacture that signature, and cannot replay a genuine one. One residual surface remains and is stated plainly: the presentation attack of [EPRECEIPTS] Section 11.3, in which an approver may sign a faithful-looking rendering of the wrong action. This memo inherits that residual and the mitigations [EPRECEIPTS] states (render from the hashed bytes, register render templates under the policy, and for the highest classes render the material parameters on a surface the orchestrating operator did not author). It is an enforcement-side obligation this profile places on the enforcement point, not a property it can assume.¶

Revocation latency versus plant time. An authorisation 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. A revocation cannot recall an action already released to the process, and this profile does not close that gap.¶

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 cached trust anchors with declared staleness bounds, for the agent key material, the approver directory of [EPRECEIPTS], and the transparency-log checkpoint of [RFC9943]. The management of those anchors, their rotation, and their 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 bounds and fail closed on authority when a 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, verb, and agent, Section 3.3), the binding moment for consequential classes (Section 3.4), which a compromised agent cannot forge because it carries a human's own signature, 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 authorisation grant is signed by the principal and not the operator; the binding moment is signed by an approver key the operator does not hold (Section 3.4, and the corresponding guarantee in [EPRECEIPTS]); the audit record is a SCITT signed statement on an append-only log whose checkpoint the operator cannot rewrite undetectably ([RFC9943], [RFC9942]). These 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, authorisation, human-authorization, and transparency 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. Deployment and Incremental Adoption

This profile is meant to be adopted incrementally, alongside the installed base rather than in place of it. The enforcement point (Section 2) is an added function at a conduit boundary; it does not replace a control protocol, a safety system, or a historian, and a deployment can introduce it for one asset class or one high-consequence verb before extending it. The authority bindings compose above existing per-protocol transports, including the signed control-protocol envelopes of [SHARIFICS] where those are deployed, so a site that has already invested in a transport binding keeps that investment.¶

Adoption of a profile like this depends on the integrating parties, the control-system vendors, the asset owners, and the operators of the discovery, authorisation, and transparency primitives, each investing in the integration on its own side, and a specification alone does not create that investment. This memo takes the position that the incentive most likely to carry that investment without a mandate is that the profile discharges an obligation the deployer already holds rather than adding a new one. [IEC62443] and the [NERCCIP] reliability standards already require that consequential actions be identified, use-controlled, and auditable; a deployer meets those requirements today with bespoke, non-interoperable, and often manual evidence. The append-only, independently verifiable audit record this profile carries (Section 3.5) turns that standing, unfunded compliance obligation into a concrete and reusable mechanism, which lowers an existing cost rather than imposing a new one. The concrete integration path on each party's side, and the commercial and operational incentives that make a given party invest, are deployment matters beyond the scope of this memo and are the natural content of a companion deployment document.¶

10. 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].¶

11. Normative and Informative References

Several references in this document are normative because an implementer requires them to construct or verify a Command Authority Envelope, yet they are individual Internet-Drafts rather than published standards: the Morrison-family memos [CONSENT], [BINDINGMOMENT], and [MCPDNS], and the Schrock EMILIA-Protocol memos [HUMANAUTHBIND] and [EPRECEIPTS]. A normative reference to a work in progress will hold this document in the RFC Editor queue until the referenced drafts are published or the references are re-scoped; the authors acknowledge this and expect to revisit the normative and informative split as the referenced work matures. The remaining normative references are to published standards: [RFC9421], and the transparency pair [RFC9943] (SCITT) and [RFC9942] (COSE Receipts).¶

12. Implementation Status

This section records the status of known implementations in accordance with [RFC7942]. It is intended to assist the IETF in its decision processes for this document. The description of implementations in this section is intended neither to describe those implementations as complete or correct nor to endorse them; the listing of an implementation here does not imply endorsement by the IETF. This section is expected to be removed before the document advances beyond the Independent Stream.¶

There are no interoperable implementations of the Command Authority Envelope at the time of this revision. Several of the composed primitives have running code. The EMILIA Protocol implementation ([EPCONSENTGRANT], [EPCAEPROFILE]) reports three same-team reference ports, in JavaScript, Python and Go, agreeing across 17 suites and 193 conformance vectors, together with an externally authored Rust implementation built from a pinned public source tree that passes a clean-room subset of those vectors. [MCPDNS], [BINDINGMOMENT] and [COMPUTELOC] each report a reference deployment. An independent implementation of CAE evaluation at an enforcement point, against one concrete control-protocol binding, is the strongest near-term signal this document could receive and is explicitly solicited.¶

13. Contributors

Iman Schrock (EMILIA Protocol, Inc.) contributed the substance of the authorisation-grant row in Section 3.3. Reviewing the -00 bindings, he identified that no artefact then existed meeting the standing-grant requirement, and declined to present an object he already had as meeting it. He then specified and implemented EP-CONSENT-GRANT-v1 [EPCONSENTGRANT], and profiled it against these bindings row by row [EPCAEPROFILE]. The separation held in Sections 3.3 and 3.4, under which a per-action artefact at the binding moment never rounds up into a standing authorisation, was settled in exchange with him.¶

He also identified both gaps this revision closes. Section 4 spoke only before the action and so carried no vocabulary for an outcome that is unresolved, and the single-spend property asserted in Section 3.4 was never made to survive a restart of the enforcement point, which would have held it once per uptime rather than once.¶

14. References

Authors' Addresses