Épingler les versions des clients d'agents avant un accès sensible

Un client d'agent local ne devrait pas accéder à des services sensibles simplement parce que son nom figure sur une liste d'outils approuvés. L'exécutable, son environnement d'exécution, ses extensions et sa façon de démarrer déterminent ce qui enverra la requête. Si l'un de ces éléments change, vous avez affaire à un sujet de sécurité différent, même si le titre de la fenêtre et le nom de la commande semblent familiers.

L'épinglage de version des clients d'agents est une pratique de contrôle des mises en production, pas un remède aux mauvaises instructions ou aux permissions excessives. Il vous donne une propriété utile : vous pouvez tester un artefact connu, consigner ce que vous avez testé et refuser l'accès sensible à un remplacement qui n'a pas été examiné. Cela peut sembler banal. Pourtant, cette mesure évite un nombre surprenant de problèmes prévisibles.

J'ai vu des équipes consacrer beaucoup d'efforts aux coffres et aux fenêtres d'approbation, puis laisser un programme de mise à jour de bureau remplacer pendant la nuit le programme qui effectuait ces requêtes. Un humain restait bien dans la boucle, mais il approuvait le comportement d'un code que personne n'avait évalué. Ce n'est pas une limite de sécurité utile.

Épinglez l'identité de l'exécutable, pas une étiquette de version conviviale

Un numéro de version exact est nécessaire, mais il ne suffit pas à identifier correctement un client local. Une étiquette comme 2.4.1 indique ce que l'éditeur voulait publier. Elle ne prouve ni quels octets vous avez installés, ni qui les a signés, ni quel environnement les a lancés, ni si une extension a modifié leur comportement après le démarrage.

Un registre d'approbation exploitable identifie l'artefact à plusieurs niveaux :

• Le nom du client et la chaîne de version exacte.
• Le condensat SHA-256 du programme d'installation ou de l'exécutable téléchargé.
• L'autorité de signature du code et l'identifiant du bundle lorsque le système d'exploitation les expose.
• Le chemin d'installation, la version de l'environnement d'exécution et l'inventaire des extensions.
• La date, la personne chargée de la revue et les services ou périmètres d'identifiants approuvés pour cette fiche.

La différence entre une version épinglée et un artefact épinglé compte. Une version épinglée indique à un programme d'installation quelle version rechercher. Un artefact épinglé vous permet de refuser un fichier différent de celui que vous avez testé. Les équipes confondent souvent les deux, car les gestionnaires de paquets utilisent le mot « pin » pour l'un comme pour l'autre. La conséquence est fâcheuse : elles approuvent 1.4.3, reçoivent une nouvelle compilation 1.4.3 depuis un miroir compromis ou un cache modifié, et ne disposent d'aucun test local pour le détecter.

Une identité de signature ajoute une vérification, mais elle ne remplace pas un condensat. Un éditeur légitime peut signer une version défectueuse, et un condensat seul ne vous indique pas si le fichier provient bien de l'éditeur attendu. Lorsque le client accède à des systèmes de production, consignez les deux informations.

Ne transformez pas cette démarche en formalité administrative. Le registre doit répondre à une question pendant un incident : « Quel code avait l'autorisation d'envoyer cette requête ? » S'il indique seulement « l'agent de programmation », il ne répond pas à la question.

Un arbre de dépendances verrouillé n'est pas un client examiné

Les fichiers de verrouillage sont utiles, mais ils résolvent un problème plus limité que ne le pensent de nombreuses équipes. Un verrou de paquet sélectionne les versions des dépendances pour une installation donnée. Il n'examine pas les modules natifs, ne vérifie pas toutes les actions post-installation, n'empêche pas un environnement d'exécution de charger du code depuis un répertoire utilisateur et n'établit pas que l'exécutable lancé correspond à l'artefact examiné par la personne chargée de la revue.

Cela compte particulièrement pour les clients distribués dans des écosystèmes de langages. Une commande qui ressemble à un seul programme peut en réalité être un petit lanceur, un environnement d'exécution, un arbre de paquets et un ou plusieurs modules d'extension téléchargés. Épingler uniquement le paquet de premier niveau peut laisser la plus grande partie de la décision de confiance sans contrôle.

La spécification OpenSSF SLSA établit une distinction utile entre la provenance et l'intégrité. La provenance décrit où et comment un artefact a été construit. Les contrôles d'intégrité établissent qu'un artefact n'a pas été modifié. Aucune de ces affirmations ne signifie que le programme peut recevoir des identifiants en toute sécurité. Elles restent toutes deux importantes, car une équipe ne peut ni examiner ni reproduire une cible qui change constamment.

Commencez par cartographier ce qui s'exécute lorsqu'un développeur démarre l'agent. Sous macOS, interrogez le shell au lieu de faire confiance à une icône du Dock :

command -v agent-client
file "$(command -v agent-client)"
head -n 1 "$(command -v agent-client)"

La commande head est importante lorsque le premier résultat est un script. Une première ligne comme #!/usr/bin/env node indique que l'environnement Node et l'arbre de paquets font partie du parcours d'exécution. Une première ligne qui délègue à un autre lanceur signifie qu'il faut poursuivre la trace. N'approuvez pas un alias shell, un lien symbolique ou un script d'amorçage comme s'il s'agissait du client.

Pour un bundle d'application, examinez l'exécutable réel et les métadonnées de signature :

APP="/Applications/Agent Client.app"
BIN="$APP/Contents/MacOS/Agent Client"
shasum -a 256 "$BIN"
codesign -dv --verbose=4 "$APP" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='
spctl --assess --type execute --verbose=4 "$APP"

La sortie du hachage suit généralement la forme digest path. La sortie de codesign comprend normalement un identifiant, un identifiant d'équipe et une ou plusieurs lignes d'autorité. Conservez cette sortie avec le registre d'approbation. spctl demande à macOS d'évaluer l'application selon sa politique de sécurité actuelle. C'est un élément utile, mais cela ne signifie pas que l'application mérite l'accès à un identifiant de déploiement.

Une revue qui indique « le fichier de verrouillage est bien versionné » laisse trop de questions sans réponse. Conservez le fichier de verrouillage. Puis identifiez l'artefact qui lance réellement les actions sensibles.

La compatibilité du protocole n'établit pas la confiance dans le client

Un client peut parler correctement un protocole d'agent et rester inadapté à un accès sensible. La compatibilité du protocole indique si deux programmes peuvent échanger des messages. La confiance dans le client indique si ce programme précis, lancé dans cet état précis, peut demander une action utilisant un identifiant.

La documentation du Model Context Protocol décrit un échange de capacités déclarées entre un client et un serveur lors de l'initialisation. Cette négociation est utile pour l'interopérabilité. Elle n'atteste pas l'identité du binaire client, ne décrit pas les extensions chargées et ne garantit pas que le client préservera l'intention de l'utilisateur. Ne prenez pas une connexion établie pour une vérification d'identité.

Cette confusion apparaît lorsque des équipes autorisent n'importe quel client local compatible MCP à appeler un outil sensible parce que l'outil possède un nom de serveur connu. Le serveur MCP reçoit une requête par un canal de protocole. Il sait peut-être peu de choses sur le programme qui l'a construite. Un client malveillant ou simplement inconnu peut utiliser les mêmes noms de méthode qu'un client testé.

Conservez trois registres distincts :

1. La version du protocole et les capacités que vous avez testées.
2. L'artefact client, l'identité de signature, l'environnement d'exécution et les extensions que vous avez approuvés.
3. Les permissions de service que ce client peut demander.

Tout changement dans l'un de ces registres mérite une revue. Une mise à niveau du protocole peut modifier les valeurs par défaut ou le traitement des messages. Une mise à niveau du client peut changer les outils appelés ou le moment des nouvelles tentatives. Une modification des permissions de service peut rendre destructrice une nouvelle tentative auparavant inoffensive.

Il existe une autre distinction souvent mal comprise : l'épinglage d'un client n'épingle pas les instructions d'un agent. L'invite de l'utilisateur, les fichiers du dépôt, les descriptions des outils, le contenu distant et la sortie du modèle peuvent tous influencer un client épinglé. L'épinglage limite les surprises dues au remplacement du logiciel. Il ne rend pas sûrs les appels arbitraires aux outils. Placez une approbation humaine devant les actions dont les conséquences sont difficiles à annuler.

Testez le parcours des permissions, pas seulement la fenêtre de discussion

Un client candidat ne passe la revue qu'après avoir adopté le bon comportement sur tout le parcours d'accès que vous comptez autoriser. Lui demander de résumer un dépôt ou de créer un fichier temporaire prouve que l'interface fonctionne. Cela ne teste ni l'injection d'identifiants, ni le comportement des approbations, ni les nouvelles tentatives, ni les redirections, ni les vérifications des hôtes SSH, ni ce que fait le client après une erreur renvoyée par un outil.

Utilisez un service de préproduction ou un identifiant de test créé pour l'occasion, avec un périmètre limité. Cet identifiant doit pouvoir démontrer l'action sans pouvoir modifier les données de production, faire tourner des secrets partagés ou accéder à des comptes sans rapport. Si vous ne pouvez pas créer un tel identifiant, le service est trop large pour un client autonome et mérite une discussion spécifique sur sa conception d'accès.

Testez volontairement les cas suivants :

• Une requête ordinaire autorisée avec une réponse attendue.
• Une requête qui dépasse le périmètre de l'identifiant et reçoit un refus.
• Un délai de réponse ou une panne de connexion qui déclenche une nouvelle tentative.
• Une redirection ou un changement de point de terminaison, si le client utilise HTTP.
• Une connexion SSH avec une clé d'hôte modifiée, si le client utilise SSH.

Les deux derniers cas révèlent des comportements qui surprennent souvent. Les clients HTTP peuvent suivre les redirections, et une redirection peut envoyer une requête vers un autre hôte. La transmission des identifiants dépend du client et de l'implémentation de l'authentification. Vous devez l'observer, pas le déduire d'une note de version. Les clients SSH doivent traiter une différence de clé d'hôte comme une condition d'arrêt jusqu'à ce qu'une personne résolve le changement. Un agent ne doit pas pouvoir décider qu'une clé inconnue est acceptable simplement parce que la tâche lui demande de continuer.

Capturez les métadonnées des requêtes sans enregistrer les secrets. Pour HTTP, un point de terminaison de test peut journaliser la méthode, l'hôte, le chemin, le statut et certains en-têtes non secrets. Vérifiez quel en-tête d'autorisation la passerelle ajoute, puis confirmez que le client ne renvoie jamais sa valeur dans le résultat d'un outil, un message d'erreur ou une transcription locale.

Pour un point de terminaison destructeur, faites en sorte que l'opération de préproduction laisse une marque reconnaissable. Un test qui renvoie simplement HTTP 200 ne prouve pas grand-chose. Vous voulez démontrer qu'une seule action prévue s'est produite, que la mauvaise action n'a pas eu lieu après une nouvelle tentative et que le journal d'audit identifie la bonne session.

Isolez le candidat du client approuvé

Une version candidate doit avoir ses propres répertoires d'installation, de configuration, de cache et d'extensions. Le partage de ces répertoires donne à la version testée accès à un état qui peut différer d'une installation propre et rend le retour en arrière moins crédible. Les problèmes les plus pénibles que j'ai dû diagnostiquer venaient d'un « nouveau » client qui chargeait discrètement une ancienne extension ou réutilisait une session de navigateur authentifiée.

Sous macOS, des comptes utilisateur distincts offrent la limite la plus nette pour un test sérieux. Un compte séparé modifie le répertoire personnel, les répertoires de support des applications, les caches, les éléments d'ouverture de session et de nombreux magasins d'identifiants. Pour un test rapide de développeur, des répertoires séparés peuvent suffire si le client documente la manière de sélectionner chaque chemin et si vous vérifiez qu'il les respecte.

Ne dirigez pas les deux versions vers un même fichier de configuration accessible en écriture. Les clients mettent souvent à jour le format de configuration au démarrage. La nouvelle version peut écrire des champs que l'ancienne ignore ou gère mal. Le retour en arrière devient alors une migration partielle, précisément au moment où vous avez besoin d'un retour en arrière sans surprise.

Traitez les extensions avec la même méfiance que le client. Consignez leurs versions exactes, leurs sources, leurs condensats lorsque c'est possible et la capacité du client à télécharger automatiquement des mises à jour. Si le client découvre des extensions dans un répertoire étendu, comme un dossier de plugins au niveau de l'utilisateur, le test du candidat doit commencer avec ce répertoire vide. N'ajoutez que les extensions nécessaires au test.

Un test propre révèle aussi un problème moins prestigieux : les dépendances non documentées. Si le candidat ne fonctionne qu'après avoir hérité de variables d'environnement, de cookies de navigateur, de fonctions shell ou d'un cache global de paquets provenant de la configuration approuvée, consignez ces éléments. Chaque dépendance cachée rend le comportement ultérieur plus difficile à reproduire.

Faites de la promotion une petite modification de mise en production répétable

La promotion doit remplacer une fiche examinée par une autre, et non dépendre du souvenir de la personne qui a cliqué sur un bouton de téléchargement. Écrivez la même séquence à chaque fois. Elle donne aux personnes chargées de la revue un vocabulaire commun et fournit à l'ingénieur d'astreinte un retour arrière raisonnable.

1. Téléchargez le candidat depuis le canal de publication habituel de l'éditeur et consignez sa source, sa version exacte, son hachage et son signataire.
2. Installez-le dans l'emplacement de test isolé et consignez l'environnement d'exécution et les extensions qu'il charge.
3. Exécutez les tests du parcours des permissions avec des identifiants de préproduction, y compris les cas de refus et d'échec.
4. Comparez les requêtes, les demandes d'approbation et les journaux observés avec le comportement approuvé. Examinez toute nouvelle demande de privilège.
5. Installez le candidat approuvé dans l'emplacement privilégié, conservez l'ancien artefact et ne modifiez l'accès qu'après vérification de la conformité de l'installation avec le registre.

L'ordre final compte. N'accordez pas d'abord l'accès en prévoyant d'examiner le fichier installé plus tard. Si la vérification de l'installation échoue, le candidat doit rester incapable d'appeler des services sensibles. Le rejet d'une version est un résultat normal, pas l'échec du processus.

Utilisez une fiche simple qui peut être conservée avec vos notes opérationnelles. YAML convient, car elle reste lisible pendant un incident :

client:
  name: agent-client
  version: "2.4.1"
  executable_sha256: "replace-with-verified-digest"
  signer_team_id: "record-the-observed-team-id"
  install_path: "/Applications/Agent Client.app"
  runtime: "native bundle"
review:
  tested_on: "2025-03-08"
  reviewer: "initials"
  extensions: []
access:
  environments: ["staging", "production-read"]
  forbidden_actions: ["secret-rotation", "deployment-write"]
rollback:
  previous_version: "2.4.0"

Les valeurs ci-dessus sont des exemples, pas un modèle à recopier comme preuve. Remplacez-les par les résultats de votre propre inspection. En particulier, ne collez jamais un condensat provenant d'une annonce de version sans hacher le fichier que vous avez téléchargé.

Évitez les règles générales comme « toutes les versions de cet éditeur sont autorisées ». Elles sont populaires parce qu'elles réduisent le travail de revue. Elles suppriment aussi le contrôle précis que fournit l'épinglage. L'identité d'un éditeur peut être un élément de la revue, mais elle ne constitue pas une autorisation permanente permettant à un code inconnu d'utiliser vos identifiants de production.

Les mises à jour automatiques et l'accès sensible ne doivent pas partager la même limite

Les mises à jour automatiques sont raisonnables pour de nombreuses applications de bureau. Le risque change lorsque l'application peut provoquer des actions externes au moyen d'identifiants stockés, de clés SSH ou de comptes de service privilégiés. Dans cette situation, un programme de mise à jour peut modifier entre deux journées de travail le programme qui demande l'autorisation.

Trois modèles fonctionnent. Le plus sûr consiste à désactiver le remplacement automatique de l'installation privilégiée et à promouvoir manuellement les versions. Vous pouvez aussi laisser les développeurs utiliser des copies mises à jour automatiquement, sans accès sensible, tandis qu'une copie épinglée se charge du travail privilégié. Enfin, vous pouvez placer la limite d'action en dehors du client, afin que chaque nouveau processus doive recevoir une nouvelle autorisation avant de pouvoir effectuer quoi que ce soit d'important.

Le troisième modèle limite les dommages causés par une mise à jour inattendue, mais ne lui attribuez pas plus de garanties qu'il n'en offre. Une nouvelle carte d'approbation n'est utile que si elle identifie réellement le processus. Afficher un nom de client générique et cliquer chaque matin habitue les utilisateurs à approuver n'importe quoi. Affichez l'autorité de signature, le chemin du processus ou tout autre élément d'identité qu'une personne peut comparer au registre approuvé.

N'autorisez pas silencieusement un client mis à jour parce qu'il provient d'un magasin d'applications du système d'exploitation ou parce que macOS le considère comme signé. Ces mécanismes réduisent certains risques de la chaîne d'approvisionnement. Ils ne disent pas si le nouveau comportement respecte vos règles d'accès. C'est toujours à votre organisation de décider si elle accorde ses identifiants.

L'épinglage de version doit aussi prévoir une date d'expiration. Une épingle permanente devient une épingle non corrigée. Définissez une fréquence de revue selon le client, les services auxquels il peut accéder et les avis de sécurité de l'éditeur. La revue n'a pas besoin d'être dramatique lorsque le comportement n'a pas changé. Elle doit toutefois donner lieu à une décision explicite.

L'autorisation de chaque action détecte ce que l'épinglage ne peut pas détecter

Un client épinglé peut tout de même recevoir des instructions malveillantes par l'intermédiaire d'un dépôt, d'une description de problème, d'une page Web ou du résultat d'un outil. Il peut également prendre une mauvaise décision dans le cadre des permissions que vous lui avez accordées pour un travail légitime. L'autorisation humaine doit se concentrer sur les actions aux effets importants, comme l'écriture de données de production, la modification de l'infrastructure, le transfert de données vers une nouvelle destination ou l'ouverture d'une session SSH vers un hôte sensible.

Les demandes d'approbation échouent lorsqu'elles demandent aux utilisateurs d'approuver du bruit technique. Une demande affichée pour chaque lecture sans risque habitue les utilisateurs à cliquer. Une demande qui masque sa cible jusqu'à ce que la requête soit déjà partie n'aide pas beaucoup non plus. Affichez l'action, la destination, la méthode et l'identité de l'identifiant avant que la passerelle n'envoie la requête. Limitez le nombre de choix afin qu'une personne puisse réellement les évaluer.

Une séparation pratique consiste à laisser passer les lectures à faible risque après l'approbation d'une session et à exiger une approbation explicite pour les actions qui peuvent modifier l'état ou exposer des données. La limite dépend du service. Une lecture dans un dépôt source peut être ordinaire. Une lecture dans une base de données clients peut constituer une divulgation de données. Ne classez pas les actions selon le seul verbe HTTP.

Sallyport applique une échelle de décision fixe : le coffre refuse toute action tant qu'il est verrouillé, un nouveau processus d'agent exige par défaut l'autorisation de session et certaines entrées d'identifiants peuvent demander une approbation à chaque utilisation. Ce modèle étroit est volontaire. Un langage de politiques général offrirait davantage de réglages, mais aussi davantage de façons d'écrire par accident une exception que personne ne comprend.

Rendez la révocation immédiate. Lorsqu'un client candidat agit de manière inattendue, vous devez pouvoir arrêter sa session d'accès actuelle avant de commencer une longue enquête. Révoquer l'identifiant du service peut être nécessaire ensuite, mais c'est une réponse brutale qui peut interrompre un travail sans rapport. La révocation de session contient d'abord le processus en cours.

Les journaux d'audit doivent relier une action à l'exécution approuvée

Un journal d'action qui indique seulement « l'appel API a réussi » ne suffit pas pour le travail avec des agents. Vous devez relier l'appel au processus local, à la décision d'approbation, à l'identifiant utilisé et à la fiche du client en vigueur à ce moment-là. Sinon, l'examen d'un incident se réduira à une comparaison des horaires dans les terminaux, l'historique du navigateur et les journaux du service.

Conservez une fiche de session pour chaque processus d'agent. Elle doit indiquer quand le processus a démarré, comment l'utilisateur l'a autorisé, quelle identité a été observée et quand il s'est terminé ou a été révoqué. Conservez une fiche d'activité distincte pour chaque action. Elle doit identifier la destination, l'opération, le résultat et la session associée, sans contenir de secrets.

La preuve d'altération compte, car un agent peut produire un grand volume de travail en peu de temps et les journaux locaux sont faciles à modifier après une erreur. Une chaîne de hachage rend les suppressions ou modifications détectables lors de la vérification de la séquence. Elle n'empêche pas une machine compromise d'effectuer des actions. Elle donne aux enquêteurs une meilleure base pour détecter une histoire réécrite.

Sallyport projette ses journaux Sessions et Activity depuis un journal d'audit chiffré unique, chaîné par hachage, et sp audit verify peut vérifier la chaîne hors ligne sur le texte chiffré, sans clé de coffre. Cette conception est utile lorsque la personne qui examine la trace ne doit pas recevoir l'accès aux secrets utilisés pour les actions.

Testez votre parcours d'audit pendant la promotion. Approuvez une session de préproduction, effectuez une requête autorisée et une requête refusée, révoquez la session, puis vérifiez que les enregistrements identifient les quatre événements. Si vos journaux ne montrent pas la requête refusée ou la révocation, il leur manque des informations qui deviennent importantes précisément lorsque le comportement dérape.

L'épinglage échoue lorsque le reste du système reste modifiable

Même un client dont le condensat est soigneusement vérifié s'exécute sur une machine qui peut changer autour de lui. Le système d'exploitation, l'environnement d'exécution, le shell, la configuration DNS, les paramètres du proxy, les magasins de certificats, les binaires auxiliaires locaux et les extensions installées par les développeurs influencent tous la manière dont les requêtes quittent la machine. L'épinglage est un contrôle dans une chaîne, pas une étiquette à coller sur une configuration risquée.

Commencez par les éléments capables de modifier les actions privilégiées sans changer le condensat du client. Examinez les variables d'environnement qui sélectionnent les points de terminaison, le comportement du proxy ou l'emplacement des identifiants. Vérifiez quel binaire SSH ou quel assistant le client appelle. Consignez l'emplacement prévu du fichier known-hosts et confirmez que le test rejette une identité de serveur inconnue. Vérifiez si la configuration autorise l'exécution de commandes locales arbitraires comme outil.

Ne cherchez pas à résoudre chaque incertitude en construisant un moteur de politiques. La plupart des équipes ont besoin de moins d'éléments mobiles, pas d'un vaste ensemble de règles que personne ne peut expliquer à deux heures du matin. Une courte liste autorisée de destinations, des identifiants limités, des approbations explicites pour les appels sensibles et un artefact client connu couvrent davantage de risques qu'une collection complexe de conditions jamais testées.

L'habitude opérationnelle est simple : lorsqu'un client change, l'accès s'arrête jusqu'à ce que le nouvel artefact le mérite. Conservez l'ancienne copie approuvée, testez le remplacement sur le véritable parcours des permissions et consignez les preuves. Cette discipline est moins spectaculaire que les démonstrations d'agents autonomes. C'est aussi ainsi que vous empêchez une mise à jour en arrière-plan de devenir une modification de production non examinée.