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 des schémas de SSRF, d’empoisonnement d’outils et de contournement 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 réel de télémétrie survenu la même semaine démontre précisément pourquoi cette réponse compte.

ClawGuard, publié le 13 avril sur arxiv, est un framework de sécurité en temps réel qui applique un ensemble de règles confirmé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 fichier 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 en utilisant cinq LLM 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 les auteurs ne l’ont pas inclus dans 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é

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 provenant d’une description d’outil, d’une page web récupérée ou d’un fichier de compétences, et la seule chose qui sépare cette injection de l’exécution est la capacité du modèle à distinguer les instructions légitimes des instructions adverses. (Certaines vulnérabilités, notamment SSRF, RCE et traversée de chemin, exploitent des failles côté serveur qui ne dépendent pas 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 par alignement aide. Le RLHF rend les modèles plus susceptibles de refuser les requêtes malveillantes. Toutefois, « plus susceptible » n’est pas une propriété de sécurité. Un modèle qui refuse 99 % des injections de prompt échoue tout de même 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’exige même pas que le modèle échoue. La description empoisonnée fait passer l’action malveillante pour l’action attendue.

L’interception en temps réel opère à un niveau entièrement différent. Un hook ou un moteur de politique qui inspecte un appel d’outil avant exécution ne dépend pas du fait que le modèle ait compris l’attaque. La vérification est déterministe : l’appel correspond-il à l’ensemble autorisé, 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 par contenu web et local. L’agent lit une page web ou un fichier local contenant des instructions adverses. 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, avec des instructions d’exfiltration dissimulées dans le contenu récupéré.

Injection par serveur MCP. Un serveur MCP compromis ou malveillant intègre des instructions dans les descriptions d’outils ou les charges utiles de réponse. 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 en détail.

Injection par fichier de compétences. Un attaquant place des instructions adverses 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 donc 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 toute 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 à son ensemble de règles. Dans la configuration évaluée, ces règles sont des contraintes basiques de contrôle d’accès (restrictions de chemins de fichiers, listes blanches d’appels réseau, blocage d’accès aux identifiants). ClawGuard bloque tout appel qui sort de ces contraintes, quelle que soit la force de conviction du prompt d’injection.

L’insight architectural mérite d’être énoncé 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 ClawGuard, Akshay Chugh a publié une divulgation concernant le Vercel Plugin 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 de chaîne vide 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 résolu les problèmes de télémétrie le 14 avril, en supprimant les matchers trop 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ème que la défense en temps réel adresse : un hook qui se déclenche plus largement que prévu par l’utilisateur, collectant des données que l’utilisateur n’a pas explicitement consenti à partager, via un mécanisme qui contourne l’interface native de consentement.

Remplacez « télémétrie » par « exfiltration » et l’architecture est identique. Un hook avec un matcher trop large, s’exécutant sur tous les projets, envoyant des données à un point de terminaison externe. La différence entre télémétrie et attaque réside dans 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 qui prend en charge l’interception PreToolUse et PostToolUse. J’utilise plus de 95 hooks qui appliquent des restrictions de chemins de fichiers, valident les entrées d’outils et conditionnent les opérations destructives à 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 un git force-push. La configuration évaluée de ClawGuard utilise des règles de contrôle d’accès basiques similaires dans l’esprit aux hooks écrits manuellement. Le composant d’induction de règles spécifiques à la tâche proposé dans l’article 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 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 succès 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).

Reste à savoir si la dérivation automatique fonctionne de manière fiable en production. 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 « sans compromettre 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 d’appel d’outil avant exécution. Bloquer les adresses IP internes, valider les chemins de fichiers, rejeter les métacaractères shell. Mes hooks PreToolUse opèrent à cette couche. Faible taux de faux positifs, mais ne capture que les schémas malveillants connus.

Couche 2 : Application de règles basiques. Restreindre l’ensemble des outils autorisés et des arguments autorisés selon des règles de contrôle d’accès (restrictions de chemins, listes blanches réseau, gardes d’identifiants). La configuration évaluée de ClawGuard opère à cette couche.¹ L’article propose également une dérivation de contraintes ciblées par tâche, qui se situerait entre cette couche et la suivante, mais ce composant reste un travail futur. Couverture supérieure à la seule validation des entrées, mais les règles doivent être maintenues au fur et à mesure que l’environnement évolue.

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 a documenté pourquoi l’inspection des sorties est importante : un routeur compromis modifie les réponses après génération.

Couche 4 : Audit de session. Journaliser 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 par ce type d’audit : en lisant la configuration des hooks et en traçant ce que les hooks faisaient.²

Aucune couche isolée ne suffit. La validation des entrées manque les schémas inédits. Les contraintes ciblées par 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 laissées par les autres.

Ce que ClawGuard fait bien

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

Le déterminisme plutôt que l’alignement. Formuler la défense en temps réel comme un mécanisme déterministe plutôt qu’une propriété d’alignement est la formulation correcte. L’alignement est une propriété d’entraînement qui se dégrade sous conditions adverses. L’application déterministe est une propriété d’exécution qui tient indépendamment du comportement du modèle. La distinction semble académique, mais elle change ce que l’on peut promettre quant à la posture de sécurité d’un système.

Application agnostique 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 solide. Trois défenses distinctes pour trois canaux d’injection créeraient une charge 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 ceux que l’on ne contrôle 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 livre 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’en autoriser de 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 peuvent ne pas anticiper les étapes intermédiaires.

Descriptions de tâches adverses. Si la dérivation de contraintes dépend de l’objectif déclaré par l’utilisateur, un attaquant qui contrôle la description de la tâche (via un espace de travail partagé, un gestionnaire 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 fournit 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. Inutile d’attendre ClawGuard ou tout 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 : bloquer les adresses internes, restreindre les chemins de fichiers, conditionner les opérations destructives. Le tutoriel sur les hooks couvre l’implémentation.

Auditez vos matchers de hooks. L’incident Vercel s’est produit parce que des matchers de chaîne vide se déclenchaient sur tous les projets.² Passez en revue chaque hook de 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 risque, pas une défense.

Journalisez chaque appel d’outil. L’audit de session est la couche de défense la moins coûteuse en effort et la plus précieuse. 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. L’article renvoie à un dépôt, bien que les auteurs n’aient pas encore publié le code au moment de la rédaction. Une fois 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 appliqués 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 comptent. La défense en temps réel à la frontière d’appel d’outil est la couche exécutoire — non pas parce que l’alignement n’aide pas, mais parce que l’application ne dépend pas de celui-ci.

Sources

Questions fréquentes

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 prend en charge à la fois l’approbation au niveau de l’outil (approuver ou refuser des catégories d’outils) et les spécificateurs au niveau des arguments (par exemple, Bash(git diff *) pour n’autoriser que les commandes correspondantes). La configuration évaluée de ClawGuard applique des règles de contrôle d’accès basiques au niveau des arguments. Son composant d’induction de règles spécifiques à la tâche dériverait automatiquement des contraintes d’arguments à partir de la tâche en cours, mais les auteurs n’ont pas évalué ce composant. Les deux systèmes se complètent : les permissions de Claude Code contrôlent quels outils et quels schémas d’arguments peuvent s’exécuter, tandis que les contraintes en temps réel de type ClawGuard ajoutent une seconde couche d’application.

Faut-il attendre la sortie de ClawGuard pour 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 qui valident les entrées d’outils couvrent immédiatement les schémas d’attaque les plus courants. La contribution de ClawGuard est 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 résolu ces problèmes. Le schéma architectural (matchers de hooks trop larges, transmission de données externe, consentement non natif) reste instructif car il reflète le même schéma qu’un hook malveillant utiliserait pour l’exfiltration de données.

Quel est l’impact en performance 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 d’après mon expérience opérationnelle. L’article ClawGuard ne fournit pas de mesures de latence pour l’évaluation de ses contraintes, qui pourrait ajouter une surcharge supplémentaire. Pour les sessions interactives, la latence par appel d’outil compte ; testez donc avant de déployer une logique de validation complexe.