Summary

  • Revision 07 of the individual Internet-Draft draft-howard-virp was submitted on 6 September 2026 and is dated 7 September. It is not an IETF standard, a Working Group document or an endorsed IETF design.
  • Its new External Authorization Binding profile gives the automation gate a standing read-only device identity and requires a separate authorization service, outside the gate's control, to decide on write commands.
  • The proposed evidence model compares the gate's intent and execution records with device accounting and the external service's permit or deny decision. A missing or unmatched record is classified, not silently treated as proof of success or refusal.
  • The text says static per-command policy and gate-to-device-accounting reconciliation are implemented and have been exercised on Cisco IOS and IOS-XE. Those are author-reported results, not independent proof of broader deployment.
  • The most important part remains unfinished: approval-scoped, time-bounded, single-use write grants are specified but not implemented, and external authorization decisions are not yet first-class entries in the chain.

The credential has moved before the full grant has arrived

The Datatracker history records revision 07 of VIRP as uploaded and accepted on 6 September. The revision itself is dated the following day. Its headline addition is not another AI policy statement. It is an attempt to move the device credential that can change production state away from the automation gate that asks to use it.

Under External Authorization Binding, the gate's standing identity is restricted to observation-class commands. A command outside that class must be denied by the device's own authorization service, rather than merely filtered by software inside the gate. A write-capable identity cannot sit on the gate in a form that becomes usable without a separate decision for that action by a party the gate does not control.

That arrangement matters because a rule enforced only inside a compromised gate is no longer a rule. If the same process holds the privileged credential, classifies the request and records its own result, compromise collapses permission, execution and evidence into one actor. Revision 07 instead makes the device consult an external authority and send authorization and accounting traffic along a path the gate cannot suppress or forge by itself.

The component mechanisms are not new, and the text says so. RFC 8907 defines TACACS+ authorization and accounting. In command-based authorization, a client asks the server whether each command is permitted. Read-only administrative identities are routine operational practice. VIRP's asserted contribution is the composition: treat the autonomous requester as a constrained principal, separate its read and write identities, and then join its account of an action to evidence originating elsewhere.

This is a proposal in an individual Internet-Draft. The Datatracker page explicitly warns that anyone may submit one, that this text is not endorsed by the IETF and that it has no formal standing in the IETF standards process. The design should therefore be judged by the precision of its boundary and the evidence behind its implementation claims, not by the presence of an IETF document header.

Four records, three origins and one missing link

Revision 07 defines four evidence types. gate_intent/1 records what the gate says it is about to do before contacting the device. gate_execution/1 records what the gate says happened afterward. Both are described as implemented. device_accounting/1 carries the device's own command-accounting event, received by an independently reachable collector and chained on receipt. It too is described as implemented as received.

The fourth record is different. authorization_decision/1 is meant to carry the external service's permit or deny decision, including the device, principal, canonical command or digest, result and timestamp. The specification defines that shape, but the reference implementation does not yet emit it into the chain. The decision remains in the authorization service's local log and can be attached to a verification bundle as a separately sourced artifact.

That distinction creates two kinds of refusal. A refusal generated by the VIRP gate is already a chained gate-side event. A refusal generated by the external authorization service is not yet chained. These are not competing descriptions of the same event. They are decisions made at different control points with different evidence status.

The reconciliation vocabulary makes the split visible. A MATCHED action has qualifying gate and device records that agree. GATE-ONLY means the gate says it executed something that the device did not account for within the declared matching window. DEVICE-ONLY means the device accounted for an action with no matching gate execution, including a possible path around the gate. DENIED depends on an authorization-service decision. UNRESOLVED is the correct state when clocks, identity, command digest or available records cannot support a deterministic match.

The join is intentionally strict: device identifier, principal identity and exact digest of the canonical command, plus a declared time window. A device clock that cannot be trusted prevents a time match. The record must stay unresolved rather than being pulled into the nearest plausible action.

This is the useful governance move in the revision. It does not ask readers to trust the gate's story merely because the story is signed or chained. It asks whether an independently sourced device event agrees with that story, and it gives disagreement a durable name.

Accounting is not a universal execution receipt

The most disciplined passage in revision 07 is its refusal to treat command accounting as a universal statement that a command executed. RFC 8907 describes accounting as recording what a user is doing or has done, but its device-administration guidance calls for a start record for every command entered, irrespective of how the command was authorized. Depending on the device, accounting may therefore attest entry rather than authorization or execution.

VIRP requires each deployment to declare what its accounting events mean for each device class: command entered, command authorized, command executed, or unknown execution semantics. Only a device class whose accounting meaning has been established as execution may support an execution classification.

The revision reports a narrower observation from Cisco IOS and IOS-XE: in the exercised systems, a command-accounting event corresponded to an executed command and a denied command produced no such event. The text immediately says not to assume that mapping on other platforms. The referenced implementation repository is maintained by the same project, so it can document what the author claims to have built; it cannot by itself turn those claims into independent reproduction.

Absence is especially dangerous. If a device does not account for denied commands, no accounting event does not mean no attempt occurred. A reliable DENIED result needs the authorization service's decision. Until that decision becomes a chained record, denial evidence remains attached from the service's own log rather than native to the VIRP chain.

Transport also belongs inside the evidence claim. Revision 07 recommends protecting a TACACS+ path and cites the TLS 1.3 profile in RFC 9887 when both sides support it. Independence at the organizational diagram does not survive an AAA path that the gate can intercept, alter or suppress.

The one-use write path is a specification, not current code

The future grant is precise on paper. An issuer other than the gate would verify an enrolled approver's Ed25519 signature bound to the exact canonical command, target device and expiry. A grant meant for one execution would carry a unique approval identifier. The issuer would have to record consumption durably before releasing write authority and reject reuse. Expiry would not substitute for consumption, because an unconsumed approval could otherwise be replayed many times inside its validity window.

The grant would also have to survive the boundary between policy text and device invocation. If a driver renders a canonical operation into different bytes, the deployment must establish that correspondence before claiming that the approval governed what actually ran. Textual policies must be anchored so a longer or compound command cannot match by prefix or embedding. Effective expiry includes the authorization service's propagation delay; a successful reload call does not prove that a revocation has already taken effect if policy changes apply asynchronously.

Revision 07 labels this approval-scoped grant path as not implemented. The described implementation uses static policy: a read-only identity, an operator identity and denial of everything else. Static separation can still reduce blast radius. It is simply not the dynamic chain in which each approved write creates a bounded capability that is consumed once and then disappears.

The same honesty applies to public verification. Revision 07 adds optional per-entry and per-head Ed25519 signatures alongside the mandatory HMAC. They are off by default and enabled per node. A deployment may therefore conform while remaining HMAC-only. The added signature does not transform a gate observation into proof of device truth, and it does not replace the base symmetric guarantee.

A custody receipt for automated writes

An operator evaluating this profile should ask for a compact custody receipt for every write-capable action. It should identify the standing gate identity and prove that it is read-only. It should name the independent authorization service, the exact approved command digest, target, expiry, unique grant identifier and durable consumption result. It should state the policy-propagation delay and the exact device invocation derived from the canonical command.

The receipt should then join the gate intent, gate execution, external authorization decision and device accounting event. It should record the matching window, clock health and device-class accounting semantics. Every conclusion should retain one of the five states rather than forcing uncertainty into success or failure.

That receipt is my recommendation, not a requirement in VIRP, RFC 8907, RFC 9887 or the IETF process. Its purpose is to keep authority and evidence attached across systems. A gate that cannot write is one control. An external service that can grant a write is another. A device that records an event is a third. None may silently borrow the authority or evidentiary meaning of the others.

Sources