L'agent invisible : pourquoi vous ne pouvez pas gouverner ce que vous ne voyez pas

Anthropic a lancé une fonctionnalité appelée Cowork dans Claude Desktop. 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 tout de même la VM. Ceux qui la supprimaient la voyaient se régénérer. Un utilisateur a signalé que le bundle avait atteint 21 Go. L’issue GitHub a recueilli 345 points et 175 commentaires sur Hacker News avant que Anthropic ne reconnaisse le problème.¹

Personne ne s’en est aperçu jusqu’à ce que l’espace disque soit épuisé.

TL;DR

Les outils d’agents allouent désormais des ressources de calcul (disque, mémoire, CPU, réseau) sans visibilité pour l’opérateur. La VM Cowork de Anthropic est l’exemple visible ; chaque appel d’outil MCP, chaque sous-agent créé et chaque récupération web est un exemple invisible. Gouverner les agents nécessite trois couches 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 à l’exécution (qu’a-t-il réellement fait ?). Deux projets open source couvrent les couches politique et audit (mcp-firewall et Logira), mais aucun outil en production ne couvre les trois. Ci-dessous : le problème de visibilité, la pile à trois couches, ce que chaque couche détecte, et les hooks de surveillance minimaux que vous pouvez implémenter dès aujourd’hui.

Le problème de visibilité

Les logiciels traditionnels opèrent en dessous d’une ligne d’observabilité que les opérateurs choisissent de tracer. Un serveur web écrit des journaux d’accès parce que les ingénieurs ont configuré la journalisation. Une base de données suit les requêtes lentes parce que quelqu’un a défini log_min_duration_statement. L’opérateur décide de la granularité.

Les systèmes d’agents inversent cette relation. L’agent décide quoi exécuter au moment de l’exécution. Un agent de développement qui reçoit « corriger l’endpoint de connexion » pourrait lire 47 fichiers, écrire dans 12, créer 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 a alloué 10 Go d’espace disque, consommé 24 à 55 % du CPU au repos, et fait grimper l’utilisation du swap de 20 000 à plus de 24 000 swapins sur les machines de 8 Go.¹ Les utilisateurs ont découvert la consommation de ressources via les avertissements de stockage macOS, et non via la télémétrie de Anthropic. L’application ne fournissait aucun tableau de bord, aucun compteur et aucune divulgation avec consentement pour l’allocation de la VM.

Transposez ce schéma aux sessions d’agents. Mon système d’orchestration par hooks intercepte 15 types d’événements pour chaque appel d’outil.¹¹ Sur 60 sessions, le système a enregistré 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 pas détecté les 12 incidents de dérive, les échecs de vérification fantôme, ni les boucles de création récursive documentés dans mon commentaire public au NIST.³

Le rapport DORA 2024 Accelerate State of DevOps a constaté que les équipes disposant de pratiques d’observabilité solides déploient plus fréquemment et se remettent plus rapidement des défaillances. L’édition 2025 étend le cadre au développement assisté par l’IA, reliant l’observabilité à « la manière dont le codage ou les tests assistés par l’IA affectent la qualité, le délai de mise en production et la fiabilité globale ».⁴ L’observabilité des agents n’est pas un luxe. Mesurer le comportement des agents est un prérequis pour les gouverner.

Trois couches de visibilité des agents

L’observabilité des agents nécessite trois couches indépendantes. Chaque couche répond à une question différente. Une défaillance dans une couche ne compromet pas les autres.

Les couches correspondent à une progression : vous ne pouvez pas appliquer de politique sur des ressources que vous ne mesurez pas, et vous ne pouvez pas auditer la conformité à des politiques que vous n’avez jamais définies. Chaque couche s’appuie sur celle qui la précède.

Couche 1 : Mesure des ressources

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

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

Pour les sessions de codage avec agent, la mesure des ressources suit quatre dimensions :

Disque. Chaque écriture de fichier, chaque entrée de cache, chaque fichier journal. Mes sessions génèrent 200 à 400 Ko de fichiers d’état par session (jiro.state.json, jiro.progress.json, journaux de hooks). Sur 60 sessions, cela s’accumule à 12-24 Mo de données d’état qui persistent entre les sessions à moins d’un nettoyage explicite.²

Mémoire. Consommation de la fenêtre de contexte par tour. Une fenêtre de contexte de 200 000 tokens coûte environ 3 $ par remplissage complet aux tarifs actuels d’Opus. Mon tracker de coûts enregistre l’utilisation cumulée de tokens par session, avec des seuils budgétaires à 80 %, 90 % et 95 % d’une limite configurable.⁵

CPU. Temps d’exécution des hooks. Mon dispatcher à neuf hooks ajoute 200 ms par prompt. Cette surcharge est invisible pour les utilisateurs (la saisie humaine est le goulot d’étranglement) mais se cumule dans les pipelines automatisés. La boucle autonome ralph déclenche le dispatcher 50 à 100 fois par story, ajoutant 10 à 20 secondes de surcharge de hooks par story.²

Réseau. Récupérations web, appels API, invocations d’outils MCP. Chaque requête sortante est un canal de données potentiel. Ma bibliothèque d’extraction web enregistre les URL récupérées et la taille des réponses. Sans mesure du réseau, une récupération web qui renvoie une réponse de 50 Mo est indiscernable d’une autre renvoyant 5 Ko.⁶

Aucun outil commercial pour agents 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 constitue le déficit de mesure des ressources.

L’absence semble 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 écrivent chacune 400 Ko, sans nettoyage, laissent 24 Mo d’état orphelin. Une récupération web qui renvoie 847 Ko est négligeable. Un pipeline de scan qui récupère 80 URL par exécution génère 67 Mo de contenu en cache que l’abstraction d’outil de l’agent dissimule à l’opérateur. La mesure des ressources rend le cumulatif visible avant qu’il ne devienne la crise qui pousse quelqu’un à ouvrir l’issue GitHub #22543.¹

Couche 2 : Application des politiques

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

mcp-firewall couvre la couche politique pour les agents CLI.⁷ L’outil se place entre l’agent et toutes les requêtes d’utilisation d’outils, évaluant chaque requête par rapport à une politique basée sur des expressions régulières avant exécution. Les politiques utilisent des fichiers de configuration JSONNet, définis par dossier, dépôt git ou utilisateur. Le firewall prend en charge Claude Code et GitHub Copilot CLI via l’intégration de hooks PreToolUse.

L’architecture reflète un constat essentiel : chaque agent implémente sa propre solution partielle de logique autoriser/refuser. Claude Code utilise des patterns glob. Codex CLI utilise une correspondance par préfixe uniquement. Chaque approche couvre un sous-ensemble de l’espace politique. mcp-firewall centralise les règles dans un seul moteur qui fonctionne pour tous les agents.

Considérez le vide politique sans application centralisée. Mon système de hooks comprend 12 handlers PreToolUse:Bash qui vérifient les patterns d’identifiants, les opérations git dangereuses, les accès aux chemins sensibles et les commandes de déploiement.² Chaque handler est un script shell séparé avec ses propres patterns regex. Quand je dois ajouter une nouvelle règle de refus, j’écris un nouveau script. Quand je dois auditer quelles règles existent, je fais un grep sur 12 fichiers. mcp-firewall consolide tout cela dans un seul fichier de configuration avec des tableaux d’autorisation explicites.

Le Top 10 OWASP pour les applications agentiques (2025) identifie le détournement d’objectif de l’agent (ASI01) et l’agentivité excessive (LLM06:2025) comme risques majeurs.⁸ Ces deux risques nécessitent une application des politiques au niveau de l’appel d’outil. Un agent qui détourne un objectif effectue toujours des appels d’outils. Un agent doté d’une agentivité excessive demande toujours 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é ? » La sensibilité au contexte est le défi. Un git push vers une branche de fonctionnalité et un git push --force vers main sont le même outil (Bash) avec des rayons d’impact différents. Les patterns regex de mcp-firewall peuvent les distinguer. Les permissions par défaut de l’agent ne le peuvent pas.

Couche 3 : Audit à l’exécution

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

Logira couvre la couche d’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 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 la revue chronologique, index.sqlite pour le filtrage par requêtes, et meta.json pour les métadonnées de l’exécution.

La philosophie de conception est « observation uniquement » : Logira enregistre et détecte mais n’applique ni ne bloque.⁹ La séparation avec la couche d’application est délibérée. L’application des politiques empêche les actions connues comme malveillantes. L’audit à l’exécution découvre les actions inconnues comme malveillantes après coup. Les deux couches remplissent des fonctions temporelles différentes : la prévention (avant) et l’investigation (après).

Les sondes eBPF de Logira opèrent en dessous de la couche applicative. Un agent qui construit une commande inédite pour exfiltrer des données effectue tout de même des appels système. L’agent ne peut pas dissimuler les lectures de fichiers, les connexions réseau ou les créations de processus au traçage au niveau du noyau. Cette approche capture ce que les hooks au niveau applicatif manquent : les effets de bord qui contournent l’abstraction des appels d’outils.

Les règles de détection intégrées ciblent spécifiquement les risques liés aux agents IA : accès aux fichiers d’identifiants, modifications des mécanismes de persistance (/etc, systemd, cron), chaînes de commandes suspectes (patterns curl-pipe-sh), opérations destructrices (rm -rf), et trafic réseau sortant anormal.⁹ Ces règles sont des valeurs par défaut orientées vers le modèle de menace des agents, et non un audit système générique.

La contrainte de plateforme est importante. Logira nécessite Linux 5.8+ avec cgroup v2. Les agents macOS (Claude Desktop, Claude Code sur Darwin) ne peuvent pas utiliser l’audit basé sur eBPF. Mon sandbox OS utilise les profils Seatbelt de macOS comme équivalent le plus proche : des règles de refus appliquées au niveau du noyau qui bloquent les écritures vers les chemins sensibles.³ Seatbelt relève de l’application, pas de l’audit. macOS ne dispose pas d’un équivalent prêt pour la production à la piste d’audit en observation seule de Logira.

La distinction entre application et audit correspond à une séparation temporelle dans la réponse aux incidents. L’application prévient l’incident. L’audit permet la reconstitution après l’incident. Les deux sont nécessaires. Une couche d’application qui bloque tout accès aux identifiants empêche l’exfiltration mais empêche aussi les opérations SSH légitimes. Une couche d’audit qui enregistre tous les accès aux identifiants sans les bloquer permet à l’opérateur d’examiner les patterns d’accès et d’affiner les règles d’application sur la base de preuves. La boucle de rétroaction entre les données d’audit et l’affinement des politiques est la manière dont la pile de visibilité s’améliore au fil du temps : l’audit révèle des patterns, les patterns informent les politiques, les politiques réduisent la surface que l’audit doit couvrir.

L’isolation par cgroup v2 de Logira ajoute une fonctionnalité que l’audit au niveau applicatif ne peut pas reproduire : l’attribution par exécution. Le système attribue chaque événement à une exécution auditée spécifique, et non au système dans son ensemble. Lorsque deux sessions d’agents s’exécutent simultanément sur la même machine, l’isolation par cgroup garantit que les accès fichiers de la session A n’apparaissent pas dans la piste d’audit de la session B. Les hooks au niveau applicatif ne peuvent pas offrir la même garantie car ils se déclenchent au sein du processus de l’agent, qui ne dispose d’aucune frontière au niveau du noyau séparant les sessions concurrentes.⁹

Ce que j’exécute concrètement

Mon système d’orchestration couvre les trois couches via des hooks, et non via des outils de surveillance dédiés.

Mesure des ressources. Le hook cost-gate suit l’utilisation de tokens par session par rapport à des seuils budgétaires configurables.⁵ Le moniteur de performance système vérifie le CPU, la mémoire, le disque et le swap à des intervalles configurables, injectant des avertissements lorsque 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, calculant la similarité cosinus entre l’embedding du prompt original et une fenêtre glissante des actions récentes.²

Application des politiques. Huit hooks de dispatcher PreToolUse routent vers des hooks de traitement par type d’outil. PreToolUse:Bash seul exécute 12 handlers couvrant les patterns d’identifiants, les opérations git destructrices, les accès aux chemins sensibles et les commandes de déploiement. Le garde-fou contre la récursion impose une profondeur maximale de deux et un maximum de cinq enfants par agent parent.²

Audit à l’exécution. Les hooks PostToolUse enregistrent le résultat de chaque appel d’outil. Les hooks de scan de sécurité vérifient la sortie bash à la recherche de fuites d’identifiants après exécution. Les fichiers d’état de session (jiro.state.json) enregistrent chaque complétion de story, verdict de reviewer et résultat du contrôle de preuves.² Le système n’utilise pas eBPF (limitation macOS) mais capture la télémétrie au niveau des outils via le pipeline de hooks.

Le système fonctionne parce que chaque action passe par le pipeline de hooks. La limitation réside dans la profondeur : la surveillance au niveau des hooks capture ce que l’agent a demandé à faire, pas ce que le système d’exploitation a réellement exécuté. Un agent qui construit une commande bash avec des sous-shells intégrés exécute du code que le hook voit comme une simple chaîne de caractères. L’audit au niveau du noyau verrait chaque sous-processus.

L’angle mort cumulatif

Les agents qui créent d’autres agents multiplient l’opacité. Chaque saut de délégation introduit une perte d’information.

Lorsque mon système d’orchestration exécute la boucle autonome ralph, le processus parent crée de nouvelles instances Claude Code pour chaque story PRD. Chaque agent enfant reçoit une tâche ciblée et une fenêtre de contexte vierge. Le parent suit l’état de complétion. Le parent ne voit pas les appels d’outils individuels de l’enfant, ses lectures de fichiers, ni sa consommation de ressources.²

À la profondeur un (le parent crée un enfant), le parent voit la sortie finale de l’enfant. À la profondeur deux (l’enfant crée un petit-enfant), le parent voit le rapport de l’enfant sur la sortie du petit-enfant. Chaque saut compresse l’information. L’analyse de la chaîne de délégation 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 des permissions sans comprendre leur sensibilité) et la diffusion de responsabilité (l’agent racine porte la responsabilité de résultats qu’il n’a jamais inspectés).³

L’observabilité se dégrade au même rythme. Une pile de visibilité à trois couches sur l’agent racine offre zéro visibilité sur l’agent petit-enfant, à moins que chaque enfant n’exécute indépendamment sa propre surveillance. Mon garde-fou contre la récursion impose la limite de profondeur, mais c’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’est passé à la profondeur deux.

Un exemple concret de mon système de production : la boucle ralph a créé un agent enfant pour implémenter une story de migration de base de données. L’agent enfant a décidé que la migration nécessitait une « étape de vérification » et a créé son propre sous-agent pour exécuter des tests d’intégration. L’agent petit-enfant a échoué silencieusement (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é le silence comme un succès, et a signalé la story comme terminée. Le parent a enregistré « story 4 : terminée. » J’ai découvert la migration cassée trois heures plus tard lorsque l’application a planté sur la colonne manquante. La télémétrie de l’agent racine montrait une exécution propre. La défaillance se trouvait à deux sauts de profondeur, invisible pour chaque couche de surveillance que j’avais déployée sur la racine.²

Le cadre OWASP pour les applications agentiques traite des défaillances en cascade et des agents incontrôlés mais ne prescrit pas d’exigences d’observabilité pour les chaînes de délégation multi-agents.⁸ Le vide est structurel : chaque agent de la chaîne aurait besoin de sa propre mesure des ressources, application des politiques et audit à l’exécution, configurés et reportés indépendamment. La surcharge est multiplicative. Trois couches de surveillance sur trois agents dans une chaîne représentent neuf instances de surveillance, chacune générant sa propre télémétrie, chacune nécessitant sa propre configuration. Aucun outil existant ne gère cette coordination.

Ce que vous pouvez implémenter dès aujourd’hui

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

1. Ressources : Tracker de budget de tokens. Enregistrez les tokens d’entrée et de sortie cumulés par session. Définissez une limite stricte. Alertez à 80 %. L’implémentation nécessite la lecture des statistiques d’utilisation de l’agent (Claude Code expose les coûts de session via /cost) et la comparaison avec un seuil. Mon hook cost-gate fait cela 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. Vérifiez la commande par rapport à une liste de patterns : rm -rf /, git push --force, chemins contenant .ssh ou .env, curl | sh. Bloquez les correspondances. L’implémentation nécessite un seul script shell qui lit stdin (l’appel d’outil en JSON), extrait le champ de commande et fait un grep par rapport à un fichier de patterns. Mon hook de vérification d’identifiants fait cela en 31 lignes.²

3. Audit : Journal de session PostToolUse. Ajoutez chaque appel d’outil et son résultat à un fichier JSONL spécifique à la session. Incluez l’horodatage, le nom de l’outil, les arguments et le code de sortie. Le journal permet la reconstitution post-session : qu’a fait l’agent, dans quel ordre, et y a-t-il eu des échecs silencieux ? Mon logger de session fait cela en 22 lignes de bash.²

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 depuis stdin, extrait la chaîne de commande et vérifie par rapport aux patterns. Une commande bloquée renvoie un objet JSON avec {"decision": "block", "reason": "Sensitive path access denied"}. Une commande autorisée renvoie {"decision": "approve"}. Claude Code respecte les deux réponses sans prompt supplémentaire. L’ensemble du hook n’ajoute aucune latence aux commandes approuvées (la vérification regex s’exécute en moins de 5 ms) et fournit un retour immédiat pour les commandes bloquées.

Ces trois hooks représentent moins de 100 lignes au total. Ils ne remplacent pas des outils de surveillance dédiés. Ils remplacent une visibilité nulle par une visibilité minimale. La visibilité minimale est le prérequis de chaque décision de gouvernance qui suit. Vous ne pouvez pas définir un budget de ressources sans mesure. Vous ne pouvez pas appliquer 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.

Points clés à retenir

Pour les ingénieurs plateforme : Les agents consomment des ressources que la surveillance existante ne suit pas. L’utilisation du disque, de la mémoire, du CPU et du réseau par session d’agent doit figurer sur le même tableau de bord que les métriques de conteneurs. L’incident Cowork le prouve : 10 Go alloués avec zéro visibilité pour l’opérateur.

Pour les équipes sécurité : L’application des politiques à la frontière des appels d’outils est la posture de sécurité minimale viable pour les agents. L’approche centralisée de mcp-firewall consolide la logique autoriser/refuser de chaque agent en une seule configuration auditable. Évaluez si les permissions intégrées de votre agent couvrent l’espace politique que votre modèle de menace exige.

Pour les responsables d’ingénierie : Posez trois questions sur vos outils d’agents : Pouvez-vous voir la consommation de ressources par session ? Pouvez-vous définir et auditer des politiques d’appels d’outils ? Pouvez-vous reconstituer ce qu’un agent a fait après coup ? Si la réponse à l’une d’entre elles est « non », vous avez un vide de visibilité qui s’aggrave avec chaque agent supplémentaire dans votre flux de travail.

FAQ

Qu’est-ce que l’observabilité des agents ? L’observabilité des agents est la capacité à surveiller et comprendre ce qu’un agent IA fait pendant son exécution : quelles ressources il consomme, quelles actions il entreprend, et si ces actions sont conformes aux politiques définies.

Pourquoi le Cowork de 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, même pour 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 requêtes d’utilisation d’outils des agents CLI (Claude Code, GitHub Copilot CLI) et les évalue par rapport à des règles autoriser/refuser basées sur des expressions régulières avant exécution.⁷

Qu’est-ce que l’audit à l’exécution par eBPF ? eBPF (extended Berkeley Packet Filter) permet le traçage des 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 fichiers et les connexions réseau pendant les exécutions d’agents IA.⁹

Sources