Toute l'industrie vient de s'accorder sur le fait que votre agent ne doit pas voir vos clés. Elles sont cachées au mauvais endroit.

Cette semaine, Anthropic a glissé une ligne discrète dans le journal des modifications de Claude Code : "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. En clair — quand Claude Code s'exécutait en mode headless (la façon dont il tourne dans l'intégration continue et les pipelines d'agents automatisés), les outils d'authentification censés rester cachés étaient exposés au modèle : l'IA pouvait voir les noms des outils d'authentification, leurs paramètres, et éventuellement y toucher. Dans l'agent de programmation le plus utilisé au monde — 133 000 étoiles — la couche d'identifiants fuyait dans l'endroit où vous le souhaitez le moins : le contexte même du modèle.

Cela a été corrigé. Mais le correctif est la petite histoire. La grande, c'est pourquoi tous les harnais d'agents sérieux se battent soudain sur le même front.

Trois harnais, une semaine, le même réflexe

Regardez ce qui a été livré en une seule fenêtre de 24 heures :

• Claude Code a corrigé la fuite d'auth-stub mentionnée ci-dessus et a renforcé le filtrage d'authentification MCP [1].
• Hermes (v0.17.0) a ajouté « Managed Scope » — des secrets épinglés par l'administrateur, immuables pour l'utilisateur et verrouillés au niveau du système de fichiers, afin qu'un opérateur d'agent ne puisse pas les outrepasser — ainsi que le masquage des secrets dans les journaux de débogage et le blocage des configurations MCP de forme exfiltrante avant leur lancement [2].
• Codex (v0.141.0) a enveloppé le trafic d'exécution distante dans des canaux Noise chiffrés et a commencé à router les plugins selon leur mode d'authentification [3].

Trois rivaux, trois approches, une conclusion partagée : le harnais doit posséder les secrets, et l'agent ne doit jamais voir les clés en clair. Quand des concurrents convergent ainsi dans la même semaine, ce n'est pas une mode. C'est une catégorie qui admet enfin ce qu'elle est.

Le problème suivant : la prolifération des identifiants

Voici le piège. Chacun de ces correctifs vit à l'intérieur du harnais. Et le bogue de Claude Code est l'indice : quand l'authentification vit dans le harnais, juste à côté du modèle, « l'agent ne doit jamais la voir » cesse d'être un fait pour devenir une propriété qu'il faut continuer à concevoir — et parfois à laquelle on échoue, en mode headless, là où aucun humain ne surveille. Vous ne pouvez pas la déclarer une fois pour toutes. Vous la défendez, version après version.

Mais le problème plus profond n'est pas telle ou telle fuite — c'est ce qui se passe quand chaque harnais, chaque fournisseur et chaque cas d'usage livre sa propre réponse. Vous vous retrouvez avec un coffre dans Claude Code, un coffre dans Hermes, un coffre dans Codex, un pool OAuth ici, un fichier de secrets là — un stockage d'identifiants distinct pour chaque outil que vous exécutez. C'est la prolifération des identifiants, et c'est le problème à venir, pas un problème résolu.

La prolifération est déjà une défaillance, même quand aucun silo ne fuit. Vos secrets sont copiés dans chacun d'eux pour qu'il fonctionne — plus de copies, plus d'endroits à voler. La rotation doit être faite N fois, à la main, et celle que vous oubliez est celle qui vous brûle. Et personne ne peut répondre à la seule question qui compte vraiment — quel agent a utilisé quelle clé, contre quoi, quand — parce que la réponse est éparpillée dans une douzaine de stockages qui ne se parlent pas. Vous ne pouvez pas monter un coffre neuf pour chaque fournisseur et chaque flux de travail. Cela ne passe pas à l'échelle. C'est précisément ce qui casse.

Les clés n'ont pas leur place dans le harnais

Le correctif que vous n'aurez jamais à livrer est celui où l'agent ne détient pas l'authentification dès le départ. Placez les identifiants dans une autorité unique qui se trouve en dehors de chaque harnais — pas un coffre par fournisseur, un seul sous-jacent à tous. L'agent — dans Claude Code, dans Codex, dans Hermes, peu importe — demande une action nommée et reçoit un identifiant éphémère et limité en portée, injecté pour exactement cela, récupéré en direct et disparu ensuite. Il n'y a pas d'auth-stub dans le contexte du modèle à exposer par inadvertance, puisque l'authentification n'a jamais été dans le harnais. Il n'y a pas de prolifération, puisqu'il y a un stockage unique au lieu d'un par outil — une rotation, pas N. Et chaque accès atterrit sur une piste d'audit unique au lieu de s'éparpiller dans une douzaine de silos incapables de dire qui a utilisé quoi.

(Garder le secret hors de l'endroit où le code s'exécute figure en tête des règles qu'un outil d'identifiants doit respecter — l'industrie vient de passer une semaine à le découvrir.)

Et c'est la partie qui constitue une frontière de sécurité, pas un confort : l'identifiant ne peut pas vivre dans le même système que l'agent. Les colocater, c'est leur faire partager un rayon d'impact — une injection de prompt, un serveur MCP empoisonné, un journal de débogage partagé, le prochain bogue d'auth-stub, et tout ce qui atteint l'agent atteint les clés avec. C'est pourquoi la simple visibilité est déjà la brèche : dès qu'un secret atterrit quelque part où l'agent peut le voir, vous le traitez comme déjà fuyé et vous le faites tourner — de la façon dont chaque équipe soigneuse a traité cet auth-stub de Claude Code le jour de sa livraison. Tenez l'identifiant à distance de bras, dans un système où l'agent ne peut que demander — jamais lire, jamais détenir — et un agent entièrement compromis ne peut toujours pas exfiltrer ce qui n'a jamais été à sa portée. Il peut demander une action. Il ne peut pas s'emparer de la clé. La distance est la défense ; un coffre dans le processus ne l'a à aucun prix.

C'est la ligne que Clavitor trace. Tout le domaine vient de prouver le principe — l'agent ne doit pas voir les clés. Nous pensons simplement que vous ne devriez pas avoir à le re-prouver dans chaque harnais que vous exécutez, et nous ne pensons pas que la chose qui détient vos clés doive être la même chose qu'un attaquant vient de compromettre.

Rendons justice aux équipes de harnais : des secrets épinglés par l'administrateur, des relais chiffrés, des valeurs par défaut en échec fermé, c'est de l'ingénierie réelle et de qualité. Mais un correctif de la semaine pour une fuite qui réapparaît sans cesse n'est pas une architecture — c'est un symptôme. L'architecture, ce sont des clés qui ne sont pas là pour fuir.

Quand trois concurrents corrigent la même blessure dans la même semaine, la blessure, c'est la conception. L'agent ne doit pas voir vos clés — cessez donc de les garder là où il le peut.

Clavitor (@clavitorai) est le coffre d'identifiants conçu pour les agents d'IA, et contre eux. clavitor.ai

Sources

[1] Claude Code v2.1.183 — "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (admin-pinned secrets), secret redaction, exfil-config blocking — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — encrypted Noise relay channels, auth-mode plugin routing — https://github.com/openai/codex/releases