HTTP ou SSH pour les agents IA : limiter le rayon d'action

Un agent IA doit utiliser HTTP lorsqu'un service peut exprimer l'action souhaitée comme une opération authentifiée et ciblée. Il ne doit utiliser SSH que si la tâche nécessite une capacité au niveau de la machine qu'une API ne peut pas fournir, et uniquement avec un compte et une interface de commandes conçus pour cette tâche précise.

L'erreur habituelle consiste à comparer les deux moyens de transport comme si l'un était moderne et l'autre ancien. Ce n'est pas le bon critère. HTTP et SSH sont des mécanismes d'acheminement. C'est l'autorité qu'on leur associe, les entrées qu'on accepte et les preuves qu'on conserve qui déterminent si un agent peut effectuer une modification limitée ou parcourir un hôte de production avec les privilèges d'un administrateur.

J'ai vu des équipes créer une clé SSH prétendument temporaire parce qu'un agent avait besoin d'une seule information opérationnelle. Un mois plus tard, la clé pouvait lire des secrets de déploiement, accéder à des services internes et ouvrir un shell interactif. Personne n'avait pris une décision de sécurité spectaculaire. L'équipe avait simplement accepté le réglage par défaut, plus pratique. C'est exactement ainsi qu'une petite tâche acquiert un grand rayon d'action.

L'interface détermine l'autorité reçue par l'agent

HTTP ou SSH pour les agents IA est une question de forme des capacités, pas de préférence de protocole. Un appel HTTP peut être large et dangereux, tandis qu'une connexion SSH peut être strictement limitée. En pratique, les API offrent plus souvent un point de contrôle utile, car un point d'accès, une méthode, un schéma de requête et les permissions d'un jeton peuvent décrire une seule opération.

Prenons l'instruction suivante : redémarrer un worker défaillant. Un point d'accès HTTP comme POST /workers/worker-17/restart indique la cible et le verbe autorisé. Le service peut refuser un worker inconnu, exiger un rôle autorisant les redémarrages et écrire un enregistrement associé au jeton. Une commande shell comme ssh host sudo systemctl restart worker implique une autorité plus large. Elle dépend du compte, de la configuration de sudo, des règles de nommage des unités, de l'analyse du shell et de l'état de l'hôte.

Cela ne rend pas automatiquement l'API sûre. Un jeton capable d'appeler tous les points d'accès, de créer d'autres jetons ou d'exporter tous les enregistrements dissimule un vaste rayon d'action derrière une URL bien rangée. De même, une commande SSH forcée qui accepte un identifiant de worker fixe provenant d'une liste autorisée peut être plus limitée qu'une API administrative mal conçue.

Avant de connecter l'un ou l'autre outil, faites ce test : décrivez en une phrase l'action réussie la plus limitée, puis énumérez tout ce que le même identifiant peut encore faire si l'agent produit une entrée inattendue. Si vous ne pouvez pas expliquer la seconde partie, vous n'avez pas encore mesuré l'autorité accordée.

Une interface ciblée possède quatre propriétés :

• Elle nomme un petit ensemble de cibles plutôt qu'un environnement entier.
• Elle accepte des entrées structurées selon une grammaire validable.
• Elle refuse les actions voisines dont la tâche actuelle n'a pas besoin.
• Elle crée un enregistrement qui permettra à une autre personne d'expliquer le résultat plus tard.

La tâche doit aussi déterminer la durée de vie de l'identifiant. Un identifiant utilisé pour une seule exécution ne doit pas devenir silencieusement un accès permanent parce que personne n'a pensé à le supprimer. La durée du processus constitue une limite plus fiable qu'un rappel dans un calendrier.

HTTP ne fournit des limites utiles que si l'API les applique

HTTP réduit le rayon d'action d'un agent lorsque le service vérifie l'autorisation au niveau de la ressource et de l'opération. Un jeton bearer n'est qu'un moyen de transport. Sa sécurité dépend de ce que le serveur vérifie après l'avoir reçu.

RFC 9110 décrit les méthodes HTTP par leur sémantique, notamment la distinction entre méthodes sûres et méthodes idempotentes. Cette terminologie aide à gérer les relances et l'intention, mais elle n'accorde aucune permission. Un GET peut divulguer des informations sensibles. Un PUT peut être idempotent tout en écrasant un réglage de production. Considérez les noms de méthodes comme des indications sur le comportement du client, pas comme un modèle d'autorisation.

Posez les questions suivantes au responsable du service avant de remettre un jeton à un agent :

• Quels chemins et quelles méthodes précis ce jeton peut-il appeler ?
• Le service vérifie-t-il l'accès pour chaque ressource, ou seulement pour l'ensemble général ?
• Le jeton peut-il créer des identifiants, modifier des permissions ou déclencher des exports ?
• Une requête peut-elle atteindre un autre locataire, projet ou environnement via un identifiant ?
• Le service enregistre-t-il l'identité de l'identifiant et le résultat de la requête ?

La question délicate est de savoir si une permission de lecture divulgue plus que nécessaire. Une API de dépôt peut permettre à un jeton de lecture de récupérer le code source, les commentaires de pull request, les journaux de compilation et la configuration. Une seule valeur de configuration mal stockée peut rendre l'accès en lecture équivalent à un accès aux secrets. Si l'agent a seulement besoin de l'état d'un déploiement, donnez-lui un point d'accès qui renvoie cet état. Ne lui remettez pas un jeton général de dépôt en appelant cela le principe du moindre privilège.

Le schéma de requête compte autant que la portée. Comparez ces deux requêtes :

POST /v1/releases/release-42/promote HTTP/1.1
Authorization: Bearer token-value
Content-Type: application/json

{"environment":"staging"}

POST /v1/admin/execute HTTP/1.1
Authorization: Bearer token-value
Content-Type: application/json

{"operation":"promote","arguments":{"environment":"staging"}}

Les deux peuvent promouvoir une version. La première laisse au serveur peu de place pour interpréter l'opération. La seconde crée un répartiteur administratif. Ces répartiteurs attirent les exceptions, puis des noms d'opérations arbitraires, puis un jeton dont l'autorité réelle devient difficile à décrire. Je les évite pour les agents, sauf si le serveur applique une liste stricte d'opérations autorisées et valide séparément le schéma des arguments de chaque opération.

Utilisez des identifiants distincts pour des verbes distincts lorsque le service le permet. Séparez l'observation de la modification, puis les modifications courantes des changements d'identité ou de facturation. La configuration demande davantage de travail, mais les refus d'autorisation deviennent alors significatifs. Un refus indique que la définition de la tâche et l'identifiant ne correspondent pas. Avec un jeton trop large, chaque erreur produit une requête réussie qu'il faut examiner après coup.

Ne placez pas un secret d'API permanent dans une instruction destinée à l'agent, un fichier d'environnement, un réglage de dépôt ou une configuration d'outil. Le problème ne se limite pas à une divulgation accidentelle dans la sortie. Les agents inspectent leur environnement, les outils collectent des diagnostics et un processus qui dispose d'un accès en clair peut transmettre ce secret à une autre destination. Gardez le secret hors du processus de l'agent et autorisez plutôt l'action qui en résulte.

SSH expose l'hôte si vous ne supprimez pas volontairement le shell

SSH possède un large rayon d'action par défaut, car un compte interactif peut inspecter des fichiers, exécuter des programmes, modifier la configuration, ouvrir des tunnels et utiliser tous les chemins réseau disponibles pour ce compte. Le fait de vouloir exécuter une seule commande ne restreint pas un compte qui reçoit un shell normal.

RFC 4251 décrit SSH comme un protocole de connexion distante sécurisée et d'autres services réseau sécurisés. Il prend volontairement en charge les sessions, les canaux, la redirection de ports et plusieurs méthodes d'authentification. Ces capacités sont utiles aux administrateurs. Elles constituent un mauvais point de départ pour un acteur autonome qui n'a besoin que d'une opération de maintenance limitée.

La commande elle-même compte également. systemctl restart service-name semble limitée jusqu'à ce qu'on examine l'autorité environnante : quelles unités le compte peut redémarrer, si les fichiers d'unité peuvent exécuter des actions privilégiées, si le compte peut modifier ces fichiers et si les noms de services proviennent d'une entrée validée. Une commande qui paraît opérationnelle peut atteindre des identifiants de déploiement, des volumes montés ou un plan de contrôle interne par l'intermédiaire du service qu'elle redémarre.

Si SSH est nécessaire, créez un petit programme distant avec une grammaire d'entrée fermée. Le programme doit associer des champs de requête connus à des opérations connues. Il ne doit pas concaténer une requête dans une commande shell. Évitez d'accepter des chemins de fichiers, noms d'hôtes, expressions régulières, fragments de shell ou affectations d'environnement, sauf si le programme valide chacun d'eux avec une liste d'autorisation stricte.

Une entrée authorized_keys restreinte permet de rendre cette limite visible. Le modèle suivant force l'utilisation d'un seul programme récepteur et supprime plusieurs fonctionnalités SSH dont les agents ont rarement besoin :

command="/usr/local/libexec/agent-maintenance",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexample agent-runner

Cette ligne ne suffit pas à régler l'autorisation. Le programme agent-maintenance doit refuser les sous-commandes inconnues et valider ses arguments. Le compte système doit disposer uniquement des permissions sur les fichiers, services et réseaux nécessaires à ce programme. Si le programme appelle sudo, sa règle sudo doit désigner un exécutable fixe et ne doit pas autoriser d'éditeur, d'interpréteur, de caractère générique ou de sortie vers un shell.

Le manuel d'OpenSSH consacré à authorized_keys documente command=, no-pty et les restrictions de redirection. Considérez ces options comme une ceinture de sécurité, pas comme le véhicule. Elles suppriment plusieurs échappatoires faciles, mais une commande forcée exécutée par un compte trop privilégié conserve un accès trop large.

Un protocole d'entrée distant utile peut utiliser un JSON simple sur l'entrée standard :

{"action":"restart_worker","worker":"worker-17","request_id":"8b4f3c2a"}

Le récepteur ne doit accepter que restart_worker et des noms de workers présents dans son propre inventaire. Il doit écrire un événement avant l'exécution, appeler un programme fixe sans shell, capturer le code de sortie et écrire un événement de fin. Si l'agent envoie worker-17; cat /etc/shadow, la validation doit refuser la valeur complète avant toute exécution de commande par le système.

Ne donnez pas à un agent un accès SSH simplement parce qu'une personne utilise déjà SSH pour la même tâche. Les humains peuvent reconnaître une invite inhabituelle, remarquer un nom d'hôte différent et s'arrêter après un résultat surprenant. Les agents ont besoin que la restriction soit intégrée à l'interface.

Les journaux doivent expliquer l'action tentée et l'état obtenu

Une ligne de journal disant « la requête a échoué » n'est pas un enregistrement d'audit. Elle peut suffire pour déboguer une bibliothèque cliente, mais elle ne permet pas de déterminer si un agent a modifié quelque chose, si une personne l'a approuvé ou ce qu'il faut examiner après un incident.

Pour HTTP, enregistrez l'identité de l'exécution de l'agent, l'identité ou le libellé de l'identifiant, l'hôte de destination, la méthode, le chemin normalisé, une représentation sûre du corps de la requête, le statut de la réponse, la valeur de corrélation de la requête, l'heure de début et le résultat final. Masquez les secrets et les champs sensibles avant que l'événement ne quitte la limite d'action. Enregistrer l'en-tête Authorization pour préserver les preuves provoquerait une fuite de données par vous-même.

Pour SSH, enregistrez l'identité de l'hôte, le compte distant, le nom de la commande forcée, les arguments validés, l'identité du processus source, le code de sortie, la classification de la sortie d'erreur et l'identifiant de l'opération distante. Une chaîne de commande brute constitue une preuve faible, car elle peut dissimuler le comportement des guillemets et ne montre pas quels arguments le récepteur a acceptés.

La séquence d'événements doit distinguer l'intention de l'effet. Cette structure fonctionne pour les deux moyens de transport :

{"event":"authorization_granted","run":"r-204","action":"restart_worker","target":"worker-17"}
{"event":"action_started","run":"r-204","transport":"ssh","operation":"restart_worker","request_id":"8b4f3c2a"}
{"event":"action_finished","run":"r-204","outcome":"success","remote_status":0,"request_id":"8b4f3c2a"}

Si la connexion se coupe après action_started, écrivez outcome:"unknown" plutôt que d'inventer un échec. Ce mot impose l'étape suivante : interroger l'état distant avant toute nouvelle tentative. Il rend aussi l'enquête ultérieure plus honnête.

Les journaux ordinaires posent également un problème de conservation. Un administrateur de l'hôte ou un processus qui obtient suffisamment d'accès peut les tronquer, les réécrire ou les supprimer. La collecte centralisée aide, mais elle peut toujours laisser des lacunes lorsque le collecteur ou le réseau tombe en panne. Si le journal doit régler un désaccord sur les actions d'un agent, conservez des enregistrements append-only avec des contrôles d'intégrité et vérifiez-les en dehors du chemin d'action.

Une chaîne de hachage rend les modifications détectables lorsque chaque événement intègre l'empreinte de l'événement précédent. Elle ne prouve pas que l'enregistreur a vu tous les événements et ne rend pas fiable une horloge qui ne l'est pas. Ces limites comptent. La chaîne répond à une question plus étroite, mais utile : quelqu'un a-t-il modifié cette séquence conservée après coup ?

Sallyport conserve un journal Sessions pour les exécutions d'agents et un journal Activity pour les appels individuels, tous deux produits à partir d'un journal d'audit chiffré et chaîné par hachage. Sa commande sp audit verify vérifie cette chaîne hors ligne sur le texte chiffré. C'est la bonne propriété lorsqu'il faut examiner des preuves sans exposer d'abord les secrets.

Les délais d'attente produisent des résultats inconnus, pas des actions échouées

Les défaillances réseau sont à l'origine des doublons que provoquent des équipes pourtant prudentes. Un client envoie une requête, le serveur distant exécute l'opération, puis la réponse disparaît. L'agent constate un délai d'attente et relance l'action. Avec SSH, la même séquence peut se produire après le démarrage de la commande distante, mais avant la réception de son code de sortie par le client.

Ne laissez pas un agent interpréter une erreur de transport comme une permission de relancer une modification. Commencez par classer l'opération.

Une opération est idempotente uniquement lorsque répéter la même requête produit le même état souhaité sans effet supplémentaire. Définir l'état souhaité d'un worker nommé sur running peut répondre à cette définition. Créer un paiement, ajouter un enregistrement, renouveler un secret ou redémarrer un processus n'y répondent souvent pas. Un redémarrage peut interrompre une séquence de récupération que la première tentative avait déjà déclenchée.

Utilisez un identifiant d'idempotence lorsque l'API le prend en charge. Le service doit conserver cet identifiant avec l'effet terminé et renvoyer le résultat précédent en cas de doublon. Un identifiant fourni par le client que le serveur se contente d'enregistrer n'empêche pas les doublons.

Pour les commandes distantes, ajoutez une opération d'état capable de répondre à une question précise. Après une réponse en échec à restart_worker, interrogez la génération actuelle du worker, l'identifiant de sa dernière demande de redémarrage et son état de santé. Si le récepteur stocke l'identifiant de la demande avant l'exécution et le renvoie avec l'état, il peut indiquer à un agent qui réessaie si la demande a déjà été exécutée.

Cette séquence montre pourquoi c'est important :

1. L'agent demande le redémarrage de worker-17 avec l'identifiant 8b4f3c2a.
2. Le récepteur enregistre l'identifiant et redémarre le worker.
3. La connexion SSH tombe pendant l'arrêt du worker.
4. L'agent demande l'état au lieu de redémarrer une nouvelle fois.
5. La réponse indique que le même identifiant est en cours de traitement, alors l'agent attend et vérifie l'état de santé.

Une limite du nombre de tentatives ne règle pas les résultats ambigus. Elle réduit les dégâts après une mauvaise décision de relance. L'observation de l'état permet de prendre la bonne décision.

HTTP comporte un autre piège : les services renvoient parfois un statut de réussite avant la fin du traitement asynchrone. 202 Accepted signifie que le serveur a accepté le travail pour un traitement ultérieur, pas que l'état demandé existe déjà. Exigez une ressource d'opération ou un point d'accès d'état, puis faites attendre l'agent jusqu'au résultat final pertinent pour la tâche.

SSH présente un piège équivalent lorsqu'une commande lance un processus en arrière-plan et se termine avec le code zéro. Ne considérez pas le code zéro d'un lanceur comme la preuve que l'action de maintenance est terminée. Faites attendre le récepteur jusqu'à la fin ou renvoyez un identifiant d'opération durable que l'agent pourra interroger.

Une commande shell dissimule plus d'autorité que son texte n'en révèle

La commande distante la plus courte possède souvent l'autorité cachée la plus large. L'expansion du shell, l'héritage de l'environnement, les répertoires courants, les fichiers de configuration et les chemins de recherche des exécutables influencent tous ce qui s'exécute. Un agent peut produire un texte apparemment inoffensif qui déclenche un résultat surprenant parce que l'hôte l'interprète dans son contexte.

Évitez ce modèle :

ssh ops@host "deploy $branch $environment"

Même si l'appelant protège correctement les variables aujourd'hui, le shell distant analyse un langage de commandes. Le script de déploiement peut effectuer ses propres expansions. Un nom de branche peut choisir un emplacement source. Un nom d'environnement peut sélectionner des identifiants ou un cluster cible. Vous devez examiner chaque niveau avant de pouvoir affirmer que l'entrée est limitée.

Utilisez un récepteur qui lit une entrée structurée et appelle directement un exécutable fixe. Dans la plupart des langages, cela signifie un tableau d'arguments, et non une chaîne transmise à sh -c. Le récepteur doit gérer la correspondance entre un nom de cible compréhensible par l'utilisateur et un identifiant propre à l'hôte. Ne demandez pas à l'agent de découvrir les chemins du système de fichiers ou les noms d'unités de service.

La même préoccupation s'applique aux paramètres HTTP. Un chemin comme /files?path=... peut sembler structuré alors que le serveur transmet la valeur à une opération sur le système de fichiers. Une API ne réduit le risque que si le serveur valide la signification de l'entrée, pas lorsqu'elle déplace l'analyse des commandes derrière une URL.

L'emplacement des identifiants modifie les conséquences d'une compromission du processus de l'agent. Si un agent stocke localement une clé privée SSH ou un jeton d'API, tout processus capable de lire ces éléments peut agir plus tard sans l'agent. Une limite d'action distincte peut conserver le secret et transmettre au service distant uniquement une requête et une décision d'autorisation. La différence est nette : cacher un secret à la sortie du modèle ne revient pas à garder ce secret hors du processus de l'agent.

Sallyport adopte cette dernière approche pour les identifiants HTTP et les clés SSH : l'application les conserve dans un coffre chiffré et exécute l'action demandée au lieu de remettre les identifiants à l'agent. Cette organisation ne rend pas sûre une requête dangereuse. Il faut toujours restreindre les cibles et examiner les approbations.

Choisissez le transport avec une comparaison écrite des capacités

Vous pouvez prendre une décision défendable sans organiser un long atelier sur les risques. Écrivez une ligne pour l'appel HTTP envisagé et une autre pour la commande SSH envisagée, puis remplissez chaque ligne avec les mêmes informations. Des libellés vagues comme « accès en lecture » ou « accès de maintenance » ne suffisent pas.

Utilisez cette comparaison en cinq points :

1. Décrivez le résultat exact, par exemple « récupérer l'état du déploiement du service A » ou « redémarrer worker-17 après un échec du contrôle de santé ».
2. Nommez toutes les cibles accessibles : collections d'API, projets, hôtes, services, fichiers et destinations réseau.
3. Énumérez les modifications que le même identifiant ou compte peut encore effectuer au-delà du résultat attendu.
4. Décrivez les preuves disponibles après un délai d'attente, un refus ou une réussite apparente.
5. Définissez la limite d'approbation : une exécution, un appel ou une routine préapprouvée avec une identité fixe.

Choisissez HTTP si la ligne de l'API nomme un ensemble de cibles plus restreint, expose une opération plus ciblée et laisse une trace plus claire. Choisissez SSH si la ligne du récepteur distant permet de faire mieux, ou si aucune API n'existe pour l'opération nécessaire sur l'hôte. Si aucune des deux lignes n'est suffisamment limitée, ne connectez pas encore l'agent. Créez d'abord le point d'accès ou le récepteur manquant.

Cette comparaison permet aussi de repérer une recommandation souvent mauvaise : « utilisez SSH pour les lectures et les API pour les écritures ». Elle semble prudente parce que l'accès shell paraît opérationnel et les appels d'API transactionnels. Elle échoue parce que la lecture d'un hôte peut révéler des identifiants, du code source, des données client et la topologie, tandis qu'une modification d'API soigneusement limitée peut ne changer qu'un seul état souhaité. La distinction lecture-écriture ne suffit pas. Les catégories pertinentes sont les données accessibles et les effets secondaires accessibles.

Une équipe qui utilise un agent pour diagnostiquer des échecs de compilation peut avoir besoin d'un point d'accès HTTP pour l'état d'un travail, d'un appel d'API pour récupérer une fenêtre limitée du journal et d'un récepteur distant sur un seul hôte lorsqu'une réparation précise l'exige. Séparer ces fonctions ajoute des interfaces. Cela empêche aussi une tâche de diagnostic courante de transporter un identifiant shell permanent uniquement parce qu'une réparation rare en a besoin.

L'approbation doit suivre le coût d'une mauvaise action

L'approbation est la plus utile lorsqu'elle apparaît à une limite qu'une personne peut comprendre. Demander une confirmation pour chaque lecture d'état sans conséquence habitue les utilisateurs à cliquer sans lire. Accorder une approbation générale couvrant tous les futurs exécutables supprime entièrement l'examen utile.

Utilisez une approbation par exécution lorsqu'un nouveau processus d'agent demande pour la première fois à agir et que son identité peut être affichée clairement. La personne peut comparer l'exécutable demandeur avec le travail qu'elle s'attendait à lancer. Révoquez l'exécution si elle se comporte de manière inattendue, puis examinez ses appels précédents dans l'enregistrement d'action.

Utilisez une approbation par appel pour les actions dont les effets sont irréversibles ou coûteux : renouvellement d'identifiants, suppression, promotion en production, changements de compte et toute action dont l'agent peut sélectionner dynamiquement la cible. La demande d'approbation doit nommer la destination et l'opération en termes ordinaires. « Exécuter la demande de l'outil » n'apprend presque rien à la personne qui examine la demande.

N'essayez pas de remplacer ce jugement par un langage de règles tentaculaire couvrant toutes les exceptions. Les équipes finissent alors par entretenir un second environnement de programmation dont les cas limites autorisent ce qu'elles voulaient bloquer. Un petit ensemble de contrôles fixes est plus facile à examiner : l'état de verrouillage du coffre, l'autorisation de l'exécution et, éventuellement, l'obligation d'approuver chaque utilisation d'un identifiant sensible.

L'approbation ne compense pas un identifiant doté d'une autorité illimitée. Elle donne à une personne la possibilité d'arrêter une action avant qu'elle ne quitte la machine. Le service sous-jacent doit tout de même appliquer sa propre autorisation et le journal d'audit doit conserver ce qui s'est produit après l'approbation.

Construisez une limite d'action distante avant le premier incident

Le meilleur premier changement n'est généralement pas une instruction plus compliquée pour l'agent. Remplacez un identifiant trop large par une limite d'action dont la grammaire d'entrée, l'ensemble de cibles, la stratégie de délai d'attente et les preuves vérifiables par un autre opérateur sont clairement définis.

Pour une tâche HTTP, demandez au responsable du service un point d'accès et un identifiant dont les permissions correspondent à l'action unique. Testez les chemins et méthodes refusés avec autant de soin que les appels réussis. Pour une tâche SSH, créez un compte dédié, désactivez les fonctions interactives, forcez l'utilisation d'un programme récepteur et testez ses entrées malformées. Exécutez ces tests depuis le même chemin que celui de l'agent, car l'accès réseau et les contrôles d'identité diffèrent souvent de ceux d'un ordinateur portable d'administrateur.

Testez ensuite l'échec que personne ne veut simuler : terminez le travail distant, puis coupez la connexion avant que la réponse n'atteigne l'appelant. Si votre agent ne peut pas déterminer, à partir de l'enregistrement conservé et de l'état distant, s'il doit attendre, interroger ou relancer, la conception produira des doublons sous la pression.

Le choix du protocole devient simple dès que vous exigez ces propriétés. Utilisez l'interface qui accorde la plus petite capacité que vous pouvez décrire, fournit une réponse fiable après une défaillance et laisse une trace de l'action qui ne dépend pas du souvenir qu'une personne garde d'une session de terminal.