Résumé

  • La révision 01 de draft-kuehlewind-audit-architecture, datée du 7 septembre 2026, ajoute un stockage « in-band » : chaque agent peut exploiter son propre Audit Store et faire circuler les traces sur la connexion utilisée pour l’interaction.
  • Le texte en fait une solution alternative, et non un remplacement du magasin externe ; les deux peuvent coexister. Il précise aussi que l’exploitation par la même partie exige davantage de confiance dans l’opérateur de l’agent.
  • Le stockage ne résume pas l’audit. Le projet distingue encore l’enregistreur, l’Auditing Service, l’attestation, l’inscription dans un registre de transparence, l’auditeur et le vérificateur.
  • Il s’agit toujours d’un Internet-Draft individuel. Le Datatracker indique qu’il n’est pas approuvé par l’IETF et n’a aucun statut formel dans son processus de normalisation.
  • Daniel Kade propose un reçu de topologie de garde qui indique l’opérateur de chaque fonction. Cette proposition éditoriale ne figure pas dans le projet.

Un raccourci technique avec une étiquette de confiance

L’ajout le plus révélateur de la révision 01 tient en un paragraphe. La nouvelle section 3.2 prévoit qu’au lieu d’exporter les traces vers un Audit Store externe et séparé, chaque agent puisse faire fonctionner son propre magasin. Les données peuvent alors être envoyées au magasin de l’agent interlocuteur en réutilisant la connexion existante, sans canal hors bande supplémentaire.

Le choix a des avantages immédiats. Un agent éphémère dispose déjà parfois d’une liaison authentifiée avec son correspondant ; la réutiliser peut réduire les intégrations et suivre plus facilement un travail distribué. Les auteurs ne prétendent pas imposer ce modèle. Ils le décrivent comme une alternative au magasin externe, autorisent une combinaison des deux et inscrivent le coût de confiance dans le texte : quand le magasin et l’agent relèvent du même opérateur, cette partie reçoit davantage de confiance qu’un dépositaire externe indépendant.

Ce passage est bien nouveau. La révision 00, datée de mai, ne comportait pas de section consacrée au stockage in-band. L’événement est donc une modification vérifiable du projet, pas une relecture d’un mécanisme inchangé.

Derrière le mot « audit », plusieurs actes

Le problème n’est pas de déclarer illégitime tout stockage embarqué. Il apparaît lorsqu’un déploiement résume plusieurs fonctions distinctes par la formule rassurante « l’agent est audité ». La révision 01 fournit elle-même les distinctions nécessaires.

Les acteurs principaux produisent des traces depuis des points de vue différents. Le système en contact avec l’utilisateur peut conserver l’intention ou l’autorisation. L’agent peut émettre des signaux d’action, de délégation et de changement d’autorisation. Le service ou l’outil peut enregistrer la requête observée là où l’effet s’est produit. L’Audit Recorder capte ou transforme ces signaux. L’Audit Store conserve et expose les enregistrements. L’Auditing Service les canonise, les signe avec sa propre identité et les soumet à un registre de transparence.

Enfin, un auditeur les apprécie selon une politique ; un vérificateur peut évaluer certaines affirmations.

Chaque fonction répond à une question différente. Le stockage indique où retrouver une trace. Une signature associe une déclaration à une clé. Une attestation étaye des affirmations sur l’environnement producteur. Un reçu de transparence montre qu’une déclaration existait dans un registre à un moment donné et permet de détecter certaines présentations incohérentes. L’indépendance de l’auditeur concerne celui qui porte le jugement. Aucun de ces éléments ne démontre seul que tous les acteurs ont tout enregistré avec exactitude.

Cette précision est d’autant plus importante que le projet admet l’agrégation des rôles. Un rôle est une fonction, pas nécessairement une machine ou une société distincte. Le processus hôte de l’agent peut aussi servir d’enregistreur. C’est simple à déployer, mais le texte identifie alors un risque de collusion avec l’enregistreur et cite comme réponses possibles un enregistreur indépendant ou une preuve de non-répudiation par inscription transparente. Ailleurs, la révision 01 affirme que les propriétés de responsabilité de l’architecture exigent un Auditing Service indépendant.

Il n’y a pas contradiction si l’on conserve les bons noms. Un magasin exploité par l’agent peut transporter et garder des données tandis qu’un service indépendant les canonise ou les engage dans un registre. Un tiers peut héberger le magasin sans exercer le jugement d’audit. À l’inverse, un produit externe peut rester sous le contrôle du même groupe, du même administrateur ou du même détenteur de clés. « Externe » décrit un emplacement ; « indépendant » décrit un pouvoir et des intérêts.

L’adresse du magasin ne prouve pas la garde

Imaginons deux montages. Dans le premier, l’agent écrit dans un magasin de son propre processus, mais un service séparé inscrit aussitôt des engagements signés dans un système de transparence que l’opérateur ne peut pas réécrire seul. Dans le second, l’agent exporte ses traces vers un compte de journalisation en nuage administré par l’équipe qui exploite aussi l’agent, avant tout engagement extérieur.

Le second magasin se trouve à l’extérieur sur le plan géographique. Le premier peut pourtant imposer plus tôt une contrainte historique. Cet exemple ne garantit ni l’exhaustivité ni la conformité de l’un ou l’autre. Il montre seulement qu’un schéma réseau et un nombre de fournisseurs ne remplacent pas un registre de garde.

La RFC 9334 opère une séparation comparable pour l’attestation distante : l’Attester produit des preuves, le Verifier les apprécie et le Relying Party applique sa propre politique. La RFC 9943 sépare elle aussi les déclarations signées, les services de transparence, les reçus et la décision de la partie qui s’y fie. Le nom d’un composant ne suffit pas à fixer un niveau d’assurance ; ce sont les rôles, les politiques, les clés et le trajet de la preuve qui le font.

Enfin, ce projet demeure un travail en cours. Sa fiche ne montre ni flux RFC, ni directeur de domaine responsable, ni adoption par un groupe de travail. Le Datatracker affiche expressément qu’un Internet-Draft individuel ne bénéficie d’aucune approbation de l’IETF. Le nouveau choix de stockage doit donc être présenté comme une proposition en évolution, pas comme une règle de l’IETF applicable aux agents.

Sources