Pistes d'audit pour agents IA : journalisation complète et infalsifiable

Une piste d'audit pour agents IA est la journalisation complète et infalsifiable de l'ensemble des décisions, appels d'outils, accès aux données, opérations de mémorisation et validations humaines d'un agent. Elle rend le comportement autonome traçable sur le plan forensique, remplit les obligations réglementaires de journalisation et fournit, en cas de dommage, la preuve de qui ou quoi a déclenché une action. Contrairement à la journalisation applicative classique, elle doit permettre de reconstituer le chemin de décision propre à l'agent.

• Ce qui est journalisé : prompt, version du modèle/hash de configuration, séquence d'appels d'outils avec arguments, requêtes de récupération et identifiants de documents, output avec justification, interventions humaines, événements de mémoire, coût et latence.
• Comment la protéger : stockage WORM (Write-Once-Read-Many) et signature cryptographique pour détecter les altérations ; externalisation vers le SIEM, hors de portée de l'agent.
• Pourquoi c'est nécessaire : obligations de journalisation du règlement européen sur l'IA, principe de responsabilité du RGPD et analyse forensique après des incidents qui s'aggravent plus vite que la réponse aux incidents classique ne peut les contenir.

Pourquoi les agents ont besoin de leur propre piste d'audit

Les applications LLM classiques se contentent de répondre : un prompt entre, une completion sort. Les systèmes agentiques, eux, planifient, raisonnent, choisissent des outils, écrivent en mémoire et agissent avec une validation humaine minimale à chaque étape. Ce sont précisément ces caractéristiques (autonomie, utilisation d'outils et état persistant) qui produisent un chemin de décision que les journaux classiques de requêtes et réponses ne reflètent pas.

Dans le modèle de l'OWASP pour les applications agentiques (ASI01–ASI10, publié le 9 décembre 2025), la traçabilité n'est plus un risque à part entière du Top 10 : elle est intégrée à l'ensemble. L'ancien thème du brouillon « Repudiation & Untraceability » se trouve aujourd'hui dans ASI03 (Identity & Privilege Abuse), complété par des exigences transversales de journalisation. La piste d'audit est donc un contrôle transversal qui permet d'élucider plusieurs classes de risques.

Trois exemples tirés des travaux de l'OWASP illustrent ce besoin :

• ASI06 : Memory & Context Poisoning : une seule attaque par injection réussie peut empoisonner durablement la mémoire persistante ; un signal de détection central est le fait que l'agent « se souvienne » d'instructions pour lesquelles il n'existe aucun enregistrement de provenance. Sans journaux fondés sur l'origine, cette preuve est impossible.
• ASI08 : Cascading Failures : selon les travaux de Galileo AI (décembre 2025), un seul agent compromis a empoisonné, lors de simulations, 87 % des décisions en aval en l'espace de 4 heures, soit plus vite que la réponse aux incidents classique ne peut le contenir. Seul un journal complet des échanges entre agents permet de reconstituer la propagation.
• ASI10 : Rogue Agents : dans la synthèse threat-to-control, « Audit » est, aux côtés des lignes de base comportementales continues et du kill switch, l'un des contrôles clés pour détecter un désalignement persistant dans le temps.

Ce qu'il faut journaliser

Les travaux de l'OWASP (section 7.6, Audit logging) définissent le périmètre forensique minimal par action de l'agent, c'est-à-dire pour chaque action individuelle et non par session :

L'essentiel réside dans les métadonnées de provenance : chaque entrée de mémoire devrait consigner la source, l'horodatage, le chemin d'ingestion et le niveau de confiance. Dans la logique de l'OWASP, les écritures en mémoire sont des événements pertinents pour la sécurité. Une entrée n'arrive dans la mémoire persistante que par une opération d'écriture explicite et auditée, jamais de manière implicite.

Infalsifiabilité : WORM et signature cryptographique

Une piste d'audit n'est crédible que si elle est immuable. Si un agent compromis, ou un attaquant disposant de ses droits (ASI03 : « l'attaquant hérite des autorisations de l'agent »), peut modifier les journaux après coup, leur valeur probante forensique disparaît. Les modèles cités dans les travaux :

• Stockage WORM (Write-Once-Read-Many) : des journaux immuables, impossibles à modifier une fois écrits.
• Signature cryptographique : chaque entrée du journal est signée, de sorte que toute manipulation devient détectable (tamper detection).
• Intégration SIEM : les journaux sont centralisés et se trouvent hors de portée de l'agent et de ses autorisations sur les outils.

Dans la logique de menaces STRIDE classique, cela couvre la catégorie Repudiation (répudiation), conservée dans l'adaptation STRIDE for AI de Microsoft. En complément : si les exécutions de code sont journalisées, les écritures dans des fichiers de configuration en dehors de la gestion des changements habituelle et le lancement de sous-processus doivent aussi figurer dans la piste (signaux de détection issus d'ASI05).

Pourquoi c'est nécessaire : obligation de journalisation, responsabilité, analyse forensique

Le moteur réglementaire est triple. Premièrement, le règlement européen sur l'IA exige pour les systèmes d'IA à haut risque un enregistrement automatique des événements tout au long de leur cycle de vie (enregistrement, art. 12), complété par l'art. 14 (contrôle humain) et l'obligation de surveillance après commercialisation de l'art. 72. Selon l'Omnibus numérique (règlement (UE) 2026/1744), les art. 12 et 14 ne s'appliquent qu'à partir du 2 décembre 2027 pour les systèmes relevant de l'annexe III et à partir du 2 août 2028 pour ceux relevant de l'annexe I. Les travaux de l'OWASP rattachent en outre les risques agentiques à l'art. 15 (robustesse, cybersécurité) et précisent que les déployeurs doivent lire les catalogues de menaces de type OWASP en plus de l'art. 15, car en mai 2026 les normes harmonisées ne comblent pas encore de nombreuses lacunes.

Deuxièmement, le principe de responsabilité du RGPD (art. 5, paragraphe 2, art. 24) exige de démontrer la mise en œuvre de mesures techniques et organisationnelles appropriées, dont la sécurité du traitement prévue à l'art. 32. Les travaux rattachent plusieurs risques directement au RGPD. Ils associent ainsi ASI03 à l'art. 32, paragraphe 1, point b) (confidentialité et intégrité des systèmes) et à l'obligation d'agir sur instruction prévue à l'art. 32, paragraphe 4. Cette disposition concerne les personnes physiques agissant sous l'autorité du responsable du traitement ou du sous-traitant. Transposé à l'agent, cela signifie qu'il ne peut agir que dans le cadre des instructions du responsable du traitement, sans être lui-même un sous-traitant. Ils associent ASI06 à l'art. 5, paragraphe 1, point d) (exactitude) et à l'art. 17 (droit à l'effacement). Les processus de suppression de la mémoire doivent donc être alignés sur l'art. 17, et c'est précisément ce qu'il faut à son tour documenter.

Troisièmement, la piste d'audit fournit l'analyse forensique. Lors de l'incident Manufacturing Procurement Cascade (2025), un agent d'achat a été progressivement convaincu, sur trois semaines, que son plafond d'autorisation s'élevait à 500 000 USD ; l'attaquant a ensuite passé 5 millions USD de fausses commandes en 10 transactions. Seule une piste complète des écritures en mémoire, des appels d'outils et des événements d'intervention humaine permet de reconstituer a posteriori une telle évolution de type « boiling frog » et de vérifier la chaîne de validation humaine.

Pour les secteurs réglementés en Autriche et en Allemagne s'ajoutent des cadres européens : NIS2 (contrôle d'accès et gestion des actifs, art. 21(2)(i)) ainsi que DORA, avec la gestion et la notification des incidents liés aux TIC (art. 17–23) pour les prestataires de services financiers. Dans le cadre de l'ISO/IEC 42001, la piste d'audit est ancrée dans le contrôle A.6.2.8 (journalisation), complété par A.6.2.6 (exploitation et surveillance).

Conservation par secteur

Le règlement européen sur l'IA fixe un plancher pour les systèmes d'IA à haut risque : les fournisseurs (art. 19, paragraphe 1) et les déployeurs (art. 26, paragraphe 6) doivent conserver les journaux générés automatiquement, dans la mesure où ils sont sous leur contrôle, pendant au moins six mois, sauf disposition contraire du droit de l'Union ou du droit national. S'y ajoutent des délais sectoriels :

Cet article ne constitue pas un conseil juridique. Les délais concrets, les numéros d'articles applicables et les obligations sectorielles, tu les clarifies au cas par cas avec ton service juridique et conformité.

Exemple pratique : enregistrement d'audit d'une action d'outil

Voici à quoi pourrait ressembler, en pseudocode, une entrée unique, signée et stockée sur un support WORM. Chaque champ correspond au standard minimal de l'OWASP :

```
audit_event {
event_id: "a1f9-…" // unique, fait partie de la signature
agent_id: "procurement-agent-07" // ASI03: Non-Human Identity
timestamp: 2026-06-09T08:14:22Z
model: { version, config_hash }
prompt: { user, system, injected_context }
retrieval: [ { query, doc_ids[] } ]
tool_call: { name: "create_purchase_order",
args: { amount: 5_000_000, vendor: "…" } }
rationale: "Order aligns with stored authorization limit"
memory_read: [ { key: "auth_limit", provenance: NULL } ] // <- alerte
human_override: { approver: "none", action: "auto-approved" } // <- alerte
cost: { tokens, usd }
signature: "sig:…" // détection cryptographique des altérations
}
```

Deux champs constituent ici les véritables pépites forensiques : la lecture en mémoire avec provenance: NULL montre que la valeur d'autorisation n'a aucune origine vérifiable (signal ASI06), et l'absence d'intervention humaine sur une transaction de 5 millions prouve qu'une étape de validation a été contournée (ASI09). Sans ces champs, l'incident n'aurait pas pu être élucidé.

Pour les agences et les décideurs B2B

Mettre des agents dans des processus de production déplace la charge de la responsabilité et de la preuve : en cas de litige ou de contrôle, seul compte ce qui a été journalisé de manière démontrable. Les agences marketing qui construisent des workflows d'agents pour leurs clients devraient traiter les pistes d'audit dès le départ comme une exigence d'architecture, et non comme une journalisation ajoutée après coup. Basée à Vienne, Blck Alpaca accompagne les entreprises en Europe dans la conception de systèmes agentiques dotés de pistes d'audit solides sur le plan forensique et conformes à l'OWASP et à l'ISO 42001, des métadonnées de provenance au stockage WORM jusqu'à la connexion au SIEM. L'autonomie reste ainsi traçable et résiste aux audits.