Résumé

  • L’IETF a créé le 31 août la liste AUDIT, hors groupe de travail, consacrée à l’usage de la délégation et à la traçabilité des interactions par les agents. Cette création ouvre une discussion ; elle n’adopte ni architecture, ni format, ni en-tête.
  • Un identifiant de trace permet de rapprocher des déclarations. Il ne certifie ni leur auteur, ni leur exhaustivité, ni l’autorisation en vigueur, ni l’effet réel. L’audit doit conserver les contradictions, les absences et les différentes horloges.

Prenons un achat qui semble parfaitement documenté. Le journal de l’agent contient la demande de l’utilisateur, une délégation, un appel d’outil et un résultat positif. Le service marchand conserve un débit. Le fournisseur d’identité atteste qu’un jeton était valide. Toutes les lignes portent le même identifiant.

Il reste quatre questions indépendantes : l’utilisateur a-t-il autorisé cet achat précis ; l’autorisation était-elle encore valable au premier effet ; le service a-t-il reçu les mêmes paramètres ; le résultat visible correspond-il au débit ? Une trace peut relier quatre réponses incompatibles. Elle ne choisit pas la bonne.

L’annonce du Secrétariat de l’IETF formule ce besoin. Les agents autonomes traversent des services et des domaines administratifs, alors que journaux, systèmes de traçage et cadres d’autorisation ne corrèlent pas encore de manière interopérable intention, délégations, évolution des permissions et actions. Mais le statut est volontairement modeste : AUDIT est une liste hors groupe de travail. Aucun consensus IETF n’est ainsi créé.

Le joint de corrélation

La recommandation W3C Trace Context montre ce qu’un identifiant portable sait faire. traceparent situe une requête dans un graphe ; tracestate transporte un état propre aux participants. Un intermédiaire peut changer le parent, redémarrer la trace ou modifier l’échantillonnage. Même le bit d’échantillonnage ne garantit pas que les données ont été enregistrées.

La corrélation affirme donc : « ce producteur rattache cette observation à ce graphe ». Elle n’affirme pas : « ce parent a causé cet enfant », « ce graphe est complet » ou « cet acteur avait mandat ». Un service peut recopier un identifiant reçu d’une source non authentifiée. Un agent peut omettre une branche et signer fidèlement ce qui reste.

Le projet d’architecture d’audit des agents propose utilement plusieurs producteurs. L’utilisateur produit des traces d’interaction ; l’agent produit décisions, actions et délégations ; le service produit ce qu’il a observé à sa frontière. L’Auditeur ne doit pas faire confiance à l’agent : il confronte les pièces et décide si elles soutiennent ou contredisent une affirmation de conformité.

Cette pluralité ne supprime pas la confiance. Elle la rend explicite. Pour chaque arête, il faut connaître le producteur, la clé, les champs couverts, le domaine de confiance, la version du schéma et le témoin indépendant éventuel.

Quatre classes, cinq temps

Une trace d’Interaction peut établir ce que l’utilisateur a vu ou approuvé, pas ce que l’agent a exécuté. Une trace de Délégation décrit un transfert revendiqué, pas le pouvoir initial du délégant. Une transition d’Autorisation marque octroi, réduction, révocation ou expiration, mais doit être raccordée à l’état effectif au moment de l’acte. Une trace d’Action décrit un appel proposé ou exécuté ; elle ne prouve pas à elle seule l’effet externe.

Il faut en outre séparer le temps de l’interaction, celui où l’autorisation devient effective, celui où l’agent forme l’acte, celui du premier effet et celui où le journal est créé ou ancré. Le projet Verifiable Agent Conversation Records distingue la création du dossier des horodatages de session. Il rappelle aussi qu’un raisonnement visible peut diverger du processus ayant réellement produit l’action.

Le projet individuel Agent Audit Trail -01 ajoute une notion de phase. Un refus écrit après l’exécution ne prouve pas que l’action a été bloquée avant son effet. Cette pression de conception est saine ; les noms de champs restent une proposition non adoptée.

Des preuves étroites qui se composent

L’échange de jetons RFC 8693 peut porter sujet et acteur selon la politique d’un serveur d’autorisation. Il ne reconstruit pas chaque décision de modèle. L’architecture RATS RFC 9334 permet d’évaluer des preuves sur un environnement ; elle ne fait pas de cet environnement le mandant de l’utilisateur.

L’architecture SCITT RFC 9943 et les reçus COSE RFC 9942 peuvent prouver l’enregistrement et l’inclusion d’une déclaration. Ils ne garantissent pas sa vérité. Une fausse affirmation rendue inaltérable reste fausse.

Les signatures de messages HTTP RFC 9421 authentifient les composants sélectionnés et un signataire. L’application doit encore dire quels composants importent et ce que ce signataire peut affirmer. La canonisation JSON RFC 8785 stabilise les octets à hacher, pas le sens. Un jeton d’horodatage RFC 3161 établit qu’une empreinte existait avant une date sous un modèle de confiance ; il ne date pas automatiquement l’événement raconté.

L’absence et le conflit

Le projet d’architecture reconnaît deux limites : un service hostile peut refuser d’enregistrer sa frontière et une collusion de tous les rôles reste insoluble. Une interface ne doit donc jamais masquer un témoin manquant. Chaque frontière attendue doit avoir un producteur, un délai et un état : observée, absente, tardive, invalide ou contestée.

Si l’agent annonce le succès et le service l’échec, l’Auditeur conserve les deux versions. Si une révocation précède un acte marqué « autorisé », la divergence devient un dossier. Si une chaîne de hachage est valide mais commence après l’étape décisive, son intégrité ne crée pas le fragment absent.

La discipline des couches de réalité de Heng Lu est ici opératoire : lien, signature, attestation, inclusion, autorisation, exécution et résultat ne se transmettent pas mutuellement leur pouvoir de preuve. La primauté du code en fonctionnement place le témoin le plus fort à la frontière indépendante qui pouvait produire ou refuser l’effet.

Une infrastructure d’audit peut devenir une infrastructure de surveillance

Corréler une transaction aide l’enquête ; corréler durablement toutes les actions d’une personne révèle ses relations, ses outils et la forme de son travail. Les projets recommandent empreintes détachées, chiffrement et politiques de conservation parce que les invites, résultats et raisonnements peuvent contenir des données sensibles.

La souveraineté pratique des données suit les copies et les clés. L’organisation qui signe la politique ne contrôle pas nécessairement le magasin d’audit, le graphe de corrélation, le service de transparence ou les exports. Il faut donc limiter l’identifiant global, préférer des identifiants par paire quand le raccordement global n’est pas requis et journaliser l’autorité de chaque requête d’audit.

AUDIT sera utile s’il normalise des preuves que l’on peut confronter. Il échouera s’il normalise une histoire unique que les systèmes racontent sur eux-mêmes.

Sources