Le problème de sécurité qui se cache dans vos outils de développement

Soyons directs : la plupart des équipes techniques ne savent même pas combien d'agents IA sont actifs dans leur entreprise. Cursor, Claude Code, GitHub Copilot, Gemini CLI, outils internes custom... La liste s'allonge chaque mois. Chacun avec ses propres paramètres, son propre modèle de permissions, sa propre définition de ce que signifie "sécurisé".

Ce n'est pas un scénario hypothétique. C'est la réalité de l'adoption de l'IA en entreprise aujourd'hui.

Anthropic a récemment partagé leur approche pour contenir Claude. Ça mérite qu'on s'y attarde — pas parce que c'est magique, mais parce que ça met en lumière un dilemme fondamental : plus un agent est capable, plus il est difficile à contrôler. Chez eux, tout est sous le même toit : le modèle, le runtime, le réseau, la gouvernance. Votre entreprise, elle, gère un patchwork d'outils tiers, d'autonomie développeur et de politiques de sécurité écrites à une époque où les agents IA ne pouvaient pas lire de fichiers, exécuter des commandes ou accéder au réseau.

Ce qu'Anthropic fait bien

Leur sandbox-runtime est élégant dans sa simplicité. Le principe : tout est bloqué par défaut. Si un agent dentrok tente de joindre un endpoint non autorisé, la requête meurt au niveau du proxy. Pas d'exfiltration, pas de callback, pas de dégâts.

C'est ce type de sécurité déterministe qui fonctionne vraiment. Au lieu de faire confiance au modèle pour "comprendre" qu'il ne doit pas voler des credentials, vous construisez une frontière physique. Voler devient impossible, quoi que l'agent décide de faire.

Anthropic organise leurs défenses en trois couches, classées par fiabilité :

1. La couche environnement — Les frontières dures : VM sandbox, modes de montage filesystem, allowlist réseau. C'est la fondation.

2. La couche modèle — Les contrôles comportementaux : prompts système, classifiers, workflows d'approbation. Utiles, mais explicitement reconnus comme "jamais 100% efficaces".

3. La couche contenu externe — Ce qui arrive à l'agent en premier lieu, incluant l'audit des serveurs MCP et l'inspection des sorties d'outils.

L'idée clé, c'est le classement. La couche environnement fait le gros du travail. La couche modèle aide. La couche contenu externe sert de système d'alerte.

L'attaque dont personne ne parle

Les modèles de menaces abstraits, c'est facile à ignorer. Les exemples concrets, moins.

Prenez ce scénario que les chercheurs en sécurité reproduisent régulièrement : un développeur clone un repo pour évaluer une librarie open-source. Le README a l'air clean. Scanné pour les malwares, tout OK.

Mais caché dans ce README, il y a des instructionsdestinées à l'agent IA. Pas pour l'humain qui lit le fichier — pour l'agent qui pourrait l'ingérer comme contexte. Le prompt injecté dit à l'agent de "configurer l'environnement de dev" en cherchant les fichiers .env, en repérant les credentials AWS, et en les uploadant vers un endpoint de setup.

Ce n'est pas un malware. C'est du texte. Le scanner ne détecte rien. Le développeur ne voit rien. Mais l'agent suit les instructions parce que c'est ce que font les agents — ils exécutent les tâches embarquées dans le contexte qu'ils reçoivent.

L'attaque se déroule en étapes : d'abord une probe pour les fichiers d'environnement, puis une recherche de chemins d'upload et d'exfiltration, puis la requête curl finale vers l'endpoint de l'attaquant. Chaque action semble innocente prise isolément. Ensemble, elles constituent un vol de credentials.

Pourquoi votre laptop ne suffit pas

Voici la réalité inconfortable : si cet agent tourne dans un sandbox correctement configuré, l'attaque échoue au niveau réseau. La requête curl n'atteint jamais l'attaquant. Le credential ne quitte jamais la machine.

Mais voici le pire : votre équipe sécurité n'a aucune idée que ça s'est passé.

Le sandbox contient les dégâts. Il ne contient pas la visibilité. Vous avez peut-être des dizaines de repositories compromis qui tournent en ce moment, chacun en train de sonder vos agents, chaque tentative bloquée silencieusement pendant que votre SIEM ne log rien d'utile.

C'est le problème en entreprise. Bloquer des attaques individuelles ne suffit pas. Vous devez savoir qu'elles arrivent, qui était ciblé, quels repositories bloquer, et comment écrire une politique qui couvre chaque agent de votre org — pas juste celui qui tourne dans le sandbox.

Le point aveugle des serveurs MCP

Voici la partie qui surprend la plupart des équipes : les serveurs Model Context Protocol sont la surface d'attaque la plus sous-estimée dans les déploiements d'agents IA.

Les serveurs MCP étendent ce que vos agents peuvent faire. Ils peuvent lire des bases de données, appeler des APIs, exécuter du code, accéder à des systèmes en dehors de votre infrastructure. Quand vous approvez un serveur MCP, vous accordez essentiellement à un agent des permissions élevées dans tout votre environnement.

Le problème ? La plupart des équipes approuvent les serveurs MCP une fois et ne les auditent plus jamais. Un serveur MCP compromis ou malveillant peut faire bien plus de dégâts qu'un README empoisonné parce qu'il opère à un niveau de privilège plus élevé et persiste souvent au-delà des sessions.

Votre framework de gouvernance doit traiter les serveurs MCP comme des dépendances tierces : audités, versionnés, monitorés. Un agent qui peut atteindre votre base de données production via un serveur MCP est un agent qui peut exfiltrer toute votre table clients si quelque chose tourne mal.

Ce que vous pouvez vraiment faire

Rien de tout ça n'est insurmontable, mais ça demande de traiter la sécurité des agents IA comme un problème d'infrastructure, pas un problème d'outils développeur.

Commencez par la couche environnement. Dans la mesure du possible, lancez les agents dans des environnements isolés avec des politiques réseau deny-by-default. Vos développeurs vont râler contre la friction. Ils râleront moins que vous quand les credentials fuient.

Acceptez que la couche modèle est imparfaite. Les prompts système et les classifiers réduisent le risque, mais ne l'éliminent pas. Les modèles plus capables sont meilleurs pour trouver des chemins inattendus autour des restrictions. Prévoyez ça.

Auditez vos serveurs MCP. Faites la liste de chaque serveur MCP accessible à vos agents. Traitez ça comme un inventaire logiciel. Retirez tout ce que vous ne reconnaissez pas ou ne pouvez pas auditer.

Investissez dans l'observabilité. Bloquer les attaques, c'est bien. Savoir qu'elles ont eu lieu, c'est mieux. Votre équipe sécurité a besoin de visibilité sur chaque agent de votre org, pas juste celui qui tourne dans le sandbox.

Écrivez des politiques, pas des recommandations. "Soyez prudents avec les credentials" n'est pas une politique de sécurité. "Les agents ne peuvent pas initier de connexions réseau vers des domaines non allowlistés en accédant à des repositories marqués comme externes" est une politique de sécurité. Rendez les règles explicites, applicables et cohérentes.

Le mot de la fin

La transparence d'Anthropic sur leur containment d'agents est vraiment valuable. Elle montre ce qui est possible quand une organisation contrôle toute la stack. Mais la plupart des organisations n'ont pas ce contrôle, et faire semblant du contraire, c'est comme ça que les breaches arrivent.

Les agents tournent déjà dans votre organisation. La question n'est pas de savoir si vous allez les sécuriser — c'est de savoir si vous allez maîtriser la gouvernance avant que quelque chose se passe mal.

Vos développeurs vont vite. Assurez-vous que votre infrastructure suit.