Journaliser les actions d'un agent IA : audit et incident

Pourquoi les journaux d'un agent IA sont-ils différents ?

Parce que le comportement n'est pas déterminé par le code : le modèle choisit les actions à partir de textes qu'un tiers peut avoir écrits. Un journal d'application classique dit « la route X a été appelée ». Pour un agent, il faut aussi savoir pourquoi cette action a été choisie et à partir de quelles données.

L'OWASP rappelle, à propos de LLM06:2025 (Excessive Agency), que la journalisation et la surveillance n'empêchent pas un excès d'autonomie, mais en limitent les dégâts en permettant de le détecter. Elle figure aussi parmi les quatre axes de prévention de LLM08:2025 (surveillance et journalisation) et dans les mesures de LLM10:2025 (détection d'anomalies d'usage de ressources).

Côté réglementation, le règlement européen sur l'IA (article 12) exige des systèmes à haut risque une capacité d'enregistrement automatique des événements sur toute leur durée de vie, au service de la traçabilité. Selon le calendrier de l'article 113, cette obligation s'applique à partir du 2 décembre 2027 pour les systèmes de l'annexe III. Tous les agents ne sont pas à haut risque, mais l'article donne une bonne ligne directrice.

Quelles questions un journal doit-il permettre de résoudre ?

Il doit répondre aux cinq questions que posera toute enquête, qu'elle soit d'audit ou d'incident.

1. Qui ? Quel utilisateur, quel client, quelle identité de service a déclenché l'exécution.
2. Quoi ? Quelles actions ont été réalisées, avec quels arguments, sur quels objets.
3. Pourquoi ? Quelles entrées (message, document récupéré, résultat d'outil) ont conduit à cette décision.
4. Avec quelle autorisation ? Quelle règle a permis l'action, ou quel humain l'a validée.
5. Avec quel résultat ? Succès, échec, volume de données touché, effets de bord.

Si une de ces cinq réponses manque, une injection de prompt réussie reste impossible à prouver ou à exclure.

Quoi tracer, événement par événement ?

Tracez chaque étape de la boucle de l'agent comme un événement distinct, sous un identifiant de trace commun. Le tableau liste le minimum utile.

Les conventions sémantiques OpenTelemetry pour l'IA générative, maintenues dans un dépôt dédié, définissent des spans et des attributs pour les appels de modèle, les agents et les outils, y compris MCP. S'appuyer sur un standard évite de réinventer les noms de champs et facilite l'export vers votre outil de supervision.

Que faut-il éviter de journaliser ?

Les secrets et les données personnelles en clair. Un journal d'agent est une copie des conversations : s'il contient tout, il devient la cible la plus intéressante du système.

Les règles de prudence :

• Masquer les jetons, mots de passe, clés d'API et identifiants avant écriture, y compris dans les arguments d'outils et les réponses.
• Minimiser les données personnelles selon les principes du RGPD (minimisation, limitation de la durée de conservation) : empreinte ou extrait plutôt que contenu intégral quand c'est suffisant.
• Cloisonner les accès : seules les personnes qui enquêtent lisent les journaux complets.
• Séparer par client dans un contexte multi-tenant, voir l'isolation des données de chaque client.
• Définir une durée de conservation alignée sur les besoins d'enquête et sur vos obligations.

Il y a un arbitrage à trancher explicitement : un contenu intégral aide l'enquête, mais augmente l'exposition. Une approche courante consiste à garder les métadonnées longtemps et le contenu brut peu de temps.

Comment rendre les journaux fiables pour une enquête ?

En les écrivant hors de portée de l'agent et en les protégeant contre la modification. Un attaquant qui contrôle l'agent ne doit pas pouvoir effacer ses traces ni en fabriquer de fausses.

• Écriture par la couche d'application : le modèle ne choisit pas ce qui est journalisé.
• Stockage en ajout seul ou avec verrouillage, sur un compte distinct de celui de l'agent.
• Horloges synchronisées et identifiants de trace propagés entre l'agent, les outils et les services aval.
• Intégrité : horodatage signé ou chaînage de hachages pour détecter toute altération.
• Corrélation avec les journaux des systèmes aval (base de données, messagerie, API), car la preuve de l'effet réel vient souvent de là.

Piège fréquent : se contenter des journaux du fournisseur du modèle. Ils montrent des appels d'API et ignorent ce que votre application a exécuté ensuite.

Que surveiller en temps réel ?

Quelques signaux simples attrapent la plupart des abus : outil appelé pour la première fois par un utilisateur, volume de lecture inhabituel, appel d'un outil d'écriture juste après la lecture d'un contenu externe, refus de politique répétés, requête vers un domaine inconnu, consommation de jetons anormale.

Définissez des alertes sur ces signaux et un seuil au-delà duquel l'agent est suspendu ou ses outils d'écriture coupés. L'OWASP insiste sur la détection d'anomalies pour l'usage des ressources en LLM10, et les mêmes mécanismes servent à repérer une exfiltration.

Comment s'en servir lors d'une réponse à incident ?

En suivant l'identifiant de trace de l'action suspecte jusqu'à son origine. Une procédure simple :

1. Isoler : suspendre l'agent ou ses outils d'écriture, révoquer les jetons qu'il détient.
2. Identifier le déclencheur : quel message, document ou résultat d'outil a précédé la première action anormale.
3. Mesurer l'impact : quels objets ont été lus ou modifiés, pour quels clients, sur quelle période.
4. Remonter la source : si c'est un passage RAG ou un document, le retirer de l'index et chercher les autres réponses qui l'ont utilisé.
5. Corriger puis rejouer : ajouter le garde-fou manquant et rejouer la trace pour vérifier qu'il bloque.
6. Notifier si des données personnelles sont concernées, selon vos obligations légales.

Un bon test préalable consiste à lancer un incident simulé : demandez à quelqu'un de retrouver, avec vos journaux seuls, le document qui a déclenché une action de test. Si c'est impossible, la journalisation est insuffisante.

À quoi ressemble une entrée minimale pour un appel d'outil ?

C'est une seule ligne structurée contenant l'identifiant de trace, l'utilisateur et le client, le nom de l'outil, les arguments après masquage, la décision de politique, l'approbateur le cas échéant, le code retour et la durée. Avec ces huit champs, vous répondez déjà à qui, quoi, avec quelle autorisation et avec quel résultat pour la plupart des incidents.

Commencez par ce minimum sur vos outils les plus risqués (écritures, envois, paiements, suppressions), vérifiez que vous pouvez rejouer un incident à partir de lui, puis étendez la couverture aux outils en lecture seule et au raisonnement du modèle.

Comment CleanIssue évalue la journalisation d'un agent ?

Pendant un test d'intrusion d'agent IA, nous provoquons des actions marquées (appel d'outil, lecture d'un canari, tentative de franchissement de frontière) puis vérifions si elles sont retrouvables de bout en bout dans vos journaux. Le Red Team Agent Express à 1 900 € inclut ce constat sur un agent, en 5 jours. Nous décrivons notre démarche sur la page méthode. Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.