Défense en temps réel pour les agents augmentés par des outils

Il y a une semaine, j’ai publié 50 vulnérabilités MCP couvrant les SSRF, l’empoisonnement d’outils et les contournements de confiance. La conclusion implicite était sombre : la surface d’attaque croît plus vite que la capacité d’audit. Un nouvel article de Wei Zhao, Zhe Li, Peixin Zhang et Jun Sun propose une réponse structurelle — et un incident de télémétrie survenu la même semaine démontre précisément pourquoi cette réponse est essentielle.

ClawGuard, publié le 13 avril sur arxiv, est un framework de sécurité en temps réel qui applique un ensemble de règles validées par l’utilisateur à chaque frontière d’appel d’outil.¹ Dans sa configuration évaluée, le framework applique des règles de contrôle d’accès basiques — blocage des accès fichiers non autorisés, prévention de l’exfiltration d’identifiants, restriction des appels réseau — avant toute invocation d’outil externe. Aucune modification du modèle. Aucun changement d’infrastructure. Aucun fine-tuning spécifique à la sécurité.¹ Les auteurs ont testé sur AgentDojo, SkillInject et MCPSafeBench avec cinq LLMs de pointe.¹ L’article décrit également un composant d’induction de règles spécifiques à la tâche qui dériverait automatiquement des contraintes à partir de l’objectif déclaré par l’utilisateur, mais celui-ci ne faisait pas partie de la configuration évaluée.

L’affirmation qui compte : ClawGuard transforme une défense dépendante de l’alignement en un mécanisme déterministe et auditable.¹

Pourquoi l’alignement n’est pas une frontière de sécurité

Bon nombre des vulnérabilités MCP que j’ai cataloguées la semaine dernière exploitent une faille structurelle commune. L’agent reçoit des instructions depuis une description d’outil, une page web récupérée ou un fichier de compétences — et la seule chose qui sépare cette injection de son exécution est la capacité du modèle à distinguer les instructions légitimes des instructions adversariales. (Certaines vulnérabilités — SSRF, RCE, traversée de chemin — exploitent des failles côté serveur qui ne dépendent pas du tout du suivi d’instructions par le modèle, mais la frontière d’appel d’outil reste pertinente pour la défense.)

L’entraînement à l’alignement aide. Le RLHF rend les modèles plus susceptibles de refuser les requêtes nuisibles. Toutefois, « plus susceptible » n’est pas une propriété de sécurité. Un modèle qui refuse 99 % des injections de prompt échoue encore 1 % du temps, et un attaquant qui contrôle l’entrée peut itérer jusqu’à atteindre ce 1 %. Le schéma d’empoisonnement d’outils n’a même pas besoin que le modèle échoue — la description empoisonnée fait passer l’action malveillante pour l’action prévue.

L’interception en temps réel opère à un niveau entièrement différent. Un hook ou un moteur de politiques qui inspecte un appel d’outil avant son exécution ne dépend pas de la compréhension de l’attaque par le modèle. La vérification est déterministe : l’appel correspond-il à l’ensemble autorisé, oui ou non ?

Trois canaux d’injection, un seul point d’application

ClawGuard identifie trois canaux d’attaque pour les agents augmentés par des outils :¹

Injection via contenu web et local. L’agent lit une page web ou un fichier local contenant des instructions adversariales. Ces instructions dirigent l’agent vers des appels d’outils non prévus par l’utilisateur. La surface d’attaque par exfiltration silencieuse est une instance de ce schéma — des instructions d’exfiltration dissimulées dans du contenu récupéré.

Injection via serveur MCP. Un serveur MCP compromis ou malveillant intègre des instructions dans les descriptions d’outils ou les réponses. L’agent lit ces instructions comme du contexte et agit en conséquence. Le catalogue de 50 vulnérabilités de la semaine dernière documente ce canal de manière approfondie.

Injection via fichiers de compétences. Des instructions adversariales placées dans les fichiers de compétences et la configuration que l’agent charge comme contexte de confiance. L’agent traite le contenu des fichiers de compétences comme faisant autorité — un attaquant capable d’écrire dans un fichier de compétences ou de configuration peut diriger le comportement de l’agent.

L’architecture de défense place l’application au niveau de la frontière d’appel d’outil — le point unique par lequel chaque action externe doit transiter, quel que soit le canal ayant injecté l’instruction.¹ Avant que l’agent n’invoque un outil, ClawGuard vérifie l’appel par rapport aux contraintes dérivées de la tâche originale de l’utilisateur. Un appel hors de ces contraintes est bloqué, peu importe la force de conviction du prompt d’injection.

L’intuition architecturale mérite d’être énoncée clairement : il n’est pas nécessaire de détecter chaque injection si l’on peut appliquer une politique à la frontière d’exécution.

L’incident de télémétrie Vercel

Quatre jours avant la publication de l’article sur ClawGuard, Akshay Chugh a publié une divulgation concernant le plugin Vercel pour Claude Code le 9 avril.² Les constats au moment de la divulgation :

Le plugin enregistrait des hooks qui envoyaient des chaînes de commandes bash à telemetry.vercel.com.² Un UUID persistant stocké dans ~/.claude/vercel-plugin-device-id liait ces chaînes de commandes à un appareil.² Le plugin utilisait des matchers vides sur ses hooks, ce qui signifie que les hooks se déclenchaient sur tous les projets — pas uniquement les projets Vercel.² Le mécanisme de consentement utilisait une injection de prompt plutôt qu’une interface native pour obtenir l’accord de l’utilisateur.² La télémétrie se déclenchait à chaque événement correspondant, sauf si l’utilisateur définissait VERCEL_PLUGIN_TELEMETRY=off.²

Vercel a traité les préoccupations liées à la télémétrie le 14 avril, en supprimant les matchers larges et le mécanisme de consentement par prompt.²

L’incident Vercel n’est pas une vulnérabilité au sens traditionnel. Personne ne vole d’identifiants. Néanmoins, il illustre exactement la classe de problèmes à laquelle la défense en temps réel s’attaque : un hook qui se déclenche plus largement que prévu par l’utilisateur, collectant des données auxquelles l’utilisateur n’a pas explicitement consenti, via un mécanisme qui contourne l’interface de consentement native.

Remplacez « télémétrie » par « exfiltration » et l’architecture est identique. Un hook avec un matcher trop large, s’exécutant sur chaque projet, envoyant des données vers un point de terminaison externe. La différence entre télémétrie et attaque est l’intention — et l’intention n’est pas auditable en temps réel.

Du papier à la pratique : ce dont les praticiens disposent déjà

ClawGuard formalise ce que les praticiens construisent de manière informelle. Claude Code intègre un système de hooks prenant en charge l’interception PreToolUse et PostToolUse. J’exécute plus de 95 hooks qui appliquent des restrictions de chemins de fichiers, valident les entrées d’outils et soumettent les opérations destructrices à une confirmation explicite.³

L’écart entre mes hooks et la vision de ClawGuard réside dans l’automatisation. Mes hooks sont des règles écrites manuellement : bloquer les adresses IP internes dans les entrées MCP, restreindre les écritures de fichiers aux répertoires du projet, exiger une approbation pour les force-push git. La configuration évaluée de ClawGuard utilise des règles de contrôle d’accès basiques, similaires dans leur esprit aux hooks écrits manuellement. Le composant proposé d’induction de règles spécifiques à la tâche dériverait automatiquement des contraintes à partir de l’objectif déclaré par l’utilisateur¹ — au lieu d’écrire « bloquer les écritures dans /etc », le framework inférerait qu’une tâche décrite comme « refactoriser le module de connexion » ne devrait pas nécessiter d’accès en écriture aux répertoires système. Ce composant reste un travail futur.

La dérivation automatique de contraintes est le problème le plus difficile — et le composant d’induction de règles spécifiques à la tâche de ClawGuard représente un travail futur, pas des résultats évalués. La configuration à règles basiques que les auteurs ont effectivement évaluée a montré des résultats solides mais imparfaits : AgentDojo a atteint un taux de réussite d’attaque (ASR) de 0 %, mais SkillInject affichait encore 4,8-14 % d’ASR et MCPSafeBench montrait 7,1-11,0 % d’ASR selon le modèle.¹ Les règles écrites manuellement sont fragiles — elles couvrent les attaques anticipées. Les contraintes dérivées pourraient couvrir des attaques non anticipées, car elles opèrent sur l’ensemble positif (ce qui devrait se produire) plutôt que sur l’ensemble négatif (ce qui ne devrait pas se produire).

La fiabilité de la dérivation automatique en production reste une question ouverte. Les benchmarks sont des environnements contrôlés. Les sessions d’agents réelles impliquent des tâches ambiguës, des chaînes d’outils multi-étapes et des appels d’outils qui semblent anormaux mais sont légitimes. Des faux positifs bloquant des appels d’outils valides éroderaient rapidement l’affirmation de « préservation de l’utilité de l’agent ».

La pile de défense en couches

La défense en temps réel n’est pas un mécanisme unique. La pile pratique pour les agents augmentés par des outils comporte au moins quatre couches :

Couche 1 : Validation des entrées. Des hooks qui inspectent les arguments des appels d’outils avant l’exécution. Blocage des adresses IP internes, validation des chemins de fichiers, rejet des métacaractères shell. Mes hooks PreToolUse opèrent à cette couche. Faible taux de faux positifs, mais ne détecte que les schémas malveillants connus.

Couche 2 : Contraintes limitées à la tâche. Restreindre l’ensemble des outils autorisés et des arguments permis à ce que la tâche en cours requiert. ClawGuard opère principalement à cette couche.¹ Couverture supérieure à la validation des entrées seule, mais nécessite une compréhension précise de la tâche.

Couche 3 : Inspection des sorties. Des hooks PostToolUse qui examinent les résultats des outils avant que l’agent ne les traite. Détecte l’exfiltration de données, repère les réponses anormales, signale les comportements d’outils inattendus. L’article sur l’intermédiaire documente pourquoi l’inspection des sorties est essentielle — un routeur compromis modifie les réponses après leur génération.

Couche 4 : Audit de session. Journalisation de chaque appel d’outil, chaque argument, chaque résultat pour une revue a posteriori. Ce n’est pas un mécanisme de prévention, mais de détection. Akshay Chugh a découvert l’incident de télémétrie Vercel précisément grâce à ce type d’audit — en lisant la configuration des hooks et en traçant leur comportement.²

Aucune couche seule ne suffit. La validation des entrées manque les schémas inédits. Les contraintes limitées à la tâche peuvent être trop restrictives ou trop permissives. L’inspection des sorties ajoute de la latence. L’audit de session détecte les problèmes après les dégâts. La pile fonctionne parce que chaque couche comble les lacunes des autres.

Ce que ClawGuard fait bien

L’article apporte trois contributions qui importent pour les praticiens :

Le déterminisme plutôt que l’alignement. Présenter la défense en temps réel comme un mécanisme déterministe plutôt qu’une propriété d’alignement est le cadrage correct. L’alignement est une propriété d’entraînement qui se dégrade en conditions adversariales. L’application déterministe est une propriété d’exécution qui tient indépendamment du comportement du modèle. La distinction paraît académique, mais elle change ce que vous pouvez garantir sur la posture de sécurité de votre système.

Application indépendante du canal. Défendre contre l’injection web, l’injection MCP et l’injection par fichier de compétences avec un seul point d’application est architecturalement sain. Trois défenses séparées pour trois canaux d’injection créeraient un fardeau de maintenance et laisseraient des failles aux intersections. Un point d’application unique à la frontière d’appel d’outil couvre les trois canaux par construction.

Aucune modification du modèle requise. Ne nécessiter ni fine-tuning ni modification architecturale signifie que la défense fonctionne avec n’importe quel modèle, y compris les modèles que vous ne contrôlez pas. Un opérateur utilisant Claude Code, Codex CLI ou tout autre framework d’agents peut ajouter une défense en temps réel sans attendre que le fournisseur du modèle publie une mise à jour de sécurité.

Ce qui reste ouvert

ClawGuard a été testé sur des benchmarks. Les sessions d’agents en production sont plus chaotiques. Plusieurs questions demeurent avant que les praticiens puissent s’appuyer sur la dérivation automatique de contraintes :

Tâches ambiguës. « Aidez-moi avec ce projet » ne précise pas quels outils ou chemins sont concernés. Dériver des contraintes à partir d’objectifs vagues risque soit de bloquer des appels légitimes (trop restrictif), soit d’autoriser des appels dangereux (trop permissif).

Chaînes multi-étapes. Un agent qui doit lire un fichier de configuration, appeler une API et écrire les résultats dans une base de données présente un schéma d’accès complexe. Les contraintes dérivées de la description initiale de la tâche pourraient ne pas anticiper les étapes intermédiaires.

Descriptions de tâches adversariales. Si la dérivation de contraintes dépend de l’objectif déclaré par l’utilisateur, un attaquant contrôlant la description de la tâche (via un espace de travail partagé, un outil de suivi de tickets empoisonné ou un fichier de projet manipulé) peut influencer les contraintes elles-mêmes.

Coût en performance. Évaluer les contraintes à chaque frontière d’appel d’outil ajoute de la latence. L’article affirme que le framework préserve l’utilité, mais ne rapporte pas de mesures de latence.¹ Pour les sessions d’agents interactives, même 200 ms par appel d’outil modifie l’expérience utilisateur.

Recommandations opérationnelles

Pour les praticiens utilisant des agents augmentés par des outils aujourd’hui :

Déployez des hooks PreToolUse dès maintenant. Nul besoin d’attendre ClawGuard ou un autre framework. Le système de hooks de Claude Code prend en charge l’interception des appels d’outils dès aujourd’hui. Commencez par la validation des entrées — bloquez les adresses internes, restreignez les chemins de fichiers, soumettez les opérations destructrices à approbation. Le tutoriel sur les hooks couvre l’implémentation.

Auditez vos matchers de hooks. L’incident Vercel s’est produit parce que des matchers vides se déclenchaient sur tous les projets.² Passez en revue chaque hook dans votre .claude/settings.json et vérifiez que chaque matcher ne cible que le contexte prévu. Un hook avec un matcher trop large est un passif, pas une défense.

Journalisez chaque appel d’outil. L’audit de session est la couche de défense la moins coûteuse et la plus rentable. Même si vous ne pouvez pas prévenir chaque attaque, vous pouvez la détecter après coup — mais uniquement si vous disposez de journaux.

Évaluez ClawGuard par rapport à votre pile. Le code de l’article est publiquement disponible. Évaluez la configuration à règles basiques par rapport à votre pile de hooks existante. Si le composant d’induction de règles spécifiques à la tâche mûrit, la dérivation automatique de contraintes compléterait les règles manuelles, sans les remplacer.

Traitez la configuration comme une frontière de confiance. Fichiers de compétences, configuration des hooks, définitions de serveurs MCP — chaque fichier qui influence le comportement de l’agent est une surface d’attaque. Appliquez les mêmes contrôles d’accès que ceux que vous appliqueriez aux identifiants de production.

Le catalogue de vulnérabilités MCP a documenté la surface d’attaque. ClawGuard propose une architecture de défense. L’incident Vercel démontre pourquoi les deux sont importants. La défense en temps réel à la frontière d’appel d’outil est la couche applicable — non pas parce que l’alignement n’aide pas, mais parce que l’application ne dépend pas de celui-ci.

Sources

Foire aux questions

En quoi ClawGuard diffère-t-il du système de permissions intégré de Claude Code ?

Le système de permissions de Claude Code demande l’approbation de l’utilisateur au niveau de l’outil — approuver ou refuser des catégories d’outils spécifiques. ClawGuard opère au niveau des arguments, en dérivant automatiquement des contraintes sur les arguments qu’un appel d’outil devrait contenir en fonction de la tâche en cours. Les deux mécanismes sont complémentaires : les permissions contrôlent quels outils peuvent s’exécuter, les contraintes en temps réel contrôlent comment ces outils peuvent être appelés.

Faut-il attendre la sortie de ClawGuard avant d’ajouter une défense en temps réel ?

Non. Le système de hooks de Claude Code prend en charge l’interception PreToolUse et PostToolUse dès aujourd’hui. Des hooks écrits manuellement validant les entrées d’outils couvrent immédiatement les schémas d’attaque les plus courants. La contribution de ClawGuard réside dans la dérivation automatique de contraintes, qui viendrait compléter les règles manuelles plutôt que les remplacer.

L’incident de télémétrie Vercel était-il une vulnérabilité de sécurité ?

La divulgation décrivait un problème de confidentialité et de consentement plutôt qu’une vulnérabilité traditionnelle. Au moment de la divulgation, le plugin collectait des chaînes de commandes bash de tous les projets et les envoyait à un point de terminaison externe sans opt-in explicite via l’interface native. Vercel a depuis traité ces préoccupations. Le schéma architectural — matchers de hooks larges, transmission de données externe, consentement non natif — reste instructif car il reproduit le même schéma qu’un hook malveillant utiliserait pour l’exfiltration de données.

Quel est l’impact sur les performances de l’interception des appels d’outils en temps réel ?

Pour des hooks écrits manuellement utilisant des scripts shell ou des validateurs légers, la surcharge devrait rester sous 200 ms par appel d’outil selon les recommandations de la documentation des hooks. L’article sur ClawGuard ne rapporte pas de mesures de latence pour son évaluation de contraintes, qui pourrait ajouter une surcharge supplémentaire. Pour les sessions interactives, la latence par appel d’outil est significative — testez avant de déployer une logique de validation complexe.