Résumé

  • La révision 01 du projet GRP ajoute, après les contrôles de l’éditeur et de la session, un test portant sur le couple (publisher_id, event_id) déjà admis.
  • Une copie reconnue reçoit ALE-064 / duplicate_event_id et doit être éliminée avant l’analyse d’impact, afin qu’un seul événement ne provoque pas deux reprises, replis ou sollicitations humaines.
  • La mémoire des couples admis devient un état de sécurité ; sa persistance, sa cohérence entre nœuds et son atomicité avec la première action restent à contractualiser.

Le deuxième message n’est pas une deuxième réalité

Un éditeur autorisé annonce qu’une ressource indispensable à une session d’agent vient de changer. Le destinataire vérifie la clé, la signature et le nonce de session, puis choisit une mesure compensatoire. Un accusé de réception se perd. Le transport livre une deuxième fois exactement le même événement.

La signature ne se détériore pas pendant le trajet. Le nonce ne devient pas faux : le texte précise qu’il reste constant pendant la session. Même l’horodatage signé ne dit pas si le destinataire a déjà accepté ce message. Ces éléments prouvent des choses utiles, mais aucune ne constitue la mémoire de l’admission.

C’est l’apport ciblé de la révision 01 de The Governed Remediation Protocol (GRP) for Agentic AI Systems. Le Datatracker la classe comme Internet-Draft individuel actif. Le document vise la filière Standards Track selon ses auteurs ; cette intention ne vaut ni consensus, ni approbation de l’IETF, ni preuve de mise en œuvre. L’objet d’analyse est donc une proposition de frontière de contrôle.

GRP formalise des événements signés relatifs à un changement de dépendance, de ressource ou de mandat dans une session d’agent. Un événement comporte notamment un event_id, un publisher_id, le type et la signature de l’éditeur, un session_nonce, un horodatage, une classe de changement, le composant touché et la gravité. L’identifiant doit être globalement unique dans le flux de l’éditeur.

La révision 00 vérifiait déjà l’autorité de l’éditeur, ses justificatifs et l’appartenance à la session. La comparaison directe des textes montre que la révision 01 insère ensuite un contrôle distinct. Le destinataire doit rechercher si le couple formé par l’éditeur et l’événement a déjà été admis pendant la session courante.

Une frontière située avant le pouvoir d’agir

Si le couple existe, le destinataire inscrit ALE-064 avec la raison duplicate_event_id, puis abandonne la copie sans recommencer ni l’analyse d’impact ni la remédiation. Le projet parle d’un véritable effet nul : la première admission a déjà produit l’enregistrement et la réponse applicables.

Le couple est plus précis qu’un simple identifiant. L’unicité de event_id est définie dans le flux de chaque éditeur. L’identité de l’éditeur répond à « qui a signé ? » ; le nonce répond à « quelle session est visée ? » ; l’ensemble admis répond à « cet événement précis de cet éditeur a-t-il déjà reçu le droit de produire une conséquence ? » Confondre ces verdicts revient à demander à une preuve d’identité de faire office d’historique.

Le placement du contrôle ferme la brèche. Une détection effectuée après l’envoi d’une requête de repli ou d’une alerte humaine ne ferait qu’annoter un doublon déjà devenu action. La vérification doit précéder l’évaluation d’impact, car c’est là que le message passe d’un fait déclaré à une autorité opérationnelle.

Le projet distingue également le rejeu d’une boucle de remédiation. Le premier réutilise un événement valide capturé. La seconde résulte de défaillances transitoires réellement nouvelles et répétées. Un ensemble de déduplication arrête le premier mécanisme ; il ne suffit pas à décider que plusieurs événements frais décrivent en réalité une seule panne durable.

L’état local complète la preuve signée

Les RFC citées éclairent les briques. JSON Web Signature permet de signer un contenu JSON ; JSON Web Key représente les clés ; le profil TLS 1.3 protège la communication. Elles peuvent étayer l’intégrité et le transport. Elles ne savent pas si ce récepteur, dans cette session, a déjà admis ce couple.

La leçon de gouvernance dépasse GRP : chaque couche doit rester dans son domaine de preuve. Une signature valide n’établit pas la nouveauté. Un nonce constant rattache un événement à une session sans imposer un usage unique. Un horodatage signé n’est pas une fenêtre d’acceptation tant qu’une règle et un état comparatif ne l’entourent pas.

La limite résiduelle est explicite. Avec une clé d’éditeur compromise, un adversaire peut fabriquer de nouveaux événements signés et leur attribuer de nouveaux identifiants. Le contrôle de couple les verra comme nouveaux. La défense contre le rejeu d’une copie ne remplace donc ni la révocation de clé ni le contrôle de la source.

Une règle claire, une mise en œuvre encore à prouver

Le texte demande de suivre les couples pendant la session courante. Dans les passages examinés, il ne fixe pas la persistance après panne, la synchronisation de plusieurs récepteurs, la collecte à la fermeture d’une session ni la transaction reliant la première admission à la première mesure. Il s’agit de questions d’implémentation et d’achat, pas d’une démonstration d’échec du projet.

Elles déterminent pourtant le résultat. Une table conservée uniquement en mémoire oublie tout au redémarrage. Deux nœuds consultant deux copies peuvent chacun se croire premier. Un arrêt entre l’écriture du couple et l’action oblige à distinguer reprise et nouvelle exécution. Une écriture tardive laisse au contraire l’action partir deux fois.

Les sources attestent le texte et son évolution. Elles ne prouvent ni logiciel opérationnel, ni interopérabilité, ni incident, ni exploit, ni performance mesurée. Les noms de rôles et les codes d’audit appartiennent à la proposition. Ils ne doivent pas être présentés comme l’inventaire d’un service déployé.

Sources