Appels de découverte ou appels de mutation : sécuriser les agents IA

Un agent qui peut inspecter largement un système et le modifier à la légère dispose d’une autorité mal conçue. La séparation utile est simple : laissez l’agent découvrir suffisamment d’éléments pour établir un plan fondé sur les faits, puis fixez une frontière claire autour des opérations qui créent, modifient, déclenchent ou suppriment un état.

Cette séparation paraît évidente jusqu’à ce qu’on rencontre une vraie API. Un point d’accès présenté comme étant en lecture seule actualise un cache. Un aperçu alloue une tâche distante. Un point d’accès de mise à jour accepte un filtre vide et agit sur chaque enregistrement. Une commande SSH semble inoffensive, jusqu’à ce qu’une expansion du shell transforme un chemin précis en une cible beaucoup plus large. Les noms des méthodes et les bonnes intentions ne protègent pas un compte de production.

J’ai vu des équipes résoudre le problème en plaçant un humain devant chaque appel. Cela protège le compte pendant un après-midi et habitue tout le monde à approuver sans lire dès le vendredi. Une meilleure conception laisse les agents inspecter, rend les changements d’état évidents et concentre la friction là où une mauvaise action aurait un résultat irréversible ou coûteux.

La découverte demande une forme d’autorisation différente

Les appels de découverte doivent répondre à des questions sur l’état actuel sans le modifier, tandis que les appels de mutation tentent de créer, modifier, exécuter ou supprimer quelque chose. La distinction compte : un agent ne peut pas planifier correctement à partir d’hypothèses obsolètes, mais il ne devrait pas non plus recevoir un droit permanent d’agir simplement parce qu’il a besoin de contexte.

Un agent de programmation qui enquête sur un échec de déploiement peut avoir besoin de lister les services, récupérer les événements récents, comparer une révision de configuration, examiner l’état du dépôt et lire un ticket distant. Ces demandes réduisent l’incertitude. Si vous exigez une approbation pour chacune, l’opérateur voit une suite de petites demandes sans assez de contexte pour les évaluer. L’agent perd aussi le fil de son enquête pendant l’attente.

Ce même agent pourrait ensuite redémarrer une charge de travail, fusionner une pull request, renouveler un identifiant, fermer un ticket ou supprimer un objet. Chacune de ces opérations modifie le monde extérieur à la fenêtre de contexte de l’agent. L’opérateur doit voir la cible et l’effet prévus avant de les autoriser.

Cela ne revient pas à accorder un rôle général « en lecture seule » et à considérer le problème comme réglé. La découverte peut exposer des informations sensibles. Elle peut aussi entraîner des coûts, consommer des limites de débit ou activer un comportement dans un service mal conçu. La séparation vise à contrôler l’action, pas à déclarer l’inspection inoffensive.

Une classification utile demande ce que le système distant peut constater une fois la requête terminée :

1. Un appel de découverte renvoie des informations et ne modifie aucun état métier, opérationnel ou de facturation pertinent.
2. Un appel de mutation crée, met à jour, supprime, exécute, publie, envoie ou modifie autrement un état visible de l’extérieur.
3. Un appel ambigu doit être traité comme une mutation jusqu’à ce que quelqu’un démontre le contraire.

Cette troisième catégorie compte davantage que ne le pensent la plupart des équipes. Si personne ne peut expliquer les effets secondaires d’un point d’accès à partir de son contrat et d’un test contrôlé, ne l’ajoutez pas à l’ensemble de découverte sans surveillance simplement parce que son nom semble inoffensif.

Les verbes HTTP donnent un indice, pas une décision d’autorisation

Les noms des méthodes HTTP aident à classer les appels, mais ne remplacent pas l’examen du point d’accès. RFC 9110 définit GET, HEAD, OPTIONS et TRACE comme des méthodes « sûres », ce qui signifie que le client ne demande pas de changement d’état. La RFC avertit aussi qu’un serveur peut tout de même journaliser les requêtes, facturer un compte ou produire d’autres effets indirects.

Cette distinction est facile à manquer. La sécurité HTTP décrit la sémantique attendue de la requête, pas une promesse cryptographique que l’implémentation n’a rien fait. RFC 9110 confie au propriétaire de la ressource la responsabilité d’éviter les actions dangereuses lorsque les utilisateurs suivent les conventions des méthodes sûres. Votre agent ne peut pas faire respecter cette promesse si le service ne la respecte pas.

Considérez ces règles comme des points de départ, pas comme des décisions finales :

1. GET et HEAD appartiennent généralement à l’ensemble des candidats à la découverte. Examinez d’abord les paramètres de requête et la documentation du point d’accès.
2. POST, PUT, PATCH et DELETE appartiennent à l’ensemble des mutations, sauf si un point d’accès précis dispose d’un comportement de lecture documenté et testé.
3. OPTIONS peut inspecter les capacités du serveur, mais certaines plateformes incluent des informations propres au compte qui nécessitent tout de même un contrôle du périmètre.
4. Un test de webhook, un aperçu de tâche, une exportation de rapport ou un point d’accès de recherche peut utiliser POST tout en restant purement observationnel. Vérifiez-le au lieu d’autoriser tous les POST.

L’échec inverse est également fréquent. Des développeurs relient parfois un lien ou une route GET à une action parce que c’est pratique. Une URL comme /reports/monthly?refresh=true peut reconstruire un cache de rapport coûteux. Un point d’accès GET avec ?send=true peut envoyer une notification. Un agent qui suit la description d’une API utilisera ce qu’il reçoit. N’attendez pas du modèle qu’il remarque que le concepteur du serveur a ignoré la sémantique HTTP.

Lisez la documentation du point d’accès à la recherche de termes comme « crée », « lance », « actualise », « génère », « envoie », « enregistre », « synchronise » et « facture ». Ces verbes doivent faire sortir l’appel de la découverte, même si la route utilise GET. Testez ensuite le point d’accès avec un compte jetable et comparez l’état avant et après, notamment les files de tâches, les notifications, les compteurs d’utilisation et les journaux d’audit.

La réponse HTTP aide également à classer la requête. Une réponse qui renvoie un identifiant de tâche, un identifiant d’opération ou l’URL d’une nouvelle ressource indique souvent que le service distant a commencé à travailler. Un statut 200 prouve seulement que le serveur a traité la requête. Il ne prouve pas qu’elle était purement observationnelle.

Définissez les ressources et les effets avant de créer des listes d’autorisation

Une liste blanche de chemins est trop rudimentaire si elle ignore la ressource et l’effet associés à chaque chemin. Définissez un petit inventaire des actions indiquant ce qu’un agent peut inspecter, ce qu’il peut proposer et ce qu’il ne doit jamais faire sans une décision humaine directe.

Utilisez une fiche comme celle-ci pour chaque action externe. Les noms importent peu. Les éléments de preuve, eux, sont essentiels.

Action: repository pull request list
Channel: HTTP
Target pattern: GET /repos/{owner}/{repo}/pulls
Class: discovery
Data returned: title, status, branch names, review metadata
Side-effect evidence: API reference defines this endpoint as a list operation
Scope limit: named repositories only
Review date: 2025-02-14

Action: repository merge pull request
Channel: HTTP
Target pattern: PUT /repos/{owner}/{repo}/pulls/{number}/merge
Class: mutation
Effect: changes merge state and source history
Required control: explicit approval for each call

L’inventaire force une décision que les équipes laissent souvent floue : l’agent a-t-il le droit de connaître cette ressource, ou celui de la modifier ? Ce sont deux autorisations distinctes. Un système de tickets peut autoriser la découverte du titre et de l’état d’un problème, tout en refusant le contenu des commentaires parce qu’ils contiennent des données clients. Un compte cloud peut autoriser l’énumération d’une charge de travail strictement limitée, tout en refusant l’accès aux identités et aux informations de facturation du compte entier.

Conservez le périmètre dans la fiche d’action. GET /projects n’est pas une description d’autorisation utile si l’identifiant permet de lister tous les projets jamais créés par une entreprise. Une meilleure description nomme l’organisation, le dépôt, l’espace de noms, le compte ou le chemin dont l’agent a besoin. Si le service en amont ne permet pas de limiter l’identifiant de cette manière, imposez une liste de cibles autorisées à la passerelle d’actions ou ne rendez pas cette découverte automatique.

Ne remplissez pas cette liste à partir des seuls fichiers swagger. Les descriptions d’API indiquent souvent la méthode et les paramètres, mais omettent les conséquences opérationnelles. Associez la documentation à un compte de test, à la trace d’audit du service et à la personne responsable du système distant. Le but est de formuler une affirmation explicite que quelqu’un pourra réexaminer lorsque l’API changera.

Une requête de lecture peut quand même nuire au système

L’accès en lecture a un rayon d’impact et mérite ses propres limites. Un agent autorisé à inspecter chaque dépôt, nom de secret, note d’incident, fiche client et événement de déploiement dispose de suffisamment de contexte pour causer des dommages si un attaquant contrôle le processus de l’agent ou ses instructions.

La recommandation courante est « commencez par accorder la lecture seule ». Elle est populaire parce qu’elle semble prudente et correspond aux noms familiers des rôles IAM. Elle est mauvaise lorsqu’elle remplace une réflexion sur la classification des données par un rôle de lecture trop large. Une découverte générale provoque souvent la plus grande fuite d’informations de la conception.

Séparez deux questions :

• La requête peut-elle modifier l’état distant ?
• La réponse peut-elle révéler des informations que l’agent ne devrait pas recevoir ?

Une requête ne mérite le traitement de découverte qu’après avoir franchi le premier test. Elle ne doit recevoir une autorisation qu’après avoir franchi le second. Ne réduisez pas ces deux tests à une seule étiquette.

Pour les ressources sensibles, ne renvoyez que les champs nécessaires à l’agent. Pour diagnostiquer un déploiement, il peut avoir besoin de l’état du pod, de l’empreinte de l’image et des messages d’événements récents. Il n’a pas besoin des valeurs d’environnement ni de l’objet de configuration complet. Un agent de triage des tickets peut avoir besoin des libellés et des horodatages, pas de chaque commentaire privé. Si une API ne permet pas de sélectionner les champs, placez devant elle une action intermédiaire limitée ou gardez l’opération soumise à approbation.

La pagination mérite aussi de l’attention. Un point d’accès de liste peut sembler limité lors d’un test normal, puis devenir un moyen d’extraire des données sans limite lorsque l’agent suit les curseurs. Limitez la taille des pages et le nombre total de pages lorsque le canal le permet. Inscrivez cette limite dans l’inventaire des actions. Les limites de débit protègent le fournisseur, mais ne définissent pas la frontière d’information adaptée à votre agent.

Les points d’accès de recherche doivent recevoir le même traitement. Une recherche en texte intégral dans le code source ou les dossiers d’assistance peut révéler davantage qu’une consultation directe d’objet, et le texte de l’invite peut influencer la requête. Limitez les collections consultables et la syntaxe des requêtes. Ne transmettez pas directement des expressions de recherche créées par l’agent à un moteur puissant sous prétexte que la requête utilise GET.

Les identifiants doivent appliquer cette séparation lorsque c’est possible

Le meilleur endroit pour distinguer l’inspection de l’action est le modèle d’autorisation du service distant. Utilisez un identifiant capable de lire les ressources approuvées pour la découverte et un autre identifiant capable d’exécuter les mutations limitées nécessaires au workflow.

Cette organisation limite un échec simple mais désastreux : un agent malveillant ou désorienté découvre un point d’accès de mutation que vous avez oublié de refuser. Si l’identifiant de découverte ne peut pas écrire, l’appel échoue même si votre couche d’action le classe incorrectement. C’est une défense indépendante, pas une raison de négliger l’inventaire des actions.

Certains services facilitent cette séparation avec des scopes, des rôles, des permissions de projet ou des identités machine distinctes. D’autres n’exposent qu’un jeton personnel très large. Lorsqu’un fournisseur ne propose que cette dernière option, utilisez les limites de compte et de projet les plus étroites disponibles, puis imposez les points d’accès et les modèles de cibles dans votre passerelle. Ne donnez jamais à un agent autonome les identifiants personnels d’un administrateur simplement parce qu’ils sont déjà disponibles.

Une configuration claire comprend souvent trois catégories d’identifiants :

1. Un identifiant de découverte donnant accès uniquement aux ressources précises que l’agent peut inspecter.
2. Un identifiant de mutation pour les écritures limitées qui nécessitent toujours une décision d’approbation.
3. Un identifiant de secours que les agents n’utilisent jamais et que les humains ne récupèrent que dans le cadre d’un processus d’incident.

Ne laissez pas par défaut un identifiant de mutation répondre aux appels de découverte. Cela semble inoffensif puisque le point d’accès est en lecture seule, mais les révisions futures deviennent plus difficiles. Un journal indiquant qu’un identifiant puissant a interrogé une ressource ne permet pas de savoir si l’agent avait besoin de cette autorité. Gardez un sens clair à l’identité.

Sallyport conserve les identifiants API et SSH dans son coffre chiffré et exécute lui-même l’action externe. Un agent MCP reçoit donc le résultat, pas le secret. Cette conception permet d’exposer une route de découverte limitée sans placer de jeton porteur ni de clé SSH privée dans le contexte de l’agent.

L’approbation doit décrire le changement, pas punir chaque requête

L’approbation appel par appel fonctionne lorsque la personne chargée de vérifier voit un effet concret et peut décider rapidement. Elle échoue lorsque le système demande son consentement après chaque consultation sans danger : l’humain apprend alors que la demande ne contient aucune décision réelle.

Utilisez l’autorisation de session pour établir quel processus d’agent peut utiliser l’ensemble de découverte. Demandez ensuite une approbation individuelle pour les mutations, en présentant la requête dans des termes qu’un humain peut évaluer. « POST /v1/jobs » est une mauvaise formulation. « Démarrer une exportation de données pour le projet northwind vers le compartiment d’archives, avec une durée estimée de 30 jours » donne à l’opérateur quelque chose à vérifier.

La fiche d’approbation doit inclure la cible, l’opération, les paramètres importants et l’identité de l’identifiant utilisé. Ne cachez pas la cible dans un long corps JSON. Si une action touche plusieurs ressources, affichez le nombre et un échantillon compact, puis demandez à l’opérateur d’ouvrir la liste complète lorsque ce nombre dépasse la plage habituelle.

Une requête de mise à jour limitée pourrait ressembler à ceci :

{
  "action": "update_issue",
  "target": {
    "repository": "payments-api",
    "issue": 1842
  },
  "changes": {
    "labels_add": ["needs-review"],
    "assignee": "release-manager"
  },
  "reason": "The release checklist is complete."
}

L’agent peut préparer cette requête après une découverte libre dans le périmètre qui lui est accordé. L’humain doit approuver le changement, pas reconstruire toute l’enquête de l’agent. Conservez la justification, car elle facilite l’examen ultérieur, mais ne la considérez pas comme un contrôle de sécurité. Un agent peut produire une phrase plausible pour une mauvaise cible.

Évitez les règles d’approbation fondées uniquement sur l’intention exprimée en langage naturel. « Approuver les changements de déploiement » semble raisonnable jusqu’à ce qu’un agent qualifie une suppression de base de données de changement de déploiement. L’approbation doit être liée à une classe d’opération, à un périmètre de cible et à un identifiant. Le texte aide les humains à comprendre la demande. Des limites d’action typées empêchent les incohérences.

Les suppressions et les exécutions externes doivent avoir leur propre catégorie

Les suppressions, changements de permissions, renouvellements d’identifiants, opérations financières et appels qui déclenchent des systèmes externes doivent être traités plus strictement que les mises à jour ordinaires. Ils peuvent supprimer des possibilités de récupération, modifier les personnes autorisées, créer des coûts ou provoquer un travail extérieur au système dans lequel l’agent a commencé.

Ne cachez pas les suppressions dans la catégorie générale des mutations. Corriger le libellé d’un problème se répare généralement facilement. Un appel de suppression peut enlever des pièces jointes, des enregistrements enfants, l’historique ou un environnement nommé. L’API peut aussi lancer un nettoyage asynchrone après avoir renvoyé un succès, ce qui empêche parfois l’opérateur d’annuler l’erreur avec une seule requête compensatoire.

Exigez un contrôle distinct appel par appel pour les actions suivantes :

1. Supprimer, purger, archiver lorsque l’archivage modifie la disponibilité, et supprimer en masse.
2. Modifier les permissions, appartenances, rôles, secrets, identifiants et politiques d’accès.
3. Déployer, redémarrer, mettre à l’échelle, migrer et exécuter des commandes distantes.
4. Envoyer des courriels, publier des messages, ouvrir des tickets externes et démarrer des tâches payantes.

Avant de présenter l’approbation à une personne, obligez l’agent à résoudre les identifiants dans un aperçu. Une demande de suppression sur records?filter=status=inactive doit afficher le nombre exact, le filtre et des noms représentatifs. Mieux encore, demandez à l’agent de récupérer d’abord les identifiants candidats et de transmettre une liste que la passerelle comparera à la requête d’exécution. Cela n’élimine pas les courses critiques, mais intercepte l’erreur la plus fréquente : un filtre dont le sens diffère de celui supposé par l’agent.

Une confirmation limitée dans le temps est également pertinente. Si un opérateur a approuvé une demande destructive il y a une heure, l’agent ne doit pas pouvoir utiliser cette approbation après un changement de l’état environnant. Liez l’approbation à un corps de requête ou à un condensé immuable, pas à une catégorie générale comme « supprimer les accès aujourd’hui ».

SSH exige une classification au niveau de la commande

SSH est plus difficile à classer qu’une API bien conçue, car une ligne de commande peut combiner inspection et mutation, appeler un shell, suivre des alias ou changer de comportement selon l’environnement distant. Vous ne pouvez pas déclarer un hôte entier en lecture seule simplement parce que l’agent prévoit d’y exécuter une commande de lecture.

Commencez par des commandes et des arguments explicites. git status --short, git log -n 20 --oneline et kubectl get pods -n staging sont des actions de découverte plausibles si vous limitez le répertoire de travail, le contexte du cluster et l’espace de noms. git push, kubectl apply, kubectl delete, rm, l’installation de paquets et les redémarrages de services appartiennent aux catégories de mutation ou d’exécution destructive.

Refusez la composition de shell pour les découvertes sans surveillance. Voici le genre de commande qui ressemble à une demande de liste, mais rend le contrôle au shell :

find "$WORKDIR" -maxdepth 2 -type f -name '*.log' -print; $EXTRA_COMMAND

Même si l’agent fournit une valeur vide pour EXTRA_COMMAND lors des tests, une valeur ultérieure peut exécuter tout ce que permet l’identité SSH. N’approuvez pas une grammaire de commande contenant ;, &&, ||, une substitution de commande, des redirections, une expansion de caractères génériques sur des chemins non contrôlés ou l’appel d’un interpréteur, sauf si l’action elle-même est examinée comme une exécution.

Utilisez plutôt des arguments structurés. Une passerelle peut accepter une action nommée list_recent_logs, valider un répertoire fixe et une limite numérique, puis construire elle-même la commande distante. L’agent ne doit jamais envoyer une chaîne shell lorsqu’une action typée suffit.

Le même principe s’applique aux outils dotés de verbes de lecture. kubectl get peut divulguer des secrets si la ressource et l’espace de noms sont trop larges. git show peut exposer un identifiant malencontreusement envoyé dans le dépôt. Construisez les permissions de commande autour de l’exécutable, du sous-commande, des arguments, du répertoire de travail et de l’identité distante. Le verbe seul apporte très peu d’information.

Les journaux d’audit doivent montrer que la frontière a tenu

Une piste d’audit doit permettre de répondre aux questions suivantes : qui a effectué l’appel, quelle route d’identification l’action a utilisée, quelle cible elle a atteinte, une personne l’a-t-elle approuvée et qu’a renvoyé le système distant ? Si la trace indique seulement « l’agent a appelé l’outil », elle ne peut pas prouver que l’accès de découverte est resté séparé de l’autorité de mutation.

Journalisez les actions tentées et celles qui ont abouti. Une demande de suppression refusée est importante. Elle peut indiquer que l’agent a mal compris son périmètre, qu’une injection de prompt a tenté de l’orienter ou que quelqu’un teste la frontière. Enregistrez la raison du refus sans écrire de secrets ni de corps de réponse sensibles dans un journal accessible plus largement que le système d’origine.

Pour chaque action, capturez au moins les champs suivants dans un enregistrement résistant aux modifications :

• L’identité du processus de l’agent et l’identifiant de session.
• La classe de l’action : découverte, mutation, destructive ou exécution externe.
• L’identité de la cible, la méthode de requête ou la forme de la commande, ainsi qu’une représentation sûre des paramètres.
• L’événement d’approbation, notamment l’humain approbateur lorsqu’une approbation était nécessaire.
• Le résultat, le statut distant, la référence du résultat et les horodatages.

Une chaîne de hachage aide à détecter les modifications du journal, mais ne rend pas utile un événement vague. Enregistrez un événement d’action canonique avant l’exécution, puis liez-y l’enregistrement de la réponse. Si l’événement indique seulement POST /jobs, un examinateur ne saura toujours pas si l’agent a lancé un rapport inoffensif ou une exportation coûteuse.

Sallyport regroupe les journaux de session et d’appel dans un journal d’audit chiffré et chaîné par hachage. La commande sp audit verify vérifie la chaîne hors ligne sans nécessiter l’accès au coffre. Cette vérification n’est utile que si la taxonomie des actions rend l’événement compréhensible. Gardez donc la classification près du chemin d’exécution plutôt que d’ajouter les étiquettes plus tard dans une couche de rapports.

Testez la frontière avec des échecs, pas seulement avec des scénarios normaux

Une séparation des permissions gagne la confiance lorsqu’elle bloque les mauvaises requêtes prévisibles. Traitez chaque action de découverte comme un contrat testable et exécutez des cas négatifs chaque fois que l’API, l’enveloppe de commande ou le workflow de l’agent change.

Pour une route HTTP de découverte, testez une cible autorisée, une cible voisine interdite, une méthode non prise en charge, une demande de page trop volumineuse et une requête qui tente de franchir une frontière de locataire ou de projet. Attendez des refus précis. Une erreur serveur générique apporte peu de garanties, car elle pourrait devenir un succès après une petite modification du code.

Pour une route de mutation, vérifiez qu’une requête valide s’arrête pour demander une approbation, que toute modification d’un champ important invalide cette approbation et qu’un second processus d’agent n’hérite pas de l’autorisation de session du premier. Pour une suppression, testez les sélecteurs vides, les sélecteurs ressemblant à des caractères génériques, les listes plus grandes que prévu et les cibles disparues entre l’aperçu et l’exécution.

Conservez une trace complète pour chaque classe d’action. Une bonne trace est assez courte pour être lue par un examinateur et assez concrète pour révéler une incohérence :

09:14:03  discovery  GET /projects/acme/services?limit=20  allowed
09:14:05  discovery  GET /projects/acme/services/api-7/events  allowed
09:14:11  mutation   POST /projects/acme/services/api-7/restart  approval required
09:14:32  mutation   POST /projects/acme/services/api-7/restart  approved by operator
09:14:34  mutation   result: accepted, operation=op_481

Si la troisième ligne indique plutôt GET /services/api-7?action=restart, votre modèle de classification vient de révéler un défaut. Corrigez le contrat de l’action ou gardez cette route sous le contrôle des mutations. Ne créez pas d’exception parce que le point d’accès est mal conçu.

Commencez par les actions externes que vos agents exécutent déjà. Classez chacune selon son effet, vérifiez son comportement réel, limitez la cible et testez les cas de refus. Lorsqu’un agent demande une nouvelle action, exigez une classification explicite avant qu’elle n’atteigne la production. Cette courte pause coûte moins cher que d’avoir à expliquer après coup une modification qui n’a jamais été examinée.