# Exposition d'identifiants dans le presse-papiers : arrêtez d'alimenter les agents Copier un identifiant donne l'impression d'un geste temporaire, puisqu'il prend moins d'une seconde. Pourtant, ce n'est pas temporaire. L'historique du presse-papiers, le défilement du terminal, les transcriptions d'agent, la synchronisation des conversations et l'historique du shell peuvent transformer ce geste en plusieurs copies indépendantes, chacune avec ses propres règles d'accès et de conservation. Les développeurs se demandent souvent si un secret est chiffré au repos dans un gestionnaire de mots de passe. C'est important, mais le moment critique vient après la copie. Dès que le texte en clair quitte le gestionnaire de mots de passe, il peut entrer dans des outils conçus pour mémoriser, indexer, synchroniser ou rejouer exactement ce que vous avez collé. Un agent autonome rend l'erreur plus facile à répéter, car il encourage les prompts détaillés et les sorties de commandes que l'on considère à tort comme jetables. ## L'historique du presse-papiers crée un second système de stockage L'historique du presse-papiers crée un second coffre d'identifiants lorsqu'il conserve un texte après que l'application qui l'a produit l'a oublié. Le presse-papiers du système d'exploitation est déjà un état partagé. Une fonction d'historique prolonge la durée de vie de cet état et rend souvent les anciennes entrées consultables. Le risque n'est pas le même qu'une application qui lit le presse-papiers au moment précis où vous collez le contenu. Un développeur peut raisonnablement surveiller une valeur copiée juste le temps de la coller dans un outil, puis vider le presse-papiers. Une base d'historique peut conserver cette même valeur avant l'effacement et garder plusieurs versions si vous avez copié un jeton, un en-tête secret et une commande complète. Sur macOS, `pbcopy` écrit l'entrée standard dans le pasteboard et `pbpaste` la relit. Cette commodité explique pourquoi les scripts et les habitudes de débogage font si facilement passer des secrets par le presse-papiers. Exécutez ce test sans danger dans un terminal temporaire : ```sh printf '%s' 'CLIPBOARD-TEST-7f3c' | pbcopy pbpaste ``` La sortie attendue est : ```text CLIPBOARD-TEST-7f3c ``` Ouvrez maintenant chaque fonction d'historique du presse-papiers que vous utilisez et recherchez `CLIPBOARD-TEST-7f3c`. Faites de même sur les appareils qui partagent votre presse-papiers. Ce test ne prouve pas qu'un outil donné stocke tous les types de presse-papiers, mais il montre si votre parcours habituel conserve une entrée après la fin de l'opération initiale. Apple présente Universal Clipboard comme une fonction de continuité qui permet de copier sur un appareil Apple et de coller sur un autre appareil connecté au même Apple Account et répondant aux conditions de continuité. Cette documentation décrit un mécanisme de transport pratique, pas une limite de sécurité pour les secrets. Si votre identifiant se déplace vers un autre appareil, les applications locales, les sauvegardes et l'état de session de cet appareil entrent aussi dans le périmètre du risque. La réaction habituelle est : « Je ne l'ai copié qu'en local. » Local n'est pas une politique de conservation. Un gestionnaire de presse-papiers local peut fonctionner en permanence, conserver une base de données consultable, inclure des entrées dans les sauvegardes ou les transmettre à un service de synchronisation. Une machine locale peut aussi héberger d'autres sessions utilisateur, des logiciels d'administration à distance, l'enregistrement d'écran, des outils de support et des utilitaires de développement. Il ne s'agit pas de soupçonner indistinctement tous les logiciels locaux. Identifiez ce qui peut lire votre presse-papiers, la durée de conservation des données et leur éventuelle transmission ailleurs. Un secret copié n'est pas automatiquement compromis, mais il a franchi une limite que vous ne pouvez pas décrire avec la même certitude que celle d'un coffre. Cela doit modifier votre réaction. ## Un prompt d'agent est un canal de distribution d'identifiants Coller un jeton dans un prompt d'agent le distribue à davantage d'endroits que la requête n'en nécessite. L'agent peut le lire, mais le client qui conserve l'historique des conversations le peut aussi, tout comme le générateur de contexte qui prépare les tours suivants, les journaux associés au client et toute personne capable d'inspecter la transcription produite. Le prompt favorise aussi un schéma particulièrement risqué : copier une requête complète qui fonctionne parce que cela semble efficace. Un développeur colle un jeton bearer, une URL, un identifiant client et une commande `curl`, puis demande à l'agent de les modifier. L'agent peut citer la commande dans sa réponse. Le développeur peut recopier cette réponse dans un terminal. Un même secret apparaît alors dans l'enregistrement initial du presse-papiers, le prompt, la réponse, le défilement du terminal et éventuellement un fichier d'historique du shell. N'essayez pas de régler le problème avec une instruction de masquage après avoir collé la valeur. L'agent ne peut pas oublier un contexte qu'il a déjà reçu, et une instruction ne supprime ni les enregistrements locaux ni les enregistrements distants. Demandez une structure, pas des identifiants. Un prompt qui n'expose rien de sensible peut tout de même donner à un agent des indications suffisantes : ```text Call the staging inventory API endpoint GET /v1/items. Use the credential named staging-inventory. Return the status code and the count of items. Do not print request headers or authentication material. ``` Ce prompt sépare la demande d'action du matériel d'autorisation. Il indique aussi à l'agent le résultat à renvoyer, ce qui évite l'habitude courante de déverser une requête ou une réponse complète pour rassurer l'utilisateur. La distinction est constamment brouillée : une référence de secret n'est pas une valeur secrète. `staging-inventory`, `PAYMENTS_TOKEN` ou « utilise mon identifiant de déploiement de production » peuvent être des références sûres uniquement si l'agent ne peut pas les convertir en texte en clair. Si un fichier de configuration local développe la référence puis renvoie la valeur à l'agent, vous avez simplement remplacé la copie par une indirection. Considérez le texte des prompts comme un contenu susceptible d'être conservé, recherché, consulté, exporté ou inclus par erreur dans un rapport de bug. La même règle s'applique aux sorties des outils de l'agent. Un outil qui renvoie des en-têtes de requête, une erreur d'autorisation qui répète un jeton dans une URL ou une sortie de débogage verbeuse peut placer un identifiant dans le prompt suivant sans que personne ne l'y colle volontairement. ## La commodité du terminal laisse plusieurs copies Une commande shell contenant un secret littéral peut fuir par davantage de chemins que l'historique du presse-papiers. Le shell peut la conserver dans son historique. Le terminal peut la garder dans son défilement. Un multiplexeur de terminal peut l'écrire dans le journal d'un panneau. Un enregistreur peut la capturer. Sur certains systèmes, les arguments des commandes peuvent être visibles par d'autres processus locaux disposant des droits suffisants. C'est pourquoi cette commande familière est un mauvais choix par défaut : ```sh curl -H 'Authorization: Bearer eyJ...' https://api.example.test/v1/items ``` Le jeton est visible pendant la saisie ou le collage, peut finir dans le presse-papiers et peut persister dans l'historique du shell. Remplacer le jeton par une variable d'environnement le retire de la ligne de commande, mais ne le fait pas disparaître de l'environnement du processus : ```sh curl -H "Authorization: Bearer $INVENTORY_TOKEN" https://api.example.test/v1/items ``` C'est une amélioration uniquement si vous contrôlez la manière dont `INVENTORY_TOKEN` entre dans l'environnement, les processus enfants qui en héritent et l'éventuelle impression de cette valeur par les diagnostics. Ne collez pas `export INVENTORY_TOKEN=...` dans un shell interactif en pensant avoir réglé le problème. Vous avez peut-être simplement déplacé la valeur littérale dans l'historique, une commande plus tôt. Pour un travail manuel, une invite interactive est souvent plus sûre, car la saisie ne fait pas partie de la commande elle-même. Un petit script peut lire un jeton sans l'afficher : ```sh #!/bin/sh printf 'Inventory token: ' \u003e\u00262 stty -echo IFS= read -r token stty echo printf '\\n' \u003e\u00262 curl -sS -H "Authorization: Bearer $token" https://api.example.test/v1/items unset token ``` Cela empêche le secret d'apparaître dans la commande saisie et dans l'affichage normal du terminal. Cela ne transforme pas un script shell en coffre. Le processus conserve toujours la valeur en mémoire, `curl` reçoit un en-tête et un mode verbeux ou un journal de proxy peut la divulguer. Utilisez ce modèle pour une courte récupération manuelle, pas comme architecture d'intégration permanente. La meilleure conception garde l'identifiant en dehors du parcours de la commande. Laissez un composant capable de gérer les identifiants envoyer la requête et renvoyer uniquement les données dont le développeur ou l'agent a besoin. Si la tâche consiste à « me dire si le déploiement X est terminé », le résultat doit être un état et un horodatage, pas un échange HTTP authentifié complet. ## Les outils de presse-papiers partagé élargissent discrètement le public Les outils de presse-papiers partagé sont dangereux pour les identifiants, car le partage transforme une copie locale en mécanisme de livraison. L'exposition peut concerner le client de bureau d'un collègue, une extension de navigateur, une intégration de chat, un espace de travail distant ou un appareil dont vous avez oublié la session ouverte. Les développeurs jugent souvent ces outils selon leur intention. Un presse-papiers partagé est conçu pour aider une équipe à déplacer rapidement des extraits, il ressemble donc à un canal de travail. Les identifiants ne se soucient pas de l'image professionnelle du canal. Si chaque participant peut récupérer une entrée plus tard, vous avez accordé à chacun l'accès à ce secret. Le cas le plus délicat est celui du canal d'incident temporaire. Quelqu'un a besoin d'un jeton API pour diagnostiquer une panne de production et un collègue dit : « Dépose-le dans le presse-papiers partagé, je le supprimerai après. » Ne le faites pas. Le destinataire peut le coller dans son propre historique shell. Le service peut enregistrer l'élément avant sa suppression. Un client local de synchronisation peut le télécharger sur plusieurs appareils. Depuis votre machine, vous ne pouvez pas vérifier la suppression de toutes les copies. Envoyez une référence et définissez un parcours approuvé pour utiliser l'identifiant. Si un humain doit recevoir un secret, utilisez la méthode de partage de secrets désignée par l'organisation, avec des contrôles d'accès et une expiration. Si cette méthode n'existe pas, créer un identifiant de remplacement à portée étroite et le révoquer après l'incident est généralement moins imprudent que d'utiliser un outil de collaboration comme canal de secrets. Le partage du presse-papiers provoque aussi un échec plus subtil : les développeurs copient un secret localement, puis activent la synchronisation, installent un utilitaire d'historique ou se connectent sur un second appareil. Les anciennes entrées peuvent devenir accessibles pour la première fois. Vérifiez les paramètres de conservation et de synchronisation avant un travail sensible, mais partez du principe que les copies passées nécessitent leur propre investigation. ## Vider le presse-papiers n'efface pas la trace Vider le presse-papiers actuel ne fait que remplacer son contenu actuel. Cela ne garantit pas la suppression d'une base d'historique, d'un enregistrement de synchronisation, d'un terminal, d'une conversation d'agent ou des journaux de l'application destinataire. Vous devez tout de même vider le presse-papiers après une copie accidentelle, car cela réduit l'exposition occasionnelle. Sur macOS, cette commande remplace le contenu texte du presse-papiers par une chaîne vide : ```sh printf '' | pbcopy ``` Ne présentez pas cette opération comme une remédiation. C'est une mesure de confinement. Il en va de même pour le bouton « supprimer » visible dans un gestionnaire de presse-papiers. Il peut retirer l'entrée de l'interface tout en laissant des sauvegardes, des répliques synchronisées, des données indexées ou un autre terminal la conserver. Traitez une copie accidentelle comme un petit incident. La réponse dépend de la portée de l'identifiant, mais l'ordre des actions compte : 1. Cessez d'utiliser l'identifiant exposé et révoquez-le ou faites-le tourner lorsque l'émetteur le permet. 2. Videz le presse-papiers actuel et supprimez l'entrée connue de l'historique sur chaque appareil que vous contrôlez. 3. Recherchez les destinations probables : conversations d'agents, historique du terminal, journaux du terminal, scripts shell, notes, commentaires de tickets et fichiers du dépôt. 4. Examinez l'activité du service associée à l'identifiant pour repérer les actions que vous ne reconnaissez pas. 5. Notez ce qui s'est passé et corrigez le processus qui a rendu le collage nécessaire. Certaines personnes refusent de faire tourner un identifiant parce qu'elles ne peuvent pas prouver qu'un tiers a lu l'entrée. C'est compréhensible pendant une panne, mais ce n'est pas le bon niveau de preuve. Vous savez que le secret a atteint un stockage ou un canal hors de son contrôle prévu. Le coût de la rotation doit être comparé aux privilèges et à la durée de vie de l'identifiant, pas à votre capacité à prouver un vol. Ne faites pas tourner un identifiant à l'aveugle en laissant ensuite un ancien jeton non révoqué dans l'historique d'une commande. Vérifiez que l'ancien identifiant ne fonctionne plus. Si le fournisseur ne peut pas révoquer des valeurs individuelles, réduisez la fenêtre d'exposition en modifiant le secret parent ou la politique d'accès, puis documentez cette limite pour le prochain incident. ## Les gestionnaires de mots de passe réduisent les copies sans supprimer les risques Les gestionnaires de mots de passe règlent bien le problème du stockage lorsqu'ils conservent les secrets chiffrés et contrôlent leur récupération. Ils ne contrôlent pas ce qui se passe après qu'une application a collé une valeur dans un prompt, un terminal, un formulaire ou un historique du presse-papiers. De nombreux gestionnaires de mots de passe proposent un délai d'effacement du presse-papiers. Utilisez-le. Il limite la durée pendant laquelle le presse-papiers actif contient du texte en clair. Mais il ne peut pas effacer de manière fiable une entrée d'historique créée par un autre programme, un enregistrement synchronisé ou un texte déjà collé dans une autre application. Cette fonction aide à éviter les collages accidentels ultérieurs. Elle ne justifie pas un usage généralisé de la copie. La solution la plus sûre consiste à utiliser l'intégration du gestionnaire de mots de passe uniquement pour les destinations qui ont réellement besoin du texte en clair et savent le protéger. Un client API qui stocke les secrets dans un fichier d'espace de travail local est souvent une destination plus risquée qu'il n'y paraît. Un formulaire web peut les divulguer à cause d'erreurs de remplissage automatique. Une commande de terminal est généralement le pire endroit, car les développeurs recopient souvent la même commande dans des tickets et des conversations lorsqu'un problème survient. Adoptez un jugement différent pour un mot de passe qu'un humain doit saisir dans une page de connexion et pour un identifiant machine utilisé dans des appels API ou SSH. Pour un mot de passe humain, il n'existe parfois aucune alternative utile à une saisie contrôlée. Un identifiant machine devrait généralement rester derrière une limite d'action, afin que ni l'agent ni l'humain n'aient à le déplacer sous forme de texte. Cette distinction aide les équipes à éviter une règle improductive comme « ne copiez jamais de secrets ». Il faut parfois qu'un humain copie un code de récupération. La règle utile est plus précise : ne copiez pas un secret dans un système qui enregistre, synchronise, interprète ou redistribue du texte, sauf si ce système est explicitement autorisé à conserver ce secret. ## L'injection d'identifiants est préférable à l'autorisation au niveau du prompt L'injection d'identifiants est plus sûre que l'autorisation au niveau du prompt, car l'agent demande une action sans recevoir le matériel qui l'autorise. L'agent peut dire « effectue cette requête HTTPS avec l'identifiant X », tandis qu'un composant local distinct fournit l'en-tête d'autorisation et renvoie un résultat filtré. Cette architecture limite le mode d'échec le plus dangereux des flux de travail avec agents : l'agent exfiltre un identifiant en le répétant dans un fichier, une réponse, un message de commit ou un prompt suivant. Si l'agent ne reçoit jamais la valeur, il ne peut pas l'afficher par erreur. Il peut toujours mal utiliser l'autorité qui lui est accordée, ce qui impose des contrôles d'approbation et d'audit autour de l'action elle-même. SSH doit bénéficier du même traitement. Copier une clé privée dans le contexte d'un agent est indéfendable. La copier dans un heredoc de terminal est à peine moins risqué. Un parcours SSH correct conserve la clé privée dans un stockage protégé, effectue localement la signature ou l'établissement de la connexion et renvoie à l'appelant la sortie de la commande plutôt que le matériel de la clé. Sallyport applique ce modèle à HTTP et SSH : son coffre contient les identifiants API et SSH, tandis que les agents demandent des actions via le shim MCP intégré au lieu de recevoir des identifiants en clair. Sa barrière de coffre, l'approbation de session et l'approbation facultative de chaque utilisation d'identifiant contrôlent les actions, sans demander aux développeurs d'écrire des règles de politique. Ne confondez pas cela avec un proxy réseau ou un moteur de règles général. Une passerelle d'action ne peut pas corriger une requête qu'un agent autorisé n'aurait jamais dû être capable d'effectuer. Elle peut rendre l'autorisation visible, exiger une décision humaine à la limite prévue et garder le secret hors du prompt et du parcours du presse-papiers. ## L'approbation doit décrire l'action, pas afficher le secret Un écran d'approbation doit indiquer qui a demandé l'action, quelle autorité d'identification cette personne souhaite utiliser et quelle opération sera exécutée. Il ne doit jamais obliger un humain à comparer ou inspecter le secret lui-même. C'est là que beaucoup de wrappers maison échouent. Ils conservent un jeton dans un fichier de configuration, puis affichent la commande `curl` entièrement développée pour approbation. Le développeur a évité de copier le jeton dans un prompt d'agent, mais le révèle dans la boîte de dialogue d'approbation et ses journaux. Un enregistrement sûr peut afficher `credential: staging-inventory`, `method: GET`, `host: api.example.test` et `path: /v1/items`. Il n'a aucune raison d'afficher un en-tête d'autorisation. La fatigue liée aux approbations révèle un défaut de conception lorsque chaque requête de lecture sans danger produit une boîte de dialogue vague. Les utilisateurs valident ces boîtes de dialogue sans les lire, car les informations ne les aident pas à décider. Une demande utile indique l'identité de signature du code du processus demandeur, distingue un nouveau processus d'un processus déjà approuvé et précise si l'action actuelle utilisera un identifiant nécessitant une approbation individuelle. Le résultat de l'action doit lui aussi rester ciblé. Par exemple, un appel d'état de déploiement peut renvoyer ceci : ```json {"deployment":"api-472","state":"completed","finished_at":"2025-04-17T11:26:00Z"} ``` Il ne doit pas renvoyer les en-têtes de requête, l'intégralité du corps s'il contient des données client sans rapport ou un débogage détaillé qui pousserait un agent à répéter des secrets dans le contexte suivant. Filtrer la sortie n'est pas une question esthétique. Cela limite ce qui sera copié ensuite. ## Les traces d'audit doivent permettre de savoir si l'agent a agi Une trace d'audit doit distinguer une exécution d'agent d'un appel individuel utilisant un identifiant. Un enregistrement de session indique quel processus a reçu l'autorité et permet de révoquer cette exécution. Un enregistrement d'appel indique ce qu'il a fait après l'autorisation. Un seul enregistrement ne répond pas clairement aux deux questions. Les journaux doivent aussi éviter de devenir un nouveau coffre de secrets. Conserver la requête complète pour faciliter l'analyse est tentant, surtout pendant le développement. N'enregistrez pas les en-têtes d'autorisation, les cookies bruts, les clés privées ni les corps de requête contenant des identifiants. Enregistrez la référence de l'identifiant, la destination, la méthode, le chemin, le résultat, l'heure, l'identité du processus et la décision d'approbation. Ajoutez les identifiants de requête lorsque le service cible en fournit. La preuve d'altération compte lorsqu'un agent peut agir sans surveillance. Un journal qu'un processus peut réécrire après coup ne permet pas de trancher ce qui s'est passé. Un enregistrement chaîné par hachage permet à un auditeur de vérifier que les entrées n'ont pas été supprimées ou modifiées, sans exposer le contenu des identifiants. Sallyport projette les journaux de session et d'appel à partir d'un journal d'audit chiffré et chaîné par hachage, et `sp audit verify` vérifie la chaîne hors ligne sans nécessiter de clé du coffre. C'est un meilleur artefact d'incident qu'une transcription de terminal, car il enregistre les actions autorisées sans traiter chaque chaîne copiée comme une preuve à conserver. Lorsqu'un incident implique un secret copié, utilisez la trace d'audit pour répondre à des questions concrètes : quel processus d'agent a été exécuté ? Quelles destinations a-t-il atteintes ? A-t-il tenté une écriture ? Une session a-t-elle été révoquée avant un autre appel ? Ces réponses vous aident à délimiter l'incident. Elles ne prouvent pas qu'aucun lecteur du presse-papiers n'a vu la valeur originale, raison pour laquelle la rotation reste nécessaire. ## Le flux de travail à supprimer cette semaine Retirez les identifiants littéraux des parcours que votre équipe traite comme du texte ordinaire. Commencez par les endroits où copier et coller semble le plus naturel : prompts d'agent, commandes de terminal, outils de partage de presse-papiers, commentaires de tickets et brouillons de conversations d'équipe. Organisez un court exercice sur table avec un marqueur inoffensif comme `CLIPBOARD-TEST-7f3c`. Copiez-le une fois, puis recherchez-le dans les outils d'historique, les enregistrements du terminal, les sessions d'agent et les appareils synchronisés réellement utilisés par votre équipe. Vous trouverez plus vite le parcours important dans votre environnement en procédant ainsi qu'en débattant de conseils de sécurité généraux. Rendez ensuite le parcours sûr moins pénible que l'ancien. Donnez aux agents une interface d'action qui accepte des références d'identifiants, gardez les approbations de session compréhensibles, réservez l'approbation individuelle aux identifiants sensibles et renvoyez uniquement le résultat nécessaire pour continuer le travail. Si un développeur doit exposer du texte en clair pour réaliser une automatisation courante, le flux présente encore une faille. Un secret devrait passer sa vie utile dans un stockage protégé et dans le processus qui l'utilise. Il ne devrait pas faire le tour du presse-papiers simplement parce que le copier est facile.