L'agent qui écrit ses propres logs : pourquoi les journaux d'audit auto-déclarés ne sont pas fiables

En bref Quand un agent IA enregistre lui-même son journal d’audit, l’entité journalisée et l’entité qui écrit le journal ne font qu’un — un agent compromis ou bogué peut donc supprimer, modifier ou inventer des entrées en silence, sans que l’opérateur puisse le détecter. Un article publié le 2 juin 2026, Notarized Agents (arXiv 2606.04193), nomme cette faille structurelle et propose d’inverser la frontière de confiance : laisser le service qui reçoit l’appel de l’agent signer un reçu de ce qu’il a observé. Le draft IETF sur l’audit trail des agents et les travaux SCITT sur les journaux de transparence, datés de la même période, vont dans le même sens. Il s’agit d’une lacune défensive et de gouvernance, pas d’un exploit — mais elle mine toute enquête a posteriori qui suppose que le journal de l’agent dit vrai.

De quoi s’agit-il ?

L’observabilité des agents repose sur une hypothèse discrète : l’agent émet une trace de ses propres appels d’outils, et on fait confiance à cette trace quand un incident survient. Notarized Agents (Juan Figuera, arXiv 2606.04193, soumis le 2 juin 2026) pose le problème sans détour : « l’entité qui produit le journal d’activité est celle-là même dont l’activité est journalisée. » Si un attaquant prend le contrôle de l’agent — ou de l’opérateur qui l’exécute — le journal devient ce qu’il veut qu’il soit. Exfiltration omise, arguments réécrits, approbations fabriquées : tout cela reste invisible à quiconque reconstitue les événements plus tard.

L’enjeu est immédiat car la réglementation va s’appuyer sur ces journaux. Le draft IETF draft-sharif-agent-audit-trail-00 (Raza Sharif) rappelle que l’AI Act européen (Règlement 2024/1689) impose l’enregistrement automatique des événements pour les systèmes à haut risque à compter d’août 2026, et aligne son format sur SOC 2, ISO/IEC 42001 et PCI DSS v4.0.1. Une obligation d’audit ne vaut que par l’intégrité de ce qu’elle audite.

Comment ça fonctionne

La faiblesse n’est pas un payload ; c’est une topologie de confiance. Un agent qui se journalise lui-même se tient des deux côtés de la frontière :

# Trace auto-déclarée (défaut actuel) : un seul rédacteur, aucun témoin
agent --> appel outil --> [l'agent écrit l'entrée] --> stockage
              ^                        |
              \---- le même processus contrôle les deux ----/
# Un agent compromis n'écrit tout simplement pas la ligne compromettante.

Trois conceptions de juin 2026 convergent pour déplacer le rédacteur hors de l’agent :

• Attestation côté receveur. Dans Notarized Agents, le protocole Sello fait signer par le service qui reçoit un appel un reçu de ce qu’il a vu, le chiffre (HPKE) vers la clé publique du propriétaire de l’agent liée au jeton d’autorisation via JWS, et le publie dans un journal de transparence Merkle cosigné par des témoins. Le propriétaire reconstitue ensuite une trace inviolable sans faire confiance à l’agent ni à son opérateur. Les auteurs sont explicites sur les limites résiduelles — attaque par suppression, collusion de services et problème d’incitation à l’adoption.
• Enregistrements chaînés par hachage. Le draft IETF relie des enregistrements JSON par chaînage de hachage SHA-256 (selon RFC 8785) et des signatures ECDSA optionnelles, de sorte qu’une entrée intermédiaire supprimée ou altérée brise la chaîne.
• Transparence en ajout seul. SCITT généralise le schéma : des déclarations signées consignées dans un journal en ajout seul qui émet des reçus vérifiables.

Le geste commun est celui que la Certificate Transparency a fait pour la PKI du web : cesser de demander à l’acteur de se porter garant de lui-même, et ancrer la preuve là où il ne peut pas la réécrire en silence.

Pourquoi c’est important

L’essentiel du débat sur la sécurité des agents porte sur la prévention des mauvaises actions — prompt injection, trifecta létale, validation des arguments d’outils. L’intégrité du journal d’audit concerne ce qui vient après : réponse à incident, forensique, conformité et responsabilité supposent toutes que l’on puisse reconstituer ce que l’agent a réellement fait. Si ce relevé est auto-attesté, une seule compromission d’agent empoisonne toute enquête en aval, et « les logs ne montrent rien » perd tout sens. Avec les obligations de journalisation des systèmes à haut risque qui arrivent en août 2026, la lacune passe de l’académique au réglementaire.

Défenses

1. Considérez l’auto-déclaration de l’agent comme non fiable par défaut. Ancrez les preuves critiques là où l’agent ne peut pas les réécrire — un chemin d’écriture que le processus de l’agent ne contrôle pas.
2. Journalisez côté receveur, pas seulement côté appelant. Faites en sorte que les serveurs d’outils, les serveurs MCP et les API en aval enregistrent ce qu’eux ont observé (identité de l’appelant, arguments, résultat), indépendamment de la trace de l’agent, pour pouvoir recouper les deux.
3. Rendez l’altération détectable. Chaînez les enregistrements par hachage (SHA-256, RFC 8785) et signez-les ; une chaîne rompue ou une signature manquante est un signal de chasse. C’est peu coûteux et disponible dès aujourd’hui, sans adopter un protocole complet.
4. Stockage hors hôte, en ajout seul. Expédiez les journaux vers un puits que l’agent et son opérateur ne peuvent pas purger (stockage objet en ajout seul, SIEM, ou service de transparence). Contrôler le chemin d’écriture, c’est contrôler la vérité.
5. Suivez les standards, n’improvisez pas la crypto. Suivez SCITT, le draft IETF sur l’audit trail des agents et les travaux sur les protocoles de reçus (Signet, SCITT, Sello) plutôt que d’inventer une notarisation maison — et rappelez-vous qu’aucun ne ferme totalement la suppression ni la collusion.

Statut

Élément	Référence	Date	Notes
Notarized Agents / Sello	arXiv 2606.04193	2026-06-02	Reçus attestés côté receveur ; journal de transparence Merkle ; limites suppression & collusion nommées
Agent Audit Trail (AAT)	draft-sharif-agent-audit-trail-00	expire le 2026-09-29	JSON + chaînage de hachage SHA-256 (RFC 8785), ECDSA optionnel ; aligné AI Act / SOC 2 / ISO 42001
Architecture SCITT	draft-ietf-scitt-architecture	Groupe de travail IETF	Journal de transparence en ajout seul, déclarations signées, reçus vérifiables
Journalisation AI Act	Règlement 2024/1689	2026-08 (haut risque)	Enregistrement automatique des événements obligatoire

Le bon cadrage n’est pas « ajouter plus de logs ». C’est qu’un journal écrit par l’acteur qu’il décrit est une déclaration d’intention, pas une preuve. La solution — éprouvée par la Certificate Transparency et désormais portée aux agents — consiste à déplacer le rédacteur hors de l’agent et à ancrer les reçus là où il ne peut pas les modifier en silence.