En octobre, le CERT national de l’Inde a publié un avis critique, CIAD-2026-0049, sur des agents IA en évaluation qui ont atteint des systèmes en production d’organisations indiennes et lu des dossiers d’affaires contenant des renseignements personnels et confidentiels. Le détail que tout acheteur de services d’IA devrait retenir : aucune des organisations touchées n’a détecté l’accès. Elles l’ont su parce que les fournisseurs de modèles d’IA l’ont déclaré.
Et c’était le bon scénario. Les fournisseurs ont cherché, ont trouvé l’activité et l’ont dit. Imaginez maintenant le même incident avec un fournisseur qui n’a pas cherché, qui a cherché trop tard, ou qui a jugé que l’événement n’atteignait pas son propre seuil de divulgation. Vous n’auriez rien. Aucune trace de ce qui a été lu, ni quand, ni sous quelle identité. Aucune chronologie à remettre à votre responsable de la protection des renseignements personnels, à votre régulateur ou aux personnes dont les dossiers ont été exposés.
Si la seule trace de ce qu’un agent a fait pour vous se trouve dans le système de quelqu’un d’autre, vous n’avez pas de preuve. Vous avez une dépendance.
C’est quoi, une preuve, pour un agent ?
Les pratiques de réponse aux incidents publiées en octobre par le NIST, la NSA et la CISA sont précises sur ce dont les enquêteurs ont besoin. La pratique 5.3 demande des journaux inviolables, horodatés de façon fiable, suffisants pour reconstituer les trajectoires des agents, leurs tool calls, leurs traces de raisonnement, leurs interactions avec les utilisateurs, l’état de l’environnement et les décisions des contrôles de sécurité. La pratique 5.1 y ajoute les actions et les tool calls refusés, pas seulement ceux qui ont réussi. La pratique 3.3 exige que les agents ne puissent ni accéder aux processus de surveillance et aux journaux, ni les perturber.
Mises ensemble, ces trois pratiques disent une chose claire. La preuve doit être complète, digne de confiance et hors de portée de ce qu’elle enregistre.
Pour la plupart des acheteurs, la console d’un fournisseur échoue sur au moins un de ces points :
- Complétude. Elle montre ce que le fournisseur a choisi d’enregistrer, dans le format qu’il a choisi, pour la période que votre forfait inclut.
- Contrôle. Sa conservation suit la politique du fournisseur et votre niveau d’abonnement, pas la chronologie de votre incident ni votre obligation de conservation à des fins juridiques.
- Indépendance. Pendant un incident qui touche sa propre plateforme, le fournisseur est partie à l’enquête, pas un gardien neutre des registres.
Ça ne rend pas les logs du fournisseur inutiles. C’est une deuxième source précieuse. Ce n’est pas la première.
Ce qu’il faut journaliser chez vous
Vous pouvez détenir l’essentiel de la preuve vous-même, sans la collaboration du fournisseur, parce que les agents agissent à travers une infrastructure que vous contrôlez. Quatre couches en couvrent la plus grande partie.
1. Une gateway pour les tool calls. Faites passer les tool calls et les requêtes d’API des agents par un proxy ou une gateway que vous opérez, plutôt que directement de l’environnement d’exécution de l’agent vers le système cible. La gateway enregistre chaque appel, ses paramètres, son résultat et la décision de politique : autorisé, bloqué ou envoyé en approbation. C’est aussi l’endroit naturel pour appliquer les points d’approbation décrits dans notre billet sur la réponse aux incidents. Un seul point de passage vous donne à la fois le contrôle et la preuve.
2. Les logs du fournisseur d’identité. Si chaque agent a sa propre identité, votre fournisseur d’identité enregistre déjà chaque token émis, chaque ressource atteinte et chaque tentative ratée. Si les agents partagent un compte de service ou empruntent le token d’une personne, ces logs ne peuvent pas distinguer l’activité des agents de celle des humains. Réglez l’identité d’abord ; les logs vont suivre.
3. Les logs de trafic sortant. Enregistrez chaque connexion sortante des hôtes où roulent les agents : destination, port, protocole, volume, résultat. L’avis du CERT-In recommande aux développeurs d’IA de journaliser les destinations, les ports, les protocoles et les résultats de l’activité des agents, et aux organisations de restreindre le trafic sortant par défaut. Une connexion refusée, c’est un quasi-incident que vous pouvez compter.
4. Un stockage non modifiable. Envoyez tout ça vers un stockage que ni l’agent ni ceux qui l’opèrent ne peuvent modifier : un stockage objet avec verrouillage de la rétention, ou une plateforme de logs où la suppression exige un rôle privilégié distinct. Le CERT-In recommande de conserver les journaux au moins 180 jours. Fixez votre durée de conservation selon vos besoins en incidents et en droit, puis assurez-vous que le contrat du fournisseur ne peut pas la raccourcir.
Faites ensuite le test de reconstitution de notre billet sur la réponse aux incidents : si votre fournisseur de modèle disparaissait demain, pourriez-vous reconstituer les 24 dernières heures de votre agent à partir de vos propres registres ? Identité, tool calls, destinations, données touchées, et chaque autorisation et chaque blocage. Si la réponse dépend d’un billet de soutien, vous avez trouvé votre trou.
Ce qu’il faut négocier avec le fournisseur
Vos propres logs couvrent ce que les agents ont fait à travers votre infrastructure. Ils ne voient pas l’intérieur de la plateforme du fournisseur : les prompts et le raisonnement, les outils hébergés chez le fournisseur, l’activité des agents d’autres clients sur une infrastructure partagée. Pour ça, il vous faut le contrat.
On est des praticiens de la sécurité, pas des avocats. Les points ci-dessous sont ceux qu’on demande aux conseillers juridiques de nos clients de vérifier. Ce sont vos conseillers qui décident de leur libellé et de ce qu’exige votre juridiction.
- Exportation des logs. Une API ou une exportation planifiée des logs d’activité des agents, dans un format documenté et lisible par machine, que vous pouvez verser en continu dans votre propre stockage. Pas un tableau de bord, pas un CSV sur demande.
- Une conservation que vous contrôlez. Une durée de conservation écrite au contrat, et la possibilité de geler certains enregistrements pendant un incident ou un litige.
- Délais de notification. Un délai maximal défini pour vous aviser d’un incident de sécurité touchant vos données ou vos agents, avec une personne-ressource nommée de chaque côté. Incluez les tentatives et les quasi-incidents, pas seulement les violations confirmées.
- Transcriptions pendant un incident. L’accès aux transcriptions complètes des sessions, aux tool calls et aux chronologies pour la période touchée. La pratique 8.2 du NIST demande de partager avec les parties touchées des chronologies et des transcriptions détaillées quand c’est possible. Faites-en un engagement, pas une courtoisie.
- Sous-traitants. Une liste à jour des sous-traitants qui traitent vos données ou font rouler vos agents, et un préavis avant tout changement.
- Droit de vérification. Le droit de vérifier le respect de ces conditions, directement ou par un évaluateur indépendant, y compris après un incident.
Pour les organisations québécoises, une partie de ça n’est pas optionnelle. Comme l’explique notre billet sur la Loi 25, l’article 18.3 exige un contrat écrit lorsqu’un fournisseur traite des renseignements personnels pour votre compte. Le contrat doit préciser ses mesures de protection et lui interdire de conserver les renseignements après l’expiration du contrat. Le fournisseur doit aviser sans délai votre responsable de toute violation ou tentative de violation de la confidentialité, et lui permettre d’effectuer toute vérification. Peu de conditions standard des fournisseurs d’IA le prévoient.
Ça se joue avant l’incident
Chacun de ces points coûte peu à obtenir à l’approvisionnement et devient presque impossible à obtenir pendant un incident. À la signature, vous êtes un client que le fournisseur veut gagner. Pendant un incident, vous êtes un client parmi d’autres qui posent tous les mêmes questions pendant que le fournisseur se protège.
Même chose pour votre propre journalisation. Une gateway, une identité par agent, des logs de trafic sortant et un stockage verrouillé se mettent en place en quelques semaines. Reconstituer les actions d’un agent sans eux peut prendre beaucoup plus de temps, et peut même être impossible.
Besoin d’un deuxième regard ?
- Évaluation de la sécurité de l’IA générative. Une revue à portée fixe des identités de vos agents, de vos gateways, de vos contrôles du trafic sortant et de votre journalisation, y compris la question de savoir si les conditions de vos fournisseurs d’IA vous donnent la preuve dont vous auriez besoin pendant un incident. Chaque lacune vient avec un responsable et une correction.
- Soutien à la revue des fournisseurs. On examine les conditions et la documentation de sécurité des fournisseurs d’IA avec vos conseillers juridiques et votre équipe d’approvisionnement, et on traduit les exigences techniques ci-dessus en questions auxquelles le fournisseur doit répondre avant la signature.
Quatre questions à poser à votre équipe
- Pour notre agent le plus privilégié, lesquelles de ses actions sont enregistrées seulement dans le système du fournisseur ?
- Un agent, ou l’équipe qui l’opère, peut-il supprimer ou modifier les logs qui enregistrent son activité ?
- Est-ce que chacun de nos contrats de fournisseur d’IA précise dans quel délai on sera avisés d’une tentative de violation, et nous donne accès aux transcriptions pendant un incident ?
- Si on avait besoin demain des 180 derniers jours d’activité de nos agents, est-ce qu’on interrogerait notre propre stockage ou est-ce qu’on ouvrirait un billet de soutien ?
Si la réponse honnête à la dernière question est « ouvrir un billet », votre preuve appartient à quelqu’un d’autre. C’est un problème d’approvisionnement aujourd’hui, et un problème de réponse aux incidents plus tard.