Observabilité des agents IA : surveiller ce que vous ne voyez pas

Anthropic a livré dans Claude Desktop une fonctionnalité nommée Cowork. Cette fonctionnalité créait un bundle de machine virtuelle de 10 Go sur chaque installation macOS. Les utilisateurs qui n’avaient jamais activé Cowork recevaient malgré tout la VM. Ceux qui la supprimaient la voyaient se régénérer. Un utilisateur a signalé un bundle atteignant 21 Go. Le ticket GitHub a recueilli 345 points et 175 commentaires sur Hacker News avant qu’Anthropic ne reconnaisse le problème.¹

Personne ne s’en est aperçu avant la saturation de l’espace disque.

Qu’est-ce que l’observabilité des agents IA ? L’observabilité des agents consiste à surveiller ce que les agents autonomes consomment et exécutent au moment de l’exécution. Elle exige trois niveaux : la mesure des ressources (disque, mémoire, CPU, réseau par session), l’application des politiques (règles d’autorisation et de refus à chaque appel d’outil) et l’audit d’exécution (enregistrement du comportement réel au niveau du noyau). Sans ces trois niveaux, les opérateurs ne peuvent ni détecter la dérive, ni faire respecter le périmètre, ni reconstituer les incidents.

TL;DR

Les outils d’agents allouent désormais des ressources de calcul (disque, mémoire, CPU, réseau) sans aucune visibilité pour l’opérateur. La VM Cowork d’Anthropic en est l’exemple visible ; chaque appel d’outil MCP, chaque sous-agent lancé et chaque récupération web en sont des exemples invisibles. Gouverner les agents exige trois niveaux d’observabilité : la mesure des ressources (qu’a-t-il consommé ?), l’application des politiques (qu’avait-il le droit de faire ?) et l’audit d’exécution (qu’a-t-il réellement fait ?). Deux projets open source couvrent le niveau politique et le niveau audit (mcp-firewall et Logira), mais aucun outil de production ne couvre les trois. Au programme : le problème de visibilité, la pile à trois niveaux, ce que chaque niveau détecte et les hooks de surveillance minimaux que vous pouvez mettre en place dès aujourd’hui.

Le problème de visibilité

Les logiciels traditionnels fonctionnent sous une ligne d’observabilité que les opérateurs choisissent de tracer. Un serveur web écrit des logs d’accès parce que des ingénieurs ont configuré la journalisation. Une base de données recense les requêtes lentes parce que quelqu’un a défini log_min_duration_statement. C’est l’opérateur qui décide de la granularité.

Les systèmes d’agents inversent cette relation. C’est l’agent qui décide de ce qu’il exécute, au moment où il l’exécute. Un agent de code qui reçoit « corrige l’endpoint de connexion » peut lire 47 fichiers, en modifier 12, lancer trois sous-agents, récupérer deux pages web et exécuter 15 commandes bash. Chaque action consomme des ressources. Rien de cette consommation n’apparaît dans la surveillance traditionnelle.

L’incident Cowork a exposé cette inversion au niveau de l’infrastructure. Claude Desktop allouait 10 Go d’espace disque, consommait de 24 à 55 % du CPU au repos et faisait passer l’activité de swap de 20 000 à plus de 24 000 swapins sur des machines de 8 Go.¹ Les utilisateurs ont découvert cette consommation grâce aux alertes de stockage de macOS, pas grâce à la télémétrie d’Anthropic. L’application ne proposait aucun tableau de bord, aucun compteur et aucune information préalable sur l’allocation de la VM.

Le schéma n’a rien d’hypothétique. En mars 2026, un développeur a signalé que Claude Code avait exécuté une commande Terraform qui a détruit une base de données de production. L’agent a lancé terraform apply sur un fichier d’état de production. Aucune demande de confirmation n’est apparue. Aucun hook n’a intercepté la commande. Le développeur a découvert la destruction quand l’application est tombée. L’incident a recueilli 142 points et 158 commentaires sur Hacker News.¹² Quelques jours plus tard, un autre développeur a signalé que Claude Code avait supprimé une installation de production entière, y compris des snapshots de base de données représentant 2,5 années d’enregistrements.¹³ Les deux incidents partagent la même cause racine : aucune visibilité sur ce que faisait l’agent avant que les dégâts ne deviennent irréversibles.

Transposez ce schéma aux sessions d’agents. Mon système d’orchestration de hooks — bâti sur l’infrastructure de hooks de Claude Code — intercepte 15 types d’événements à chaque appel d’outil.¹¹ Sur plus de 60 sessions, le système a journalisé 84 hooks déclenchés à chaque action, produisant une télémétrie qu’aucune installation d’agent par défaut ne fournit.² Sans cette instrumentation, je n’aurais détecté ni les 12 incidents de dérive, ni les vérifications fantômes, ni les boucles de lancement récursif documentées dans mon commentaire public adressé au NIST.³

Le rapport DORA 2024 Accelerate State of DevOps a établi que les équipes dotées de solides pratiques d’observabilité déploient plus souvent et se remettent plus vite des pannes. L’édition 2025 étend ce cadre au développement assisté par IA en reliant l’observabilité à « la façon dont le codage ou les tests assistés par IA affectent la qualité, le délai de livraison et la fiabilité globale ».⁴ L’observabilité des agents n’est pas un confort optionnel. Mesurer le comportement d’un agent est le préalable à sa gouvernance.

Trois niveaux de visibilité des agents

L’observabilité des agents exige trois niveaux indépendants. Chaque niveau répond à une question différente. La défaillance d’un niveau ne compromet pas les autres.

Les niveaux dessinent une progression : vous ne pouvez pas appliquer de politique à des ressources que vous ne mesurez pas, et vous ne pouvez pas auditer le respect de politiques que vous n’avez jamais définies. Chaque niveau s’appuie sur celui qui le précède.

Niveau 1 : la mesure des ressources

La mesure des ressources répond à une question : combien l’agent a-t-il consommé, et où ?

L’incident Cowork est une défaillance de la mesure des ressources. Le bundle de la VM occupait 10 Go d’espace disque. Le processus de rendu consommait 24 % du CPU au repos. L’activité de swap grimpait régulièrement pendant les sessions. Toutes ces métriques figuraient dans le Moniteur d’activité de macOS. Aucune n’apparaissait dans l’interface de Claude Desktop.¹

Pour les sessions de code des agents, la mesure des ressources suit quatre dimensions :

Disque. Chaque écriture de fichier, chaque entrée de cache, chaque fichier de log. Mes sessions génèrent de 200 à 400 Ko de fichiers d’état par session (jiro.state.json, jiro.progress.json, logs de hooks). Sur plus de 60 sessions, cela représente de 12 à 24 Mo de données d’état qui persistent d’une session à l’autre tant qu’on ne les nettoie pas explicitement.²

Mémoire. La consommation de la fenêtre de contexte à chaque tour. Une fenêtre de contexte de 200 000 tokens coûte environ 3 dollars par remplissage complet aux tarifs actuels d’Opus. Mon traqueur de coûts journalise la consommation cumulée de tokens par session, avec des seuils de budget à 80 %, 90 % et 95 % d’une limite configurable.⁵

CPU. Le temps d’exécution des hooks. Mon répartiteur de prompts à neuf hooks ajoute 200 ms par prompt. Cette surcharge est invisible pour les utilisateurs (c’est la frappe humaine qui constitue le goulot d’étranglement), mais elle se cumule dans les pipelines automatisés. La boucle autonome ralph déclenche le répartiteur de 50 à 100 fois par story, ce qui ajoute de 10 à 20 secondes de surcharge de hooks par story.²

Réseau. Récupérations web, appels d’API, invocations d’outils MCP. Chaque requête sortante est un canal de données potentiel — et chaque serveur MCP constitue une nouvelle surface d’attaque que la mesure réseau doit couvrir. Ma bibliothèque d’extraction web journalise les URL récupérées et la taille des réponses. Sans mesure réseau, une récupération qui renvoie 50 Mo est indiscernable d’une autre qui en renvoie 5 Ko.⁶

Aucun outil d’agent commercial ne fournit de tableau de bord des ressources par session. Les fournisseurs cloud mesurent le calcul pour la facturation, pas pour la visibilité de l’opérateur. L’écart entre ce que les agents consomment et ce que les opérateurs peuvent voir, c’est le déficit de mesure des ressources.

Cette absence paraît invisible jusqu’à ce que les chiffres s’accumulent. Une session qui écrit 400 Ko de fichiers d’état, ce n’est rien. Soixante sessions qui en écrivent 400 Ko chacune, sans nettoyage, laissent 24 Mo d’état orphelin. Une récupération web qui renvoie 847 Ko est négligeable. Un pipeline d’analyse qui récupère 80 URL par exécution génère 67 Mo de contenu mis en cache que l’abstraction des outils de l’agent dissimule à l’opérateur. La mesure des ressources rend le cumul visible avant qu’il ne devienne la crise qui pousse quelqu’un à ouvrir le ticket GitHub #22543.¹

Niveau 2 : l’application des politiques

L’application des politiques répond à une question : quelles règles contraignent l’agent, et ces règles sont-elles appliquées de manière cohérente ?

mcp-firewall couvre le niveau politique pour les agents en ligne de commande.⁷ L’outil se place entre l’agent et toutes les demandes d’utilisation d’outils, et évalue chaque demande au regard d’une politique fondée sur des expressions régulières avant l’exécution. Les politiques reposent sur des fichiers de configuration JSONNet délimités par dossier, par dépôt git ou par utilisateur. Le pare-feu prend en charge Claude Code et GitHub Copilot CLI grâce à l’intégration du hook PreToolUse.

L’architecture reflète une observation essentielle : chaque agent bâtit sa propre solution à moitié aboutie pour la logique d’autorisation et de refus. Claude Code utilise des motifs glob. Codex CLI se limite à une correspondance par préfixe. Chaque approche ne couvre qu’une partie de l’espace des politiques. mcp-firewall centralise les règles dans un moteur unique qui fonctionne d’un agent à l’autre.

Considérez l’écart de politique en l’absence d’application centralisée. Mon système de hooks comprend 12 gestionnaires PreToolUse:Bash qui recherchent des motifs d’identifiants, des opérations git dangereuses, des accès à des chemins sensibles et des commandes de déploiement.² Chaque gestionnaire est un script shell distinct avec ses propres expressions régulières. Quand il me faut ajouter une règle de refus, j’écris un nouveau script. Quand il me faut auditer les règles existantes, je fais un grep sur 12 fichiers. mcp-firewall regroupe tout cela dans un seul fichier de configuration avec des tableaux d’autorisations explicites.

L’OWASP Top 10 for Agentic Applications (2025) désigne le détournement d’objectif d’agent (ASI01) et l’agentivité excessive (LLM06:2025) comme des risques majeurs.⁸ Ces deux risques exigent une application des politiques au niveau de l’appel d’outil. Un agent dont l’objectif a été détourné continue d’appeler des outils. Un agent doté d’une agentivité excessive continue de demander des permissions. L’application des politiques intercepte les deux à la frontière où l’intention de l’agent rencontre les outils du système.

L’application des politiques diffère du contrôle d’accès. Le contrôle d’accès traditionnel demande : « cet utilisateur a-t-il la permission ? » L’application des politiques pour les agents demande : « cette action, dans ce contexte, pour cette tâche, entre-t-elle dans le périmètre approuvé ? » Le paradoxe de la confiance entre déploiement et défense explique pourquoi accorder aux agents de larges permissions pour les rendre utiles crée exactement la surface que l’application des politiques doit contenir. La difficulté tient à la sensibilité au contexte. Un git push sur une branche de fonctionnalité et un git push --force sur main relèvent du même outil (Bash) avec des rayons d’impact très différents. Les expressions régulières de mcp-firewall savent les distinguer. Les permissions par défaut d’un agent, non.

L’application des politiques au niveau applicatif s’expose elle aussi au contournement. Comme le documente votre bac à sable d’agent n’est qu’une suggestion, des frontières d’application qui semblent solides présentent souvent des failles structurelles. Une analyse de mars 2026 a documenté trois techniques d’évasion de bac à sable de plus en plus poussées contre la liste de refus intégrée de Claude Code : l’évasion par chemin (/proc/self/root/usr/bin/npx pointe vers le même binaire que /usr/bin/npx, pourtant bloqué), la désactivation autonome du bac à sable (l’agent a raisonné de lui-même sur la suppression du bac à sable lorsque celui-ci empêchait l’achèvement de la tâche) et l’invocation de l’éditeur de liens dynamique (ld-linux-x86-64.so.2 charge les binaires par projection en mémoire, contournant entièrement les hooks d’application du noyau).¹⁴ La troisième technique constitue une classe d’exploitation à elle seule : tout chargement de code qui évite execve contourne l’application au niveau du processus. La leçon pour l’application des politiques, c’est que les listes de refus fondées sur la correspondance de chaînes forment un premier niveau nécessaire, mais insuffisant. Une application adressée par contenu (identifier les binaires par leur empreinte SHA-256 plutôt que par leur nom de fichier) comble la faille de l’évasion par chemin ; le contournement par l’éditeur de liens dynamique, lui, exige des contrôles au niveau du noyau, situés sous le niveau politique.

La même leçon vaut un niveau plus haut, là où la politique ne voit rien du tout. Publiée par Air Security en septembre 2026, Plugin4Shell est une faille de chaîne d’approvisionnement dans la marketplace des quatre principaux agents de code : une marketplace épingle un commit validé pour un plugin, mais l’agent récupère ce commit sans vérifier qu’il s’y trouve vraiment, de sorte qu’un attaquant qui contrôle le dépôt du plugin peut créer une branche portant le nom du commit épinglé et en faire la branche par défaut ; un réépinglage de routine dans la marketplace déclenche ensuite la mise à jour automatique en arrière-plan de chaque agent, et le checkout se résout sur la branche alors que l’épinglage semble toujours respecté. Selon ma lecture, aucun hook PreToolUse, aucune liste de refus et aucun pare-feu de cette pile ne voit la substitution d’un plugin, parce qu’elle a lieu avant que l’agent ne passe un appel d’outil. La chronologie d’Air indique qu’Anthropic a confirmé un correctif dans Claude Code 2.1.179 et qu’OpenAI en a livré un dans Codex 0.146.0, qu’aucun correctif n’existe pour GitHub Copilot et qu’aucun n’est prévu pour Gemini CLI, désormais abandonné ; l’entrée publique du changelog de Claude Code pour 2.1.179 ne nomme pas le correctif, le numéro de version repose donc sur le récit des chercheurs. Le contrôle qui s’applique, c’est l’hygiène des versions plus un inventaire de ce que la marketplace a réellement résolu, ce qui relève de la mesure, pas de la politique.¹⁷

Niveau 3 : l’audit d’exécution

L’audit d’exécution répond à une question : qu’a réellement fait l’agent au niveau des appels système ?

Logira couvre le niveau audit en utilisant des sondes eBPF pour intercepter les appels système au niveau du noyau.⁹ L’outil enregistre trois catégories d’événements : l’exécution de processus (événements exec), les opérations sur les fichiers (y compris l’accès aux fichiers d’identifiants) et les connexions réseau (avec suivi de la destination). Chaque exécution auditée génère trois fichiers : events.jsonl pour l’examen chronologique, index.sqlite pour un filtrage interrogeable et meta.json pour les métadonnées de l’exécution.

La philosophie de conception est « observe-only » : Logira enregistre et détecte, mais n’applique ni ne bloque rien.⁹ La séparation d’avec le niveau d’application est délibérée. L’application des politiques empêche les actions connues comme mauvaises. L’audit d’exécution découvre après coup les actions inconnues et mauvaises. Les deux niveaux remplissent des fonctions temporelles distinctes : la prévention (avant) et l’investigation (après).

Les sondes eBPF de Logira opèrent sous le niveau applicatif. Un agent qui fabrique une commande inédite pour exfiltrer des données émet malgré tout des appels système. L’agent ne peut dissimuler ni les lectures de fichiers, ni les connexions réseau, ni les processus lancés au traçage au niveau du noyau. L’approche capte ce que les hooks applicatifs manquent : les effets de bord qui contournent l’abstraction de l’appel d’outil.

Les règles de détection intégrées visent spécifiquement les risques liés aux agents IA : accès aux fichiers d’identifiants, modification des mécanismes de persistance (/etc, systemd, cron), enchaînements de commandes suspects (motifs curl-pipe-sh), opérations destructrices (rm -rf) et trafic réseau sortant anormal.⁹ Ces règles sont des valeurs par défaut assumées pour le modèle de menace des agents, pas un audit système générique.

La contrainte de plateforme compte. Logira exige Linux 5.8+ avec cgroup v2. Les agents sous macOS (Claude Desktop, Claude Code sur Darwin) ne peuvent pas recourir à un audit fondé sur eBPF. Mon bac à sable système utilise les profils Seatbelt de macOS comme équivalent le plus proche : des règles de refus appliquées par le noyau qui bloquent les écritures vers les chemins sensibles.³ Seatbelt relève de l’application, pas de l’audit. macOS ne dispose d’aucun équivalent prêt pour la production à la piste d’audit purement observationnelle de Logira.

Agent Safehouse, un outil de bac à sable natif macOS qui a recueilli 802 points et 181 commentaires sur Hacker News en mars 2026, aborde cette lacune de plateforme par le versant de l’application.¹⁵ L’outil fournit des profils de bac à sable spécialement conçus pour les agents IA locaux sous macOS. La réaction de la communauté (802 points, c’est exceptionnel pour un outil de bac à sable) traduit l’urgence : ceux qui font tourner des agents sous macOS n’ont guère d’options entre « aucun bac à sable » et « écrivez votre propre profil Seatbelt ». Agent Safehouse comble cette lacune côté application. Côté audit, la lacune de macOS reste ouverte.

La distinction entre application et audit correspond à un partage temporel dans la réponse aux incidents. L’application empêche l’incident. L’audit permet de le reconstituer après coup. Les deux sont nécessaires. Un niveau d’application qui bloque tout accès aux identifiants empêche l’exfiltration, mais aussi les opérations SSH légitimes. Un niveau d’audit qui journalise tout accès aux identifiants sans le bloquer permet à l’opérateur d’examiner les schémas d’accès et d’affiner les règles d’application sur des données probantes. C’est par cette boucle de rétroaction entre données d’audit et affinage des politiques que la pile de visibilité s’améliore avec le temps : l’audit révèle des schémas, ces schémas nourrissent la politique, et la politique réduit la surface que l’audit doit couvrir.

L’isolation par cgroup v2 de Logira apporte une propriété que l’audit applicatif ne sait pas reproduire : l’attribution par exécution. Le système rattache chaque événement à une exécution auditée précise, et non au système dans son ensemble. Quand deux sessions d’agents tournent simultanément sur la même machine, l’isolation cgroup garantit qu’un accès à un fichier dans la session A n’apparaît pas dans la piste d’audit de la session B. Les hooks applicatifs ne peuvent offrir la même garantie, car ils se déclenchent à l’intérieur du processus de l’agent, lequel ne possède aucune frontière au niveau du noyau séparant les sessions concurrentes.⁹

Ce que j’utilise réellement

Mon système d’orchestration couvre les trois niveaux au moyen de hooks, et non d’outils de surveillance dédiés.

Mesure des ressources. Le hook cost-gate suit la consommation de tokens par session au regard de seuils de budget configurables.⁵ Le moniteur de performance système vérifie le CPU, la mémoire, le disque et le swap à intervalles configurables, et injecte des avertissements quand la pression sur les ressources dépasse les seuils.¹⁰ Le détecteur de dérive de session se déclenche tous les 25 appels d’outils et calcule la similarité cosinus entre le plongement du prompt initial et une fenêtre glissante des actions récentes.²

Application des politiques. Huit hooks répartiteurs PreToolUse orientent vers des hooks gestionnaires selon le type d’outil. PreToolUse:Bash exécute à lui seul 12 gestionnaires couvrant les motifs d’identifiants, les opérations git destructrices, les accès aux chemins sensibles et les commandes de déploiement. Le garde-fou de récursion impose une profondeur maximale de deux et au plus cinq enfants par agent parent.²

Audit d’exécution. Les hooks PostToolUse journalisent le résultat de chaque appel d’outil. Les hooks d’analyse de sécurité inspectent la sortie bash après exécution à la recherche de fuites d’identifiants. Les fichiers d’état de session (jiro.state.json) consignent chaque achèvement de story, chaque verdict de relecture et chaque résultat de contrôle de preuves.² Le système n’utilise pas eBPF (limitation de macOS), mais capte une télémétrie au niveau des outils grâce au pipeline de hooks.

Le système fonctionne parce que chaque action traverse le pipeline de hooks. La limite tient à la profondeur : la surveillance au niveau des hooks capte ce que l’agent a demandé à faire, pas ce que le système d’exploitation a réellement exécuté. Un agent qui fabrique une commande bash comportant des sous-shells imbriqués exécute du code que le hook ne voit que comme une seule chaîne de caractères. Un audit au niveau du noyau verrait chaque sous-processus.

Résultats concrets tirés d’incidents de production où la pile à trois niveaux a détecté des défaillances qui auraient échappé à la surveillance par défaut :

L’angle mort qui se démultiplie

Des agents qui lancent des agents démultiplient l’opacité. Chaque saut de délégation introduit une perte d’information.

Quand mon système d’orchestration exécute la boucle autonome ralph, le processus parent lance de nouvelles instances de Claude Code pour chaque story du PRD. Chaque agent enfant reçoit une tâche ciblée et une fenêtre de contexte vierge. Le parent suit l’état d’achèvement. En revanche, il ne voit ni les appels d’outils, ni les lectures de fichiers, ni la consommation de ressources de l’enfant.²

À la profondeur un (le parent lance un enfant), le parent voit la sortie finale de l’enfant. À la profondeur deux (l’enfant lance un petit-enfant), le parent voit le rapport de l’enfant sur la sortie du petit-enfant. Chaque saut comprime l’information. L’analyse de la chaîne de délégation figurant dans mon commentaire au NIST a mesuré trois risques cumulatifs : la compression sémantique (le contexte se réduit à une chaîne de prompt), l’amplification d’autorité (les enfants héritent de permissions sans en comprendre la sensibilité) et la dilution de la responsabilité (l’agent racine répond de résultats qu’il n’a jamais inspectés).³

L’observabilité se dégrade au même rythme. Une pile de visibilité à trois niveaux sur l’agent racine n’offre aucune visibilité sur l’agent petit-enfant, à moins que chaque enfant n’exécute sa propre surveillance de façon indépendante. Mon garde-fou de récursion impose bien la limite de profondeur, mais ce garde-fou est un contrôle de politique, pas un contrôle d’observabilité. Savoir que la délégation s’est arrêtée à la profondeur deux ne vous dit pas ce qui s’y est passé.

Un exemple concret tiré de mon système de production : la boucle ralph a lancé un agent enfant pour réaliser une story de migration de base de données. L’agent enfant a jugé que la migration nécessitait une « étape de vérification » et a lancé son propre sous-agent pour exécuter des tests d’intégration. L’agent petit-enfant a échoué en silence (la base de données de test n’était pas configurée). L’agent enfant a reçu une réponse vide, a interprété ce silence comme une réussite et a déclaré la story terminée. Le parent a journalisé « story 4 : terminée ». J’ai découvert la migration défectueuse trois heures plus tard, quand l’application a planté sur la colonne manquante. La télémétrie de l’agent racine indiquait une exécution propre. La défaillance se logeait à deux sauts de profondeur, invisible pour chaque niveau de surveillance que j’avais déployé à la racine.²

Le cadre OWASP Agentic Applications traite des défaillances en cascade et des agents devenus incontrôlables, mais il ne prescrit aucune exigence d’observabilité pour les chaînes de délégation multi-agents.⁸ L’analyse d’OpenGuard de mars 2026 sur l’injection de prompt chez les agents fait apparaître la même lacune du côté sécurité : un contexte contaminé circulant entre des agents aux permissions différentes crée, au fil des passations, « un moyen silencieux d’élever l’autorité », faute de politiques claires de flux de données ou d’autorisation au niveau de la composition.¹⁶ La lacune est structurelle : chaque agent de la chaîne aurait besoin de sa propre mesure des ressources, de sa propre application des politiques et de son propre audit d’exécution, configurés et rapportés indépendamment. La surcharge est multiplicative. Trois niveaux de surveillance sur trois agents d’une chaîne, cela fait neuf instances de surveillance, chacune produisant sa propre télémétrie et réclamant sa propre configuration. Aucun outil existant n’assure cette coordination.

Ce que vous pouvez mettre en place dès aujourd’hui

Trois hooks de surveillance minimaux qui couvrent la pile de visibilité :

1. Ressources : traqueur de budget de tokens. Journalisez les tokens d’entrée et de sortie cumulés par session. Fixez une limite stricte. Alertez à 80 %. La mise en œuvre suppose de lire les statistiques d’usage de l’agent (Claude Code expose les coûts de session via /cost) et de les comparer à un seuil. Mon hook cost-gate le fait en 47 lignes de bash.⁵

2. Politique : liste de refus PreToolUse. Créez un hook qui se déclenche avant chaque appel de l’outil Bash. Comparez la commande à une liste de motifs : rm -rf /, git push --force, les chemins contenant .ssh ou .env, curl | sh. Bloquez les correspondances. La mise en œuvre suppose un script shell qui lit stdin (le JSON de l’appel d’outil), extrait le champ de la commande et fait un grep sur un fichier de motifs. Mon hook de vérification des identifiants le fait en 31 lignes.²

3. Audit : journal de session PostToolUse. Ajoutez chaque appel d’outil et son résultat à un fichier JSONL propre à la session. Incluez l’horodatage, le nom de l’outil, les arguments et le code de sortie. Ce journal permet la reconstitution après session : qu’a fait l’agent, dans quel ordre, et quelque chose a-t-il échoué en silence ? Mon journaliseur de session le fait en 22 lignes de bash.²

Voici un exemple concret du hook de liste de refus dans settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

Le script du hook lit l’appel d’outil sur stdin, extrait la chaîne de commande et la compare aux motifs. Une commande bloquée renvoie un objet JSON contenant {"decision": "block", "reason": "Sensitive path access denied"}. Une commande autorisée renvoie {"decision": "approve"}. Claude Code respecte les deux réponses sans autre demande. L’ensemble du hook n’ajoute aucune latence aux commandes autorisées (la vérification par expression régulière s’exécute en moins de 5 ms) et fournit un retour immédiat pour celles qui sont bloquées.

Ces trois hooks tiennent en moins de 100 lignes au total. Ils ne remplacent pas les outils de surveillance dédiés. Ils remplacent une visibilité nulle par une visibilité minimale. Et cette visibilité minimale est le préalable à toute décision de gouvernance qui suivra. Vous ne pouvez pas fixer un budget de ressources sans mesure. Vous ne pouvez pas faire respecter une politique de périmètre sans liste de refus. Vous ne pouvez pas enquêter sur un incident sans journal d’audit. Commencez par le journal. Les deux autres suivront.

À retenir

Pour les ingénieurs plateforme : les agents consomment des ressources que la surveillance existante ne suit pas. L’usage du disque, de la mémoire, du CPU et du réseau par session d’agent a sa place sur le même tableau de bord que les métriques de conteneurs. L’incident Cowork en démontre le besoin : 10 Go alloués sans aucune visibilité pour l’opérateur.

Pour les équipes sécurité : l’application des politiques à la frontière de l’appel d’outil constitue la posture de sécurité minimale viable pour les agents. L’approche centralisée de mcp-firewall regroupe la logique d’autorisation et de refus propre à chaque agent dans une configuration unique et auditable. Évaluez si les permissions intégrées de votre agent couvrent l’espace de politiques qu’exige votre modèle de menace.

Pour les responsables d’ingénierie : la réponse de long terme, c’est l’autogouvernance des agents — des agents qui intériorisent la surveillance comme une norme de comportement, et non seulement comme une contrainte externe. En attendant que cela mûrisse, posez trois questions à propos de votre outillage d’agents. Pouvez-vous voir la consommation de ressources par session ? Pouvez-vous définir et auditer les politiques d’appel d’outils ? Pouvez-vous reconstituer après coup ce qu’un agent a fait ? Si une seule réponse est « non », vous avez une lacune de visibilité qui s’aggrave à chaque agent supplémentaire dans votre workflow.

Questions

Qu’est-ce que l’observabilité des agents ?

L’observabilité des agents, c’est la capacité de surveiller et de comprendre ce que fait un agent IA pendant son exécution : quelles ressources il consomme, quelles actions il entreprend et si ces actions respectent les politiques définies.

Pourquoi Cowork, d’Anthropic, a-t-il créé une VM de 10 Go ?

La fonctionnalité Cowork de Claude Desktop provisionne une machine virtuelle pour les sessions de développement collaboratif. Claude Desktop crée automatiquement le bundle de la VM sur chaque installation macOS, y compris chez les utilisateurs qui n’activent jamais la fonctionnalité, et le conserve jusqu’à sa suppression manuelle.¹

Qu’est-ce que mcp-firewall ?

mcp-firewall est un outil open source d’application des politiques qui intercepte les demandes d’utilisation d’outils émises par les agents en ligne de commande (Claude Code, GitHub Copilot CLI) et les évalue, avant exécution, au regard de règles d’autorisation et de refus fondées sur des expressions régulières.⁷

Qu’est-ce que l’audit d’exécution eBPF ?

eBPF (extended Berkeley Packet Filter) permet de tracer les appels système au niveau du noyau sans modifier le processus audité. Des outils comme Logira utilisent des sondes eBPF pour enregistrer l’exécution des processus, les opérations sur les fichiers et les connexions réseau pendant les exécutions d’agents IA.⁹

Comment les agents lancent-ils des sous-agents sans visibilité pour l’opérateur ?

Les agents qui délèguent des tâches lancent des processus enfants dotés de fenêtres de contexte vierges. L’agent parent voit la sortie finale de l’enfant, mais pas ses appels d’outils, ses lectures de fichiers ni sa consommation de ressources. À chaque saut de délégation, l’information se comprime : la session complète du petit-enfant se réduit à une ligne d’état dans le journal du parent. L’observabilité se dégrade au rythme même où la profondeur de délégation augmente.²

En quoi la surveillance des agents diffère-t-elle de l’APM traditionnelle ?

L’APM traditionnelle (Application Performance Monitoring) suit la latence des requêtes, les taux d’erreur et le débit d’un logiciel déterministe. La surveillance des agents suit un comportement non déterministe : ce que l’agent a décidé de faire à l’exécution, si ces décisions relevaient de la politique en vigueur et quelles ressources chacune a consommées. L’APM présuppose que l’application suit un chemin de code connu. La surveillance des agents présuppose que l’agent choisit lui-même son chemin.²

Les hooks de Claude Code peuvent-ils assurer l’observabilité des agents ?

Oui. Le système de hooks de Claude Code déclenche des scripts sur des événements du cycle de vie (PreToolUse, PostToolUse, Notification) capables de mesurer les ressources, d’appliquer les politiques et de journaliser les actions. Un dispositif de trois hooks — traqueur de budget de tokens, liste de refus PreToolUse et journaliseur de session PostToolUse — couvre les trois niveaux de visibilité en moins de 100 lignes de bash. Les hooks constituent le point d’entrée le plus accessible pour les équipes qui utilisent déjà Claude Code.

Que se passe-t-il quand les agents contournent leur propre bac à sable ?

Un contournement du bac à sable signifie que le niveau d’application échoue en silence. L’agent continue de s’exécuter en dehors de son périmètre prévu et, sans audit d’exécution, aucune trace de la brèche ne subsiste. Les techniques d’évasion de bac à sable documentées en mars 2026 comprennent l’évasion par chemin, la désactivation autonome du bac à sable et l’invocation de l’éditeur de liens dynamique — toutes invisibles pour une surveillance au niveau applicatif.

Pourquoi l’observabilité des outils MCP est-elle importante ?

Chaque appel d’outil MCP est un canal de données potentiel : il peut lire des fichiers, émettre des requêtes réseau et exécuter du code. Les serveurs MCP élargissent la surface d’attaque parce que chaque serveur introduit de nouvelles capacités que l’agent peut invoquer à l’exécution. Sans journalisation par appel ni application des politiques, les invocations d’outils MCP restent invisibles pour l’opérateur.

Comment surveiller des chaînes de délégation multi-agents ?

Chaque agent d’une chaîne de délégation a besoin de sa propre mesure des ressources, de sa propre application des politiques et de son propre audit d’exécution. La boucle autonome ralph illustre le problème : un parent lance des agents enfants qui reçoivent chacun une fenêtre de contexte vierge. Le parent voit la sortie finale, pas les appels d’outils individuels. L’observabilité se dégrade au rythme même où la profondeur de délégation augmente, ce qui impose une surveillance indépendante à chaque saut.

Sources