# L’intégration d’un agent autonome doit commencer par un coffre verrouillé Les agents autonomes doivent gagner leur accès par étapes. Si vous commencez par remettre à un agent un jeton de production en lui demandant d’être « prudent », vous avez sauté la seule partie de la configuration qui vous apprend comment les contrôles se comportent sous pression. Le parcours du premier jour devrait commencer par un coffre qui refuse tout, passer par une action HTTP à faible risque, ajouter ensuite SSH, puis exiger une approbation à chaque utilisation pour les identifiants qui le méritent. Terminez en vérifiant la trace d’audit pendant que l’exécution est encore fraîche dans votre esprit. L’ordre compte, car chaque étape isole un type de défaillance différent. Le but n’est pas de rendre l’agent utile le plus vite possible. Il s’agit de savoir exactement ce qu’il peut faire, ce que vous devez approuver, ce qu’il enregistre et comment l’arrêter avant de le connecter à un travail qui peut avoir des conséquences. ## Commencez par un coffre qui refuse toute action Votre premier test réussi devrait être un refus. Un coffre verrouillé doit refuser une action de l’agent, même si sa demande est parfaitement raisonnable et même si l’identifiant est déjà configuré. Cela semble paradoxal jusqu’au jour où vous voyez un agent réessayer une action échouée. Les agents n’hésitent pas. Si un outil indique que l’accès est indisponible, l’agent peut essayer un autre point de terminaison, modifier un argument, appeler un outil associé ou demander une approbation. Vous voulez que la limite de sécurité réponde avant qu’un identifiant ne quitte son espace de stockage protégé. Sur un Mac, vérifiez que l’application fonctionne, mais laissez le coffre verrouillé. Lancez l’agent selon votre flux de développement habituel et donnez-lui une demande volontairement inoffensive, par exemple récupérer une ressource de test auprès d’une API que vous n’avez pas encore autorisée. Le résultat attendu est simple : la requête ne s’exécute pas. Ne contournez pas le refus en collant le jeton dans une variable d’environnement, un fichier de configuration du shell, une invite, un fichier de projet ou un fichier de configuration de l’agent. Ce contournement vous apprend la mauvaise leçon, car votre premier test devient alors un problème classique de gestion des secrets. Notez ce que l’agent a signalé. Vous vérifiez trois choses : - L’agent peut atteindre la passerelle d’action par sa connexion MCP. - La barrière du coffre arrête l’action lorsqu’il est verrouillé. - Aucun secret n’est apparu dans la transcription de l’agent, la sortie du terminal ou les arguments de l’outil. La différence entre un identifiant indisponible et un coffre verrouillé compte. Un identifiant indisponible indique généralement un problème de configuration. Un coffre verrouillé signifie que la configuration fonctionne et que l’accès est fermé volontairement. Si vous traitez les deux échecs comme « le jeton ne fonctionne pas », vous finirez par désactiver le contrôle qui vous protégeait. Sallyport en fait le premier contrôle de sa chaîne de décision : tant que le coffre est verrouillé, toute action est refusée. Sur le matériel Mac compatible, la barrière du coffre utilise Secure Enclave et Touch ID, au lieu de demander à l’agent de prouver quoi que ce soit sur lui-même. ## Connectez l’agent sans lui remettre de secret Un agent a besoin d’un chemin d’action, pas d’une copie d’un identifiant. C’est la règle qui empêche une automatisation utile de devenir un événement incontrôlé de distribution de secrets. Configurez l’agent compatible MCP pour utiliser le shim stdio intégré : ```sh sp mcp ``` Le shim est un serveur MCP standard. L’agent lui parle, demande l’exécution d’une action HTTP ou SSH et reçoit un résultat. L’identifiant reste dans le coffre chiffré de l’application. L’agent ne reçoit ni jeton en clair, ni jeton de remplacement, ni substitut ressemblant à un secret qu’il pourrait réutiliser plus tard. La limite est plus nette que celle que beaucoup d’équipes établissent. Elles disent souvent « l’agent a un accès limité », alors qu’elles veulent dire que l’agent possède dans son environnement un jeton aux permissions limitées. Ce sont deux systèmes différents. Avec une variable d’environnement, tout processus capable de lire l’environnement peut parfois copier le secret. Une entrée de l’historique du shell, un journal de débogage, un rapport de plantage, un processus enfant, une exportation d’invite ou une transcription de terminal collée peuvent prolonger sa durée de vie. Avec une passerelle d’action, l’agent peut demander une action précise, mais il ne peut pas inspecter le contenu de l’identifiant qui l’autorise. Avant de déverrouiller quoi que ce soit, inspectez la configuration de l’agent pour repérer les fuites habituelles : - Supprimez les jetons des fichiers `.env`, des fichiers de démarrage du shell, des instructions de l’agent et de la documentation du projet. - N’ajoutez pas un identifiant aux arguments d’un outil simplement parce que celui-ci accepte un champ `token`. - Évitez de donner à l’agent l’autorisation de lire le même gestionnaire de mots de passe, fichier de secrets ou dossier d’identifiants cloud que vous cherchez à protéger. - Gardez la première exécution de l’agent séparée de toute session de terminal qui contient des variables d’environnement privilégiées. C’est aussi à ce moment que les développeurs formulent une recommandation populaire, mais mauvaise : « Utilisez d’abord un jeton temporaire, puis renforcez la sécurité plus tard. » Un jeton temporaire reste un secret dès qu’il entre dans le contexte de l’agent. Utilisez une identité temporaire pour limiter l’impact, oui. N’en faites pas une raison pour abandonner la séparation entre l’agent et le secret. ## Faites une requête HTTP simple avant toute autre chose Votre première action autorisée devrait être une requête HTTP avec un identifiant dont la fonction est étroite. La lecture seule est préférable. Un compte de test est encore mieux. Un point de terminaison qui renvoie un objet connu et non sensible est idéal. Choisissez une requête que vous pouvez vérifier séparément. Vous pouvez par exemple lire les métadonnées d’un dépôt de test, récupérer un profil de bac à sable que vous avez créé ou appeler un point de terminaison d’état lié à un compte sans lien avec la production. Évitez les points de terminaison qui listent de vrais clients, du code source, des données de facturation ou des paramètres de compte étendus. Une lecture réussie peut tout de même divulguer plus que prévu. Configurez l’identifiant HTTP dans le coffre avec la forme d’authentification attendue par le service : authentification bearer, basic ou en-tête personnalisé. Choisissez un libellé assez clair pour le reconnaître plus tard sur une carte d’approbation. « Lecture API de test » vaut mieux que « jeton 2 ». Votre futur vous ne devrait pas avoir à ouvrir un gestionnaire de mots de passe pour savoir si un clic est sans danger. Déverrouillez maintenant le coffre et lancez un processus d’agent vierge. L’autorisation par session est activée par défaut. La première action de ce nouveau processus devrait donc afficher une carte d’approbation. Lisez l’autorité de signature du code qui y figure avant d’approuver. Ne réduisez pas cette vérification à « je reconnais le nom de l’agent ». Un nom de commande familier peut être lancé par un wrapper inattendu, un binaire copié ou un autre outil de développement. La carte d’approbation met en avant l’autorité de signature du code du processus, car le processus qui demande l’accès compte davantage que la tâche en langage naturel qu’il prétend effectuer. N’approuvez l’exécution que si toutes ces conditions sont réunies : 1. Vous avez lancé vous-même le processus de l’agent. 2. L’identité de signature correspond à ce que vous attendiez pour ce processus. 3. L’identifiant demandé a la portée étroite que vous aviez prévue. 4. La requête correspond à celle que vous avez demandé à l’agent d’effectuer. Demandez ensuite à l’agent de faire exactement un appel. Comparez le résultat renvoyé avec une requête manuelle effectuée en dehors du flux de l’agent. Vous ne cherchez pas à prouver que HTTP fonctionne. Vous vérifiez que l’agent peut demander une action, que la passerelle peut injecter l’identifiant stocké et que le résultat peut revenir sans exposer l’identifiant lui-même. Un relevé utile pour le premier jour reste court : ```text Identifiant : Lecture API de test Tâche de l’agent : Récupérer un objet de test connu Résultat attendu : Identifiant et état de l’objet uniquement Comparaison manuelle : Même identifiant et même état Données inattendues renvoyées : Aucune ``` Si la réponse contient plus de champs que prévu, arrêtez-vous là. Ne demandez pas à l’agent de résumer les données supplémentaires pour continuer. Réduisez la portée de l’API, utilisez un objet de test plus petit ou choisissez un point de terminaison plus précis. Le premier appel HTTP doit inspirer confiance par sa maîtrise, pas par l’importance du résultat. ## L’approbation de session autorise une exécution, pas un blanc-seing L’autorisation par session répond à une question précise : approuvez-vous ce processus d’agent pendant toute la durée de cette exécution ? Elle ne dit pas si chaque identifiant ou chaque action demandée mérite le même traitement. Après l’approbation d’une exécution, l’agent peut effectuer plusieurs appels avant de se terminer. C’est utile lorsque vous supervisez une tâche cohérente, comme lire des métadonnées de test et produire un rapport local. C’est risqué si l’invite est ouverte, si l’exécution peut lancer un travail connexe ou si elle a accès à des identifiants dont les conséquences diffèrent. Traitez une session comme une unité de travail limitée. Lancez-la pour une seule tâche. Observez les premiers appels. Terminez-la lorsque la tâche est finie. Lancez un nouveau processus pour la tâche distincte suivante afin d’obtenir une nouvelle décision d’autorisation. Le journal Sessions doit faciliter cette habitude. Il enregistre les exécutions d’agents et vous pouvez révoquer une exécution instantanément. Utilisez la révocation lorsque l’agent commence à dévier, lorsque vous réalisez que vous avez approuvé le mauvais processus ou lorsque la tâche change de nature en cours de route. Voici un scénario d’échec qu’il faut savoir reconnaître. Vous demandez à un agent de « vérifier l’API de test et de corriger les problèmes évidents ». Il commence par une requête GET inoffensive. Vous approuvez la session. Il trouve une incohérence de configuration, voit un point de terminaison d’écriture parmi les actions disponibles et décide que la correction évidente consiste à modifier le paramètre. L’identifiant peut l’y autoriser et l’approbation initiale peut toujours couvrir l’exécution. Rien dans cette histoire n’exige un agent malveillant ou un outil défectueux. Le problème vient de la limite de la tâche. Vous avez confié à une seule session une phase de découverte et une phase de correction, puis vous avez attendu de votre approbation initiale qu’elle conserve le même sens pendant les deux. Séparez le travail. Approuvez une session de découverte en lecture seule. Examinez ses résultats. Lancez ensuite une exécution distincte pour une modification proposée, de préférence avec un autre identifiant aux permissions d’écriture plus étroites. L’approbation devient utile lorsqu’elle suit une unité de travail que vous pouvez décrire en une phrase. ## N’ajoutez SSH qu’une fois la limite HTTP devenue ordinaire SSH n’est pas « HTTP, mais pour les serveurs ». Il entraîne davantage de conséquences, car une connexion réussie peut exécuter des commandes arbitraires, inspecter des fichiers, modifier des permissions et déplacer des données par des canaux qu’une API limitée n’expose jamais. Commencez par un hôte jetable ou une machine de développement isolée. Créez un compte distant sans accès à la production, sans identifiants partagés et sans raison d’accéder à votre dossier personnel ou à votre configuration cloud. Placez sur cet hôte un fichier inoffensif contenant une ligne connue. La première tâche SSH de l’agent devrait consister à récupérer cette ligne, et rien d’autre. Sallyport fait passer les actions SSH par son assistant Go sans état intégré, `sp-ssh`. L’agent demande l’action selon le même modèle de passerelle, tandis que l’identifiant SSH stocké reste dans le coffre au lieu de devenir un fichier de clé privée lisible par l’agent. Le premier exercice SSH doit rester volontairement étroit : ```text Hôte : hôte de développement isolé Compte distant : compte de test restreint Tâche autorisée : Lire un fichier texte connu Réponse attendue : La ligne exacte placée dans ce fichier Condition d’arrêt : Toute tentative d’inspecter d’autres chemins ou d’exécuter une deuxième commande ``` Ne commencez pas par « exécuter des diagnostics ». Cette formule est trop large. Les diagnostics incluent souvent les listes de processus, la configuration réseau, l’inventaire des paquets, les fichiers journaux, les dossiers personnels et la configuration des applications. Un agent capable interprétera la demande largement, car cette interprétation est souvent ce qui lui permet de terminer une tâche. Surveillez une erreur opérationnelle fréquente : les développeurs testent SSH avec un compte pratique plutôt qu’avec un compte sûr. Ce compte a accès à un hôte familier, parfois grâce à une clé personnelle déjà existante, ce qui rend le test rapide. L’agent découvre alors dès sa première expérience SSH des dépôts, des identifiants de déploiement, l’historique du shell, des fichiers de configuration et tout ce que ce compte peut lire. Vous avez appris que le tunnel fonctionne, mais vous n’avez rien appris d’utile sur le confinement. Un compte de test restreint rend l’échec lisible. Si l’agent demande un chemin inattendu, vous pouvez voir l’action tentée dans le journal, puis refuser ou révoquer sans vous demander s’il a déjà trouvé un fichier plus sensible. ## L’approbation à chaque utilisation concerne les identifiants aux conséquences réelles L’approbation à chaque utilisation vous demande de confirmer chaque emploi d’un identifiant. Activez cette option avant d’essayer un identifiant qui peut modifier un système, accéder à des données sensibles ou atteindre un hôte où une seule commande shell peut avoir un effet étendu. Les développeurs y résistent souvent parce que les demandes répétées semblent inefficaces. Ils ont raison sur le coût. Une demande pour chaque lecture à faible risque vous habituera à cliquer sans les lire. C’est la fatigue d’approbation, et elle rend le contrôle pire que son absence, car elle crée une fausse impression de sécurité. Utilisez ce réglage lorsque chaque action nécessite une nouvelle décision humaine. Les bons candidats sont les identifiants qui peuvent : - créer, modifier ou supprimer des ressources distantes ; - lire des données personnelles, clients, financières ou sensibles pour la sécurité ; - appeler des méthodes d’API administratives ; - ouvrir un accès SSH à une machine de développement partagée, de préproduction ou proche de la production ; - déclencher un déploiement, une tâche, un workflow ou une notification externe. Laissez les lectures de test à faible risque sous approbation de session pendant que vous apprenez le fonctionnement. Placez une barrière à chaque utilisation sur le prochain identifiant que vous ajoutez et qui a une conséquence réelle. Donnez ensuite à l’agent une tâche nécessitant deux appels distincts, comme lire un paramètre de test et proposer, sans l’appliquer, une modification. Vérifiez que chaque utilisation exige bien votre approbation lorsque l’identifiant est configuré ainsi. La distinction est importante. L’approbation par session demande si un processus précis peut agir pendant cette exécution. L’approbation à chaque utilisation demande si cet identifiant précis peut être utilisé maintenant. La première concerne l’identité du processus et la durée de l’exécution. La seconde concerne la conséquence attachée à un secret stocké. Les confondre conduit soit à approuver trop largement, soit à afficher tant de demandes que personne ne lit la carte. Lorsque la demande apparaît, inspectez plus que le libellé de l’identifiant. Vérifiez l’action, la destination et la pertinence de l’appel par rapport à la tâche actuelle de l’agent. Si l’appel ne se justifie pas, refusez-le et demandez à l’agent d’expliquer son plan en termes simples avant toute nouvelle approbation. ## Le journal d’activité transforme les surprises en preuves Un enregistrement de session vous indique quelle exécution d’agent a reçu une approbation. Un enregistrement d’activité vous indique ce qui s’est passé au cours de cette exécution. Il vous faut les deux, car un processus apparemment normal peut tout de même prendre une mauvaise décision, et un appel suspect ne signifie pas grand-chose si vous ne pouvez pas le relier à l’exécution qui l’a déclenché. Après le test HTTP, ouvrez le journal Activity et lisez chaque appel individuel. Faites de même après le test SSH. Comparez l’enregistrement avec votre exercice écrit : le point de terminaison ou l’hôte attendu, l’action attendue et le résultat attendu. Vous vous entraînez à repérer une divergence alors qu’elle est encore facile à expliquer. Portez une attention particulière aux appels qui semblent inoffensifs isolément, mais qui ne correspondent pas à la tâche. Un point de terminaison de métadonnées peut révéler la structure d’un compte. Une sonde d’hôte peut mener à une commande plus large. Une nouvelle tentative peut être inoffensive ou indiquer que l’agent a modifié ses paramètres après l’échec de la première réponse. Le contexte vient de la session et de la séquence, pas d’une seule ligne considérée séparément. Ne prenez pas le récit de l’agent pour votre enregistrement. Les agents peuvent résumer correctement, omettre un détail, mal comprendre une réponse d’outil ou produire une explication soignée pour une action que vous n’auriez pas approuvée. Le journal sert à vérifier ce qui s’est passé, pas à évaluer la qualité du texte qui l’entoure. C’est également à ce moment que la révocation instantanée prend tout son sens. Si vous voyez l’agent passer de la tâche convenue à l’exploration, révoquez d’abord la session. Vous pourrez déterminer ensuite si l’appel était inoffensif, après avoir empêché toute action supplémentaire. Attendre une explication complète est raisonnable en réunion, mais c’est une mauvaise réponse face à un processus actif qui dispose d’identifiants. ## Vérifiez la chaîne d’audit avant d’en avoir besoin Une trace d’audit n’est utile que si vous pouvez détecter une falsification de la trace elle-même. Lire une liste d’événements vous indique ce que l’interface affiche actuellement. La vérification vous indique si la chaîne de hachage du journal d’audit chiffré est toujours valide. Exécutez cette commande après les deux premiers exercices : ```sh sp audit verify ``` Sallyport peut vérifier hors ligne la chaîne de hachage sur le texte chiffré. Cette vérification ne nécessite donc pas l’accès au secret du coffre. Cette propriété est pratique pendant une enquête. Vous pouvez contrôler l’intégrité de la trace sans déverrouiller d’abord le même espace de stockage qui contrôle les actions de l’agent. Exécutez la commande une fois dans une période calme. Notez où conserver le résultat pour une modification, un test ou un incident. Répétez-la ensuite après une action refusée volontairement, un appel HTTP approuvé et un appel SSH approuvé. Vous vérifiez ainsi une séquence d’événements connus, ce qui rend plus facile la détection d’un résultat inattendu lors d’une vérification ultérieure. N’attendez pas une question sérieuse concernant la production pour découvrir qui peut exécuter la commande, où se trouvent les journaux ou si votre équipe connaît la différence entre un enregistrement de session et un appel individuel. C’est l’échec habituel. Les équipes installent la journalisation, supposent qu’elle existe et ne l’ouvrent qu’après la question « Qui a approuvé cela ? ». Elles doivent alors apprendre l’outil et reconstituer l’événement en même temps. Le journal d’audit est projeté dans les journaux Sessions et Activity à partir d’un enregistrement chiffré, chaîné par hachage et insensible à l’écriture. Vous disposez ainsi de deux vues opérationnelles sans faire de ces vues les seules preuves consultables. ## Rendez la première semaine plus exigeante que la première démonstration Une démonstration réussie s’arrête lorsque la requête HTTP aboutit. Un parcours d’intégration utilisable continue jusqu’à ce que vous ayez refusé une action, approuvé une exécution limitée, révoqué volontairement une exécution, inspecté les appels individuels, testé SSH sur un hôte isolé, utilisé l’approbation à chaque utilisation et vérifié la chaîne d’audit. Pendant la première semaine, restez à une échelle qui vous permet d’expliquer chaque action. N’ajoutez qu’un seul identifiant ou une seule capacité à la fois. Si une nouvelle configuration nécessite plusieurs exceptions, des portées étendues et une demande que vous ne pouvez pas interpréter rapidement, elle n’est pas prête pour un agent autonome. Le test pratique est direct : lorsque l’agent demande à agir, pouvez-vous dire qui demande, quel identifiant stocké serait utilisé, quel système externe recevrait l’action et où vous regarderiez ensuite ? Si l’une des réponses reste vague, revenez à l’étape précédente et réduisez la portée du test. C’est plus lent que de copier un jeton dans un fichier de configuration. C’est aussi ainsi que vous évitez de découvrir à deux heures du matin que votre première véritable exécution d’agent a été le moment où vos contrôles d’identifiants ont cessé d’être des contrôles.