Un agent de code IA a exécuté printenv pour déboguer un déploiement, et a ainsi introduit un token de session AWS actif dans sa fenêtre de contexte. Personne n'a rien fait de mal. C'est pourquoi nous avons créé ctxcop, un outil CLI open source qui retire les secrets du contexte de l'agent avant que le modèle ne les voie.
Votre agent de code IA n'a pas besoin de vos identifiants pour faire son travail. Nous avons construit un hook CLI qui arrête de les transmettre, et l'avons publié en open source.
Il y a quelques mois, j'ai observé un agent de code IA déboguer un déploiement en échec. Il a exécuté printenv, ce que j'aurais fait moi-même. Le problème, c'est que printenv sur cette machine affichait un token de session AWS actif. Ce token s'est retrouvé dans la fenêtre de contexte du modèle, puis dans la transcription de la conversation qui traînait en texte clair sur l'ordinateur portable, puis sur l'ordinateur de quelqu'un d'autre. Il aurait tout aussi bien pu se retrouver dans tout un tas de logs.
Personne n'a rien fait de mal. L'agent se montrait utile et l'ingénieur était productif. Un identifiant de production s'est simplement retrouvé quelque part que personne parmi nous n'avait décidé.
C'est toute la raison de cet article.
Le réflexe
Quand un nouvel outil puissant apparaît, le réflexe sécurité, c'est de le verrouiller. Rédiger une politique, l'interdire dans le manuel, le faire passer par un comité de revue. Cela donne une impression de contrôle.
Ce n'est pas le cas. Les ingénieurs ont adopté les agents de code IA plus vite que n'importe quel autre outil que j'ai vu, et ils l'ont fait, que la sécurité donne son feu vert ou non. Interdisez l'outil, et vous n'obtenez pas la sécurité. Vous obtenez la même exposition des identifiants, mais hors d'un workflow validé, et une équipe sécurité qui n'y voit plus rien du tout. Vous perdez productivité et visibilité en même temps.
« Contre » n'a donc jamais vraiment été le camp gagnant. Ce qui marche, c'est d'aller à la rencontre de l'outil là où il s'exécute, et d'y intégrer le garde-fou directement.
Need to know
Le garde-fou repose sur une vieille idée : le besoin d'en connaître.
Je veux être précis dans cette affirmation, car la version bruyante de cette histoire est fausse. Je ne dis pas qu'on ne peut pas faire confiance à Anthropic ou à OpenAI (ni à Deepinfra et consorts). La plupart des fournisseurs sont solides sur le plan contractuel, et plusieurs d'entre eux ne s'entraînent pas sur votre contexte. Mais ils conservent quand même des logs, parfois à plusieurs endroits, pour plusieurs raisons, chez plusieurs de leurs propres prestataires. Non, mon affirmation est plus modeste et plus difficile à contester : vous ne devriez confier à aucun tiers plus d'informations qu'il n'en faut pour faire le travail. Personne n'a besoin d'agir de mauvaise foi pour que cela compte. Garder un petit rayon d'impact est simplement une bonne pratique, et la fenêtre de contexte d'un agent de code est un nouvel endroit où la mettre en œuvre.
Un agent doit pouvoir raisonner sur votre code et sur le monde dans lequel ce code fonctionne. Il n'a pas besoin de la valeur littérale du mot de passe de votre base de données pour cela. Il a besoin de la forme du problème, pas du secret. Nous avons donc arrêté de lui donner le secret.
Un flic pour la fenêtre de contexte
C'est ctxcop, l'abréviation de « context cop » (le flic du contexte).
C'est un outil CLI simple qui s'installe dans n'importe quel agent que vous utilisez : Claude Code, Cursor, Codex, Pi, OpenCode, Aider, quel que soit celui que nous utiliserons tous demain. Il s'accroche aux moments où un secret pourrait passer de votre machine vers le contexte du modèle. Quand l'agent exécute une commande, lit un fichier ou appelle un outil, ctxcop examine la sortie avant que le modèle ne la voie, et remplace tout ce qui ressemble à un identifiant :
Le modèle reçoit un espace réservé à la place du secret. La commande s'est quand même exécutée avec la vraie valeur dans votre shell. Le modèle ne l'a simplement jamais vue. Rien ne quitte votre machine. Il n'y a aucun proxy ou passerelle à faire tourner, ni de compte à créer. Vous lancez ctxcop install, il trouve vos agents et s'y intègre. C'est open source sous licence MIT, parce que la confiance aveugle est toujours le mauvais choix quand on travaille avec des secrets.
La censure n'est que la moitié du travail. Quand ctxcop retire un secret, il laisse aussi une note à l'agent : c'était un identifiant, nous l'avons retiré, et si tu as besoin de la valeur, référence-la indirectement. Il prépare aussi l'agent en début de session, pour que ces conventions ne soient pas une surprise plus tard. Ainsi, l'agent ne se retrouve pas avec un espace réservé mystérieux et ne se met pas à deviner. Il n'essaie pas de décoder la censure en base64 ni de relancer la commande pour obtenir la vraie valeur. On lui dit ce qui s'est passé, et il continue de travailler.
Cette partie est délibérée : nous n'essayons pas seulement d'arrêter de nous battre contre nos développeurs, nous essayons aussi d'arrêter de nous battre contre l'agent. Un garde-fou qui altère silencieusement les entrées d'un agent est un garde-fou que celui-ci apprendra tôt ou tard à contourner. Si un outil s'explique à la place, l'agent peut coopérer avec lui.
Aucune des parties difficiles (trouver réellement les secrets) n'est de notre fait. ctxcop s'appuie sur betterleaks, le successeur maintenu de gitleaks, et sans lui, ce projet aurait été une véritable galère à construire. Nous récupérons gratuitement tout son moteur de détection et son ensemble de règles. Ce sur quoi nous nous appuyons encore plus, c'est à quel point c'est extensible. Les règles ne sont que de la configuration, vous pouvez donc renforcer les nôtres, ajouter des motifs pour vos propres données sensibles internes, ou charger tout un pack supplémentaire avec une seule variable d'environnement. C'est exactement ainsi que ctxcop livre un ensemble de règles optionnel pour les cryptomonnaies et les données personnelles financières : désactivé par défaut, une variable pour l'activer. Vos secrets ne sont pas nos secrets, et betterleaks permet de le dire facilement.
Comment ça fonctionne
Chaque harnais a sa propre approche de l'extensibilité, donc cela varie d'un harnais à l'autre. Consultez https://github.com/webflow/ctxcop/blob/main/docs/harnesses.md pour les détails, mais examinons les hooks de Claude Code à titre d'exemple :
Sur SessionStart, ctxcop oriente l'agent en lui fournissant un préambule via hookSpecificOutput.additionalContext, qui indique à Claude que ctxcop est accroché à la session, à quoi ressemble un motif censuré, et quoi faire s'il en rencontre un.
Quand l'agent décide d'utiliser l'outil Bash, ctxcop s'accroche à PreToolUse et réécrit la commande prévue par l'agent :
cat .env ⇒ ctxcop run -- bash -c 'cat .env'
Quand ctxcop encapsule une commande, il scanne stdout et censure selon les règles avec lesquelles il est configuré, en laissant suffisamment d'éléments pour que l'agent puisse raisonner, avec un rappel sur la façon de travailler avec des secrets sans polluer le contexte :
Il existe plusieurs autres surfaces pour Claude Code : si un utilisateur colle un secret dans le prompt, si l'agent lit un fichier, ou utilise des serveurs MCP, ctxcop s'accroche aussi à ces événements, en veillant à préserver la valeur de l'opération tout en maintenant la confidentialité là où c'est possible.
Ce qu'il ne fait pas
Un outil de sécurité qui se survend est pire que pas d'outil du tout, alors voici ce que ctxcop ne fait pas.
Il agit sur le contenu. Il censure ce que le modèle voit. Ce n'est ni un pare-feu, ni un proxy de sortie, ni un moniteur comportemental. Il n'arrêtera pas une attaque SSRF. Il ne connaît ni ne se préoccupe d'un outil MCP corrompu ou d'une exfiltration lente en plusieurs étapes. Ce sont des problèmes réels, qui se situent à une autre couche. ctxcop se place à côté d'un contrôle de sortie réseau, il ne le remplace pas.
Pipelock et Runlayer sont de bons exemples de cette autre couche. Ils agissent sur le réseau plutôt que sur la vision qu'en a le modèle, et appliquent les règles au point de sortie plutôt que sur votre machine. C'est un modèle de fonctionnement différent, avec ses propres avantages réels, et cela vaut vraiment la peine d'y jeter un œil. L'équipe derrière Pipelock publie aussi un benchmark externe et neutre vis-à-vis des fournisseurs, appelé agent-egress-bench. Nous avons exécuté les parties applicables à ctxcop et publié les résultats dans le dépôt, y compris chaque catégorie que nous ne couvrons pas. Si vous voulez savoir où sont les limites, elles sont écrites noir sur blanc.
Travailler avec
Je pense que c'est à cela que ressemble une équipe sécurité qui grandit autour d'un nouvel outil plutôt que de se dresser devant lui.
Les agents ne vont nulle part, et la pression sur chaque ingénieur pour les utiliser non plus. Le rôle de la sécurité n'est pas d'être le service qui dit toujours non, c'est d'intégrer la sécurité dans les workflows des utilisateurs. Utiliser un outil en toute sécurité devrait être simple, intuitif, et clair sur les zones de risque.
ctxcop est un garde-fou pour une frontière. Il est ouvert et disponible sur github.com/webflow/ctxcop. Lisez-le, testez-le, et dites-nous s'il vous aide à mieux dormir la nuit.
