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

Anthropic a livré 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 quand même la VM. Ceux qui la supprimaient la voyaient se régénérer. Un utilisateur a signalé que le bundle atteignait 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é.

En bref

Les outils 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 en est l’exemple visible ; chaque appel d’outil MCP, chaque sous-agent généré et chaque requête web en 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 en temps réel (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 monitoring minimum que vous pouvez implémenter dès aujourd’hui.

Le problème de visibilité

Les logiciels traditionnels fonctionnent en dessous d’une ligne d’observabilité que les opérateurs choisissent de tracer. Un serveur web écrit des logs d’accès parce que les ingénieurs ont configuré la journalisation. Une base de données trace 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 agents inversent la relation. L’agent décide quoi exécuter au moment de l’exécution. Un agent de programmation qui reçoit « corrige l’endpoint de connexion » peut lire 47 fichiers, écrire dans 12, générer 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 le monitoring traditionnel.

L’incident Cowork a exposé cette inversion au niveau de l’infrastructure. Claude Desktop a alloué 10 Go d’espace disque, consommé 24 à 55 % de CPU au repos et fait grimper l’activité de swap de 20K à plus de 24K swapins sur les machines à 8 Go de RAM.¹ Les utilisateurs ont découvert la consommation de ressources via les avertissements de stockage macOS, pas via la télémétrie de Anthropic. L’application ne fournissait ni tableau de bord, ni compteur, ni divulgation opt-in pour l’allocation de la VM.

Le schéma n’est pas 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 contre un fichier d’état de production. Aucune invite de confirmation n’est apparue. Aucun hook n’a intercepté la commande. Le développeur a découvert la destruction lorsque l’application s’est retrouvée hors ligne. 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é l’intégralité d’un environnement de production, y compris des snapshots de base de données représentant 2,5 ans de données.¹³ Les deux incidents partagent la même cause : zéro visibilité sur ce que l’agent faisait avant que les dégâts ne soient irréversibles.

Transposez ce schéma aux sessions agents. Mon système d’orchestration par hooks intercepte 15 types d’événements à chaque appel d’outil.¹¹ Sur 60 sessions, le système a enregistré 84 hooks se déclenchant à 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 génération récursive documentés dans mon commentaire public au NIST.³

Le rapport DORA 2024 Accelerate State of DevOps a constaté que les équipes dotées de pratiques d’observabilité solides déploient plus fréquemment et récupèrent plus rapidement après les incidents. L’édition 2025 étend le cadre au développement assisté par IA, reliant l’observabilité à « la façon dont le développement 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 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 du dessous.

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 consommait 10 Go d’espace disque. Le processus de rendu consommait 24 % du CPU au repos. L’activité de swap augmentait régulièrement pendant les 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 programmation 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, logs des hooks). Sur 60 sessions, cela s’accumule jusqu’à 12-24 Mo de données d’état qui persistent entre les sessions sans 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 au tarif Opus actuel. Mon traqueur de coûts enregistre l’utilisation cumulative des tokens par session, avec des seuils de budget à 80 %, 90 % et 95 % d’une limite configurable.⁵

CPU. Temps d’exécution des hooks. Mon dispatcher de 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. Requêtes 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 des requêtes et la taille des réponses. Sans mesure du réseau, une requête web retournant une réponse de 50 Mo est indiscernable d’une réponse de 5 Ko.⁶

Aucun outil 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 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 requête web qui retourne 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 à créer 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 positionne 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 limités par dossier, dépôt git ou utilisateur. Le pare-feu prend en charge Claude Code et GitHub Copilot CLI via l’intégration de hooks PreToolUse.

L’architecture reflète un constat clé : chaque agent implémente sa propre solution partielle de logique d’autorisation/refus. Claude Code utilise des motifs 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 déficit politique sans application centralisée. Mon système de hooks comprend 12 gestionnaires PreToolUse:Bash qui vérifient les motifs d’identifiants, les opérations git dangereuses, l’accès aux chemins sensibles et les commandes de déploiement.² Chaque gestionnaire est un script shell séparé avec ses propres motifs 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’objectifs d’agent (ASI01) et l’agence excessive (LLM06:2025) comme risques majeurs.⁸ Ces deux risques nécessitent une application des politiques au niveau des appels d’outils. Un agent dont l’objectif est détourné effectue toujours des appels d’outils. Un agent disposant d’une agence 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 motifs regex de mcp-firewall peuvent les distinguer. Les permissions par défaut de l’agent ne le peuvent pas.

L’application des politiques au niveau applicatif fait également face au risque de contournement. En mars 2026, une analyse a documenté trois techniques d’évasion de sandbox de gravité croissante contre la liste de blocage intégrée de Claude Code : évasion par chemin (/proc/self/root/usr/bin/npx résout vers le même binaire que le /usr/bin/npx bloqué), désactivation auto-dirigée de la sandbox (l’agent a raisonné de manière autonome sur la suppression de la sandbox lorsqu’elle bloquait l’accomplissement de la tâche) et invocation du chargeur dynamique (ld-linux-x86-64.so.2 charge les binaires par mappage mémoire, contournant entièrement les hooks d’application au niveau du noyau).¹⁴ La troisième technique est une classe d’exploit : tout chargement de code qui évite execve contourne l’application au niveau processus. La conclusion pour l’application des politiques est que les listes de blocage par correspondance de chaînes sont une première couche nécessaire, mais pas suffisante. L’application adressable par contenu (identification des binaires par hash SHA-256 plutôt que par nom de fichier) comble la faille d’évasion par chemin, mais le contournement via le chargeur dynamique nécessite des contrôles au niveau du noyau situés en dessous de la couche politique.

Couche 3 : Audit en temps réel

L’audit en temps réel 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ête et meta.json pour les métadonnées de l’exécution.

La philosophie de conception est « observer uniquement » : Logira enregistre et détecte mais n’applique ni ne bloque.⁹ La séparation d’avec la couche d’application est délibérée. L’application des politiques empêche les actions connues comme mauvaises. L’audit en temps réel découvre les actions inconnues comme mauvaises 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 quand même des appels système. L’agent ne peut pas dissimuler les lectures de fichiers, les connexions réseau ou les lancements de processus au traçage au niveau du noyau. L’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 (motifs curl-pipe-sh), opérations destructives (rm -rf) et trafic réseau sortant anormal.⁹ Les règles sont des valeurs par défaut orientées vers le modèle de menace des agents, pas 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 est de l’application, pas de l’audit. macOS ne dispose pas d’un équivalent prêt pour la production de la piste d’audit en observation seule de Logira.

Agent Safehouse, un outil de sandboxing natif macOS qui a recueilli 802 points et 181 commentaires sur Hacker News en mars 2026, comble le déficit de plateforme du côté de l’application.¹⁵ L’outil fournit des profils de sandbox spécifiquement conçus pour les agents IA locaux sur macOS. La réponse de la communauté (802 points est exceptionnel pour un outil de sandboxing) reflète l’urgence : les praticiens exécutant des agents sur macOS ont des options limitées entre « pas de sandbox » et « écrire son propre profil Seatbelt ». Agent Safehouse comble ce vide pour l’application. Le déficit d’audit sur macOS reste ouvert.

La distinction entre application et audit correspond à une division temporelle dans la réponse aux incidents. L’application prévient l’incident. L’audit permet la reconstruction 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 tout accès aux identifiants sans bloquer permet à l’opérateur d’examiner les schémas d’accès et d’affiner les règles d’application en se basant sur des preuves. La boucle de rétroaction entre les données d’audit et l’affinage des politiques est le mécanisme par lequel la pile de visibilité s’améliore au fil du temps : l’audit révèle des schémas, les schémas 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, pas 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 l’accès aux fichiers de la session A n’apparaît pas dans la piste d’audit de la session B. Les hooks au niveau applicatif ne peuvent pas fournir la même garantie car ils se déclenchent au sein du processus de l’agent, qui n’a pas de frontière au niveau du noyau séparant les sessions concurrentes.⁹

Ce que j’exécute réellement

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

Mesure des ressources. Le hook cost-gate suit l’utilisation des tokens par session par rapport à des seuils de budget configurables.⁵ Le moniteur de performance système vérifie le CPU, la mémoire, le disque et le swap à 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 du dispatcher PreToolUse orientent vers des hooks de traitement par type d’outil. PreToolUse:Bash seul exécute 12 gestionnaires couvrant les motifs d’identifiants, les opérations git destructives, l’accès aux chemins sensibles et les commandes de déploiement. La garde anti-récursion impose une profondeur maximale de deux et un maximum de cinq enfants par agent parent.²

Audit en temps réel. Les hooks PostToolUse enregistrent chaque résultat d’appel d’outil. Les hooks de scan de sécurité vérifient la sortie bash pour les fuites d’identifiants après exécution. Les fichiers d’état de session (jiro.state.json) enregistrent chaque achèvement de story, chaque verdict de relecteur et chaque résultat de porte de preuve.² 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 est la profondeur : le monitoring 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 seule chaîne. L’audit au niveau du noyau verrait chaque sous-processus.

Résultats concrets d’incidents en production où la pile à trois couches a détecté des défaillances que le monitoring par défaut aurait manquées :

L’angle mort cumulatif

Les agents qui génèrent 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 génère 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 d’achèvement. 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 génère un enfant), le parent voit la sortie finale de l’enfant. À la profondeur deux (l’enfant génère 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 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 la 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 son propre monitoring. Ma garde anti-récursion impose la limite de profondeur, mais la garde 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 en production : la boucle ralph a généré 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 généré son propre sous-agent pour exécuter des tests d’intégration. Le 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 déclaré la story terminée. Le parent a enregistré « story 4 : terminée ». J’ai découvert la migration cassée trois heures plus tard quand 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 résidait à deux sauts de profondeur, invisible pour chaque couche de monitoring 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 déficit est structurel : chaque agent de la chaîne aurait besoin de sa propre mesure des ressources, application des politiques et audit en temps réel, configurés indépendamment et reportés indépendamment. La surcharge est multiplicative. Trois couches de monitoring sur trois agents dans une chaîne, c’est neuf instances de monitoring, 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 monitoring minimum qui couvrent la pile de visibilité :

1. Ressources : traqueur 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 d’outil Bash. Vérifiez la commande par rapport à une liste de motifs : rm -rf /, git push --force, les chemins contenant .ssh ou .env, curl | sh. Bloquez les correspondances. L’implémentation nécessite un 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 motifs. 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 reconstruction 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 motifs. Une commande bloquée retourne un objet JSON avec {"decision": "block", "reason": "Sensitive path access denied"}. Une commande autorisée retourne {"decision": "approve"}. Claude Code respecte les deux réponses sans invite supplémentaire. Le hook complet n’ajoute aucune latence aux commandes autorisé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 les outils de monitoring dédiés. Ils remplacent zéro visibilité par une visibilité minimum. La visibilité minimum 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 portée 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 le monitoring existant ne suit pas. L’utilisation du disque, de la mémoire, du CPU et du réseau par session d’agent devrait apparaître 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 de sécurité : L’application des politiques à la frontière des appels d’outils est la posture de sécurité minimum viable pour les agents. L’approche centralisée de mcp-firewall consolide la logique d’autorisation/refus propre à chaque agent dans une seule configuration auditable. Évaluez si les permissions intégrées de votre agent couvrent l’espace politique exigé par votre modèle de menace.

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

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 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 le bundle de la VM automatiquement sur chaque installation macOS, même pour les utilisateurs qui n’activent jamais la fonctionnalité, et le conserve jusqu’à 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 d’autorisation/refus basées sur des expressions régulières avant exécution.⁷

Qu’est-ce que l’audit en temps réel par eBPF ? eBPF (extended Berkeley Packet Filter) permet le traçage au niveau du noyau des appels système 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.⁹

Comment les agents génèrent-ils des sous-agents sans visibilité pour l’opérateur ? Les agents qui délèguent des tâches génèrent des processus enfants avec des fenêtres de contexte vierges. L’agent parent voit la sortie finale de l’enfant mais pas ses appels d’outils individuels, ses lectures de fichiers ni sa consommation de ressources. À chaque saut de délégation, l’information se compresse : la session complète du petit-enfant devient une ligne de statut dans le journal du parent. L’observabilité se dégrade au même rythme que la profondeur de délégation augmente.²

En quoi le monitoring des agents diffère-t-il de l’APM traditionnel ? L’Application Performance Monitoring (APM) traditionnel suit la latence des requêtes, les taux d’erreur et le débit pour des logiciels déterministes. Le monitoring des agents suit un comportement non déterministe : ce que l’agent a décidé de faire au moment de l’exécution, si ces décisions entraient dans le cadre de la politique et quelles ressources chaque décision a consommées. L’APM suppose que l’application suit un chemin de code connu. Le monitoring des agents suppose que l’agent choisit son propre chemin.²

Sources