Summary

  • Revision 01 of the proposed Governed Remediation Protocol adds a check for an already admitted (publisher_id, event_id) pair after publisher and session verification but before impact assessment.
  • A duplicate is rejected as ALE-064 / duplicate_event_id and becomes a true no-op, preventing one captured valid event from producing another retry, fallback or human escalation.
  • The admitted-pair set is now security state. Operators still need to decide how it survives crashes, coordinates across receivers and remains atomic with first admission.

A green signature is only one verdict

Suppose a dependency publisher reports that a model gateway is unavailable. Its change event names the affected component and severity, carries the expected session nonce and verifies under the publisher's admitted key. The receiver assesses the impact, selects a fallback and records the action. Then a delivery acknowledgement disappears. A queue sends the byte-for-byte event again.

Nothing about the second copy makes its signature invalid. Nothing changes the session nonce, because the nonce is deliberately constant for that session. The event timestamp is still signed, but a timestamp is a claim about the message, not a memory of what the receiver already admitted. If the receiver treats those three checks as a complete authorization decision, one underlying outage can provoke two interventions.

That is the narrow change in revision 01 of The Governed Remediation Protocol (GRP) for Agentic AI Systems. The Datatracker identifies it as an active individual Internet-Draft. The authors state an intended Standards Track status, but an individual draft may be submitted by anyone and carries no IETF endorsement, consensus or deployment assurance. The relevant news is a proposed control boundary, not a new standard.

GRP describes signed change events concerning dependencies, resources or mandate conditions during an active agent session. Among their required fields are event_id, publisher_id, publisher type and signature, session_nonce, event timestamp, change class, affected component and severity. The draft requires an event identifier to be globally unique within the publisher's stream. Revision 00 already checked publisher authority, signature and session association. Revision 01 acknowledges that those tests still do not prove first arrival.

The receiver must remember admission

The added verification step asks whether the pair (publisher_id, event_id) has already been admitted in the current session. If so, the receiver records ALE-064 with reason duplicate_event_id and discards the copy before repeating impact assessment or any remediation action. The draft calls the result a true no-op: the first admission already created the applicable audit record and response.

Pairing matters. An event_id belongs to a publisher's stream, so an identifier alone is not the complete admission identity. Publisher authentication answers who signed. The session nonce answers which live session the event claims to concern. The pair answers whether this publisher's particular event has already crossed the receiver's admission boundary. These are related checks, not interchangeable proof.

The ordering matters just as much. Duplicate detection after a fallback API call or after a pager notification would document repetition without preventing it. Revision 01 places the test before receiver impact assessment and remediation. That is the smallest authority boundary at which an authentic retransmission can still be made harmless.

The proposal distinguishes replay from a remediation loop. Replay needs one valid event captured and presented more than once. A loop involves multiple genuine transient failures that repeatedly satisfy the protocol's rules. Both may fill an audit trail, but their causes and remedies differ. Deduplication can neutralise a repeated delivery; it cannot decide that a newly generated failure is semantically the same condition.

Cryptography cannot supply receiver memory

The draft's signing context is conventional and useful. JSON Web Signature defines signed JSON mechanics, JSON Web Key defines key representation, and the cited TLS 1.3 profile protects transport. Those standards can support integrity, key handling and authenticated carriage. They do not maintain the set of events a particular GRP receiver has already accepted.

This is a recurring governance mistake in agent infrastructure: a strong answer at one layer is promoted into an answer for the next. A valid signature can show that content verifies under a key. It cannot show that a message is novel. A valid session nonce can bind a message to a session. It cannot show one-time use when that value remains constant. A timestamp can support a future freshness policy, but the reviewed text does not turn it into a substitute for admission state.

The residual risk makes the separation clearer. If a publisher key is compromised, an attacker can mint new signed events with fresh identifiers. The pair check will not call those duplicates. Replay control therefore constrains repeated use of an already admitted message; it does not repair trust in a malicious or compromised publisher.

A precise rule leaves operational questions

Revision 01 says to track admitted pairs for the current session. In the reviewed text, it does not specify the persistence medium, recovery after a receiver crash, garbage collection at session closure, convergence among several receivers or the transaction that joins first admission to the first remediation record. Those are implementation and procurement questions, not proof that the draft is defective.

They are nevertheless decisive. If admission is written only to process memory, a restart can make an old event look new. If two receivers check separate sets concurrently, both can believe they are first. If the pair is recorded before remediation but the process dies between them, recovery needs to know whether to resume, reconcile or suppress. If it is recorded after dispatch, a crash can duplicate the effect. The specification's true no-op promise becomes credible only when the state transition and its consequence are engineered together.

The evidence is bounded. The reviewed sources establish draft text and revision history. They do not establish an implementation, interoperability test, incident, exploit, latency figure or deployment. The SOOS names and audit codes are proposal vocabulary. They should be evaluated as a design, not mistaken for an operating system already in service.

Sources