Sécuriser votre agent de programmation : les cinq couches, et les outils qui bloquent vraiment quelque chose

Votre agent de programmation lit des fichiers, exécute des commandes et installe des choses en votre nom. La plupart des outils de « sécurité IA » populaires qui lui sont destinés ne font que donner des conseils. Voici comment empiler ceux qui arrêtent vraiment quelque chose, et où placer les conseillers.

L'idée est simple. Tout ce qui tourne à l'intérieur de l'agent peut être contourné par la discussion, car une injection de consignes peut convaincre le modèle d'y renoncer. Les décisions qui doivent tenir se trouvent donc hors de l'agent : dans le système d'exploitation, dans un hook ou dans la CI. Les nombres d'étoiles ci-dessous ont été vérifiés sur GitHub le 24 octobre 2026, et ils disent peu de chose sur les outils qui imposent réellement quelque chose : la skill d'audit de Cloudflare a plus d'étoiles que tous les outils bloquants présentés ici réunis, avec 14 commits.

1. Confiner : décider de ce que l'agent peut atteindre

Si tout le reste échoue, un bac à sable décide encore des fichiers que l'agent peut lire ou écrire et des hôtes auxquels il peut se connecter.

• Anthropic Sandbox Runtime (4,4) est le moteur derrière la commande /sandbox de Claude Code. Il utilise le bac à sable propre au système d'exploitation, n'a pas besoin de conteneur et il est gratuit. Il autorise volontairement l'écriture dans votre projet : il n'empêchera donc pas un hard reset.
• NVIDIA OpenShell (4,1) est plus lourd : un bac à sable par agent, des identifiants que l'agent ne voit jamais, et des changements de politique vérifiés avant leur application. Il convient aux agents que vous laissez tourner sans surveillance.

Choisissez-en un par charge de travail. Faire tourner les deux sur le même agent ne vous donne que deux jeux de règles à déboguer.

2. Garder : bloquer les actions dangereuses avant leur exécution

• CC Safety Net (4,0) refuse les force-push, les hard reset, les rm -rf sur des cibles dangereuses et la lecture de vos clés, et ne se laisse pas tromper si l'on enveloppe la commande dans bash -c. Il couvre la brèche que le bac à sable laisse ouverte.
• security-guidance (4,2), le plugin Claude Code d'Anthropic, examine chaque modification, chaque tour et chaque commit avec un nouvel appel de modèle. Il conseille et ne bloque jamais : considérez-le comme une alerte précoce plutôt que comme un verrou.

3. Relire : laisser l'agent chasser les bugs

C'est là que les agents sont réellement bons, tant que rien ne dépend du fait qu'ils trouvent tout.

• Trail of Bits Skills (4,4) regroupe les méthodes d'audit d'une société de sécurité ; les meilleures skills pilotent CodeQL et Semgrep au lieu de se fier au jugement du modèle.
• Cloudflare Security Audit Skill (3,9) fait tenter à un second agent de réfuter chaque découverte. Selon Cloudflare, une exécution trouve environ la moitié de ce que trouvent des exécutions répétées : lancez-la donc plus d'une fois.

4. Contrôler : vérifier ce que vous installez

Chaque skill, chaque plugin et chaque serveur MCP est du code et des instructions auxquels votre agent fera confiance. Cela en fait une chaîne d'approvisionnement.

• Cisco Skill Scanner (3,7) analyse les skills avant que votre agent ne les lise, et publie ses propres taux de détection, qui sont modestes.
• Snyk Agent Scan (3,8) trouve tous les serveurs MCP et toutes les skills déjà installés sur une machine. Il envoie les descriptions des outils à Snyk pour analyse.
• ToolHive (4,1) fait tourner chaque serveur MCP dans son propre conteneur verrouillé, pour qu'un serveur malveillant puisse faire moins de dégâts.

5. Filtrer : le contrôle auquel l'agent ne peut pas toucher

Le code écrit par l'IA doit passer la même barrière de fusion que le code humain. Un modèle peut être convaincu d'abandonner une découverte ; un job de CI en échec, non.

• Semgrep (4,3) comme contrôle de statut obligatoire, avec son serveur MCP ou son plugin Guardian pour que l'agent voie les mêmes règles pendant qu'il travaille.
• Avec l'offre gratuite de Semgrep, ajoutez OSV-Scanner pour les dépendances vulnérables et Gitleaks pour les secrets divulgués. Les deux sont gratuits et open source.

Si vous n'en adoptez que trois

Activez le bac à sable intégré, installez le plugin security-guidance et faites de Semgrep un contrôle de CI obligatoire. Cela fait un outil qui impose, un qui avertit tôt, et une barrière que l'agent ne peut pas contourner.

Le hic : les outils de sécurité sont aussi des outils. Les hooks tournent avec vos autorisations chaque fois que l'agent agit, les scanners envoient des données aux éditeurs, et les installeurs récupèrent @latest. Un hook de « sécurité » malveillant est plus dangereux qu'une skill malveillante, parce que sa fonction incite à lui faire confiance. Figez les versions, préférez le dépôt de l'éditeur aux forks, et essayez les nouveaux hooks d'abord dans un bac à sable.

Ce qu'aucun ne résout

• L'injection de consignes. Rien ne la détecte de façon fiable. Le confinement vient en premier parce que le mieux que l'on puisse faire est de limiter les dégâts.
• Les fuites vers des hôtes autorisés. Une liste d'autorisation décide où l'agent peut se connecter, pas ce qu'il envoie. Si GitHub est autorisé, un gist public l'est aussi. Placez une fausse clé dans un dépôt jetable et faites échouer la CI si elle apparaît un jour dans le trafic sortant.
• La logique d'autorisation. Savoir si le client A peut lire les données du client B est une question à laquelle les scanners répondent rarement et les relecteurs IA de façon inégale. Gardez un humain sur le code d'authentification et d'autorisation.
• Les approbations machinales. Quelqu'un qui clique sur « approuver » pour des dizaines de modifications d'agent par jour n'est pas un contrôle. N'envoyez aux humains que les modifications risquées, et donnez-leur le temps.

Notre avis : la détection des problèmes peut se faire à l'intérieur de l'agent. La prévention des actions dangereuses doit se faire à l'extérieur, et l'approbation du code pour la production n'a pas sa place dans la session de programmation. Installez le bac à sable avant la skill de sécurité.