Les agents IA savent déjà ouvrir des fichiers, appeler des outils et lancer des actions à ta place. Le problème, c’est qu’après coup, il faut parfois jouer à l’archéologue pour comprendre ce qu’ils ont tenté. Docker AI Governance ajoute une brique très concrète : les décisions prises par la politique d’exécution deviennent des événements d’audit consultables dans Docker Cloud et transférables vers un SIEM.
Le journal se place au bon endroit
Un journal classique raconte ce qu’un programme a finalement fait. Il ne voit pas forcément l’action refusée avant son exécution. Docker veut enregistrer la décision au niveau où elle est prise : l’agent demande un accès réseau, un montage de fichier ou un appel d’outil, la politique répond « autorisé », « refusé » ou « validation humaine », et l’événement est conservé.
C’est plus utile qu’un tas de lignes techniques éparpillées sur les machines. Une équipe de sécurité peut enfin distinguer un agent qui travaille dans son périmètre d’un agent qui tente régulièrement de sortir du bac à sable. Le refus devient un signal exploitable, pas un silence embarrassant.
Crédit : Docker, « Docker AI Governance : Audit Logs, Now Where Your Security Team Already Works », https://www.docker.com/app/uploads/2026/07/image-1.png
Docker Cloud ou ton outil de sécurité habituel
La nouveauté annoncée le 3 août tient à la centralisation. Les événements peuvent être recherchés dans Docker Cloud, exportés en CSV et envoyés vers un point HTTPS relié au SIEM de l’organisation. Docker cite notamment Splunk et Dynatrace dans son annonce ; sa documentation mentionne aussi Datadog pour le transfert.
Deux chemins restent possibles. Les événements peuvent être écrits localement en JSON Lines, afin d’être collectés par un agent de journalisation, ou passer par Docker Cloud pour la recherche hébergée et le transfert vers le SIEM. Les deux modes peuvent fonctionner ensemble, ce qui évite de choisir entre visibilité locale et analyse centralisée.
Pour un responsable sécurité, l’intérêt est immédiat : les décisions des agents rejoignent les autres alertes de l’entreprise. Pour une équipe plus petite, le journal consultable et l’export CSV permettent déjà de répondre à une question simple : qu’a fait l’agent, et qu’est-ce que la politique l’a empêché de faire ?
Ce qui est réellement enregistré
Docker insiste sur un point important : les journaux contiennent des métadonnées, pas le contenu des prompts, les réponses de l’agent ni les valeurs des paramètres. Le schéma documenté comprend notamment l’identité de l’utilisateur, l’organisation, l’heure, la session, la cible, la décision et la raison d’un refus. Le type d’action peut préciser une sortie réseau, un montage de système de fichiers, une lecture de ressource ou une invocation d’outil.
Cette sobriété limite l’exposition de contenu sensible, mais elle impose aussi de ne pas confondre audit et enregistrement intégral. Si tu veux relire la conversation de l’agent, ce journal ne suffira pas. Il répond plutôt à la question : « quelle autorisation a été demandée, par qui, sur quelle cible, et selon quelle règle ? »
Le gros astérisque : ce n’est pas pour tout le monde
La fonction fait partie de Docker AI Governance, une offre payante distincte. Elle ne s’active pas simplement parce que Docker est installé : l’organisation doit disposer du plan correspondant, d’un compte Docker d’organisation et d’une politique de gouvernance centralisée effectivement appliquée. Les comptes personnels et les utilisateurs sans licence ne produisent pas ces événements.
La couverture annoncée porte aujourd’hui sur les décisions de politique et les sessions de Docker Sandboxes. Docker promet d’étendre le même schéma à d’autres sources, comme les décisions du MCP Gateway. C’est donc une fondation intéressante, pas encore un historique universel de tout ce que fait chaque agent dans une entreprise.
Autre détail qui compte en production : les fichiers locaux sont écrits d’abord en `.tmp`, puis finalisés en `.jsonl`. Un collecteur doit ignorer les fichiers temporaires et ne prendre que les journaux scellés. La rétention locale reste à la charge de l’équipe, tandis que Docker Cloud propose une fenêtre de conservation annoncée de 90 jours.
Un garde-fou utile, pas une absolution
Ce changement rend les agents plus observables sans prétendre les rendre inoffensifs. Une politique mal conçue peut autoriser la mauvaise action, un SIEM peut noyer les refus dans le bruit et un journal ne remplace ni la revue des règles ni l’analyse humaine. Mais placer l’événement au point de décision corrige un défaut classique : découvrir trop tard qu’un agent a été bloqué, sans savoir ce qu’il avait tenté.
Pour les entreprises qui déploient des agents avec accès au réseau, aux fichiers ou aux outils MCP, c’est une étape pragmatique. La promesse n’est pas « faites confiance à l’IA » ; c’est plutôt « gardez les preuves quand elle demande quelque chose ». Et dans la sécurité, une preuve vaut mieux qu’un agent très convaincant.
Sources
Docker, annonce du 3 août 2026 : https://www.docker.com/blog/docker-ai-governance-audit-logs-now-where-your-security-team-already-works/
Documentation Docker, journaux d’audit AI Governance : https://docs.docker.com/ai/sandboxes/governance/audit/
Documentation Docker, configuration de la livraison : https://docs.docker.com/ai/sandboxes/governance/audit/configure/
Documentation Docker, consultation et transfert SIEM : https://docs.docker.com/ai/sandboxes/governance/audit/view-export/
Documentation Docker, référence du schéma : https://docs.docker.com/ai/sandboxes/governance/audit/record-reference/
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet