Vous avez réparti le travail entre treize agents. Paperclip n'a pas réparti la clé.

Vous avez fait la chose moderne. Au lieu d'un seul gros agent, vous avez monté une flotte — un pour trier les tickets, un pour rédiger les contenus, un pour piloter le pipeline de design, une douzaine au total, chacun avec sa tâche et sa propre config. Cela semble plus sûr ainsi. Rayon d'impact plus réduit. Davantage de moindre privilège.

Puis un scan de sécurité a passé en revue les configs d'un framework d'agents comptant 71 000 étoiles, appelé Paperclip, et a découvert que douze de ses treize agents transportaient les mêmes identifiants — un jeton identique, collé en clair dans la config de chaque agent [1]. Une clé API Anthropic se trouvait codée en dur dans la config d'un agent de design, en clair. Un jeton de bot destiné à un seul agent était lisible par des agents qui n'avaient rien à y voir.

Treize portes. Une seule clé, copiée dans douze d'entre elles. Volez-la à l'agent le plus faible, et vous obtenez les onze autres.

Ce qui s'est réellement passé

Paperclip attribue à chaque agent une config de serveur MCP — le fichier qui indique à l'agent quels outils et services il peut atteindre, et comment s'y authentifier. En cours de route, les secrets sont directement atterris dans ces fichiers sous forme de texte littéral : un JWT n8n, un jeton bearer, une clé API Anthropic. Pas référencés. Pas injectés à l'exécution. Saisis à la main — puis, comme créer l'agent suivant se résume à un copier-coller, dupliqués dans toute la flotte.

Le scan a signalé trois points. Les jetons en clair partagés entre douze agents (classés HIGH). La clé Anthropic présente en clair dans la config d'un agent de design (classée CRITICAL). Et un jeton de bot accessible à des agents auxquels il n'était pas destiné — un manquement classique au moindre privilège [1]. À leur décharge, l'équipe Paperclip a réagi vite : elle est passée à des références d'identifiants, a masqué la config lors des lectures inter-agents, et a commencé à imposer la synchronisation des liaisons [2]. La bonne direction.

Il ne s'agit pas d'une négligence de Paperclip

Voici le point qui mérite qu'on s'y arrête. Paperclip a fait ce que fait presque tous les frameworks. Placer un secret dans un fichier de config est la façon dont le logiciel s'authentifie depuis trente ans. Cela fonctionnait parce qu'il y avait une application, une config, un opérateur qui savait où se trouvait la clé.

L'ère a changé sous l'effet de cette habitude. Un système multi-agents n'est pas une application avec une config unique — c'est une douzaine de processus, chacun avec un fichier, chacun une copie du précédent. Le « en clair dans la config » était un raccourci tolérable lorsqu'il n'y avait qu'un seul endroit où fuiter. À treize, le même raccourci signifie qu'une fuite en vaut treize — et la question « quel agent a fait ça ? » n'a pas de réponse, puisque le jeton présent dans le journal appartenait à tous.

Les références d'identifiants — le correctif livré par Paperclip — sont réellement meilleures. Mais notez ce qu'elles changent et ce qu'elles ne changent pas. Une référence se résout toujours vers un secret réel à l'endroit où s'exécute l'agent ; l'agent, ou tout ce qui le compromet, peut toujours lire la valeur résolue. Et le suivi de bugs du framework montre déjà le mode de défaillance suivant : une référence qui se désynchronise de sa liaison, si bien que la config paraît remplie tandis que la validation échoue silencieusement [3]. Le secret a reculé d'une couche. Il n'a pas quitté le bâtiment.

Il ne s'agit pas que de Paperclip

Même semaine, même cause racine, entrepôts différents. Un agent de codage largement utilisé a été signalé pour afficher des valeurs brutes de .env — mots de passe, jetons, clés API — directement dans sa sortie de conversation. Un autre exécuteur d'agents a été surpris transmettant l'intégralité de l'environnement parent à ses sous-processus, rendant chaque clé de fournisseur visible pour un processus enfant [4]. Un hook vocal écrivait des transcriptions, identifiants compris, dans un /tmp accessible à tous [5]. Des équipes indépendantes, des modèles de menace indépendants, une hypothèse partagée : qu'il est acceptable que le secret vive là où l'agent peut le voir. Tout l'argument d'un attaquant consiste à montrer que non.

Conçu pour cela, de manière délibérée

Clavitor part de l'hypothèse inverse : l'agent ne détient jamais l'identifiant. Il demande une action ; la requête est interceptée, authentifiée contre un secret que l'agent ne peut pas lire, puis exécutée. Il n'y a pas de config où coller un jeton, parce qu'il n'y a pas de jeton dans la config. Rien à copier entre treize agents, parce que l'environnement de l'agent ne contient jamais ce qui vaut la peine d'être volé.

Chaque agent n'atteint que ce pour quoi il a été nommé — pas l'ensemble du coffre — de sorte qu'un jeton de bot ne peut pas se retrouver lisible par un agent qui ne l'a jamais demandé. Et chaque action est journalisée sur l'acteur précis qui l'a effectuée, jamais sur un jeton partagé que douze agents avaient en commun — la question « lequel a fait ça ? » a donc une réponse.

La limite, en toute honnêteté : cela ne rend pas un agent inviolable. Un agent compromis peut toujours faire, sur le moment, ce qu'il était autorisé à faire. Ce qu'il ne peut pas faire, c'est s'en aller avec la clé et devenir les douze autres — parce qu'il n'y a aucune clé dans ses mains à emporter.

La leçon n'est pas « faites tourner le jeton »

Paperclip fera tourner les jetons, terminera la migration et clôturera les tickets. Tant mieux — c'est ce qu'il faut faire. Mais la rotation n'est pas la leçon. La leçon, c'est que dès que vous avez une flotte d'agents au lieu d'une application, « le secret vit dans la config » cesse d'être un raccourci et devient un multiplicateur. On ne corrige pas un multiplicateur en rendant le secret un peu plus difficile à lire. On le corrige en s'assurant que le secret n'a jamais été entre les mains de l'agent.

Nous avons consigné les règles qu'un outil de gestion d'identifiants devrait respecter à l'ère des agents — notamment que le secret ne vit jamais là où le code s'exécute, et qu'un agent n'atteint que ce pour quoi il a été nommé. Faites passer le vôtre au crible de ces règles : clavitor.ai/rules.

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

Sources

[1] Framework d'agents Paperclip — constats d'hygiène des identifiants (CFG-H1 jetons en clair partagés, CFG-C1 clé Anthropic codée en dur, CFG-H2 jeton de bot mal ciblé) : https://github.com/paperclipai/paperclip

[2] Paperclip — imposer la synchronisation des liaisons de secrets des agents sur les flux de cycle de vie (fusionné) : https://github.com/paperclipai/paperclip/pull/8307

[3] Paperclip — les entrées d'environnement secret_ref peuvent se désynchroniser des lignes secret_bindings, la config paraît remplie mais la validation échoue silencieusement (#8309) : https://github.com/paperclipai/paperclip/issues/8309

[4] Chetter — runBatchAgent hérite de l'environnement complet de l'exécuteur, exposant les clés API des fournisseurs au sous-processus (#56) : https://github.com/flatout-works/chetter/issues/56

[5] Hook vocal Claude Code — transcriptions complètes (identifiants compris) écrites dans un /tmp accessible à tous (#58) : https://github.com/rodlaneedu-hash/claude-code-voice-hook/issues/58