# Catalogue d’actions pour agent IA : trouvez les accès inutiles

Un catalogue d’actions pour agent IA est le moyen le plus rapide de repérer les autorisations que personne n’a réellement choisies. Il répertorie les opérations qu’un agent peut effectuer en dehors de son propre espace de travail, puis oblige à prendre une décision pour chacune : qui en est responsable, que se passe-t-il en cas d’erreur et faut-il l’approbation d’un humain ?

La plupart des équipes commencent au mauvais endroit. Elles inventorient les clés API, les intégrations ou les comptes logiciels, puis concluent qu’elles comprennent les accès. Ce n’est pas le cas. Un identifiant n’est qu’un conteneur. La décision de sécurité se situe au niveau de l’opération : « créer une facture brouillon » est très différent de « émettre un remboursement », même si les deux appels utilisent le même jeton.

J’ai vu des revues d’autorisations échouer parce qu’une équipe demandait : « L’agent a-t-il besoin d’accéder au système de facturation ? » Cette question est trop large pour recevoir une réponse honnête. Demandez plutôt s’il doit lire une facture précise, créer un brouillon, envoyer une demande de remboursement, modifier des coordonnées de versement ou exporter la liste des clients. Les réponses diffèrent généralement. C’est dans ces différences que l’accès inutile apparaît.

## Une liste d’intégrations dissimule les autorisations importantes

Un inventaire des systèmes indique où l’agent se connecte. Un catalogue d’actions indique ce qu’il peut provoquer. Conservez les deux, mais ne confondez pas l’un avec l’autre.

Prenons un agent connecté à un service de gestion du code source. « Accès au dépôt » peut inclure la lecture du code, l’ouverture d’une pull request, la modification de la protection des branches, la création d’une clé de déploiement, la publication d’une version ou la suppression d’un dépôt. Traiter cet ensemble comme une seule autorisation transforme plusieurs décisions de risque distinctes en un oui ou non paresseux.

La même erreur apparaît avec SSH. « L’agent peut se connecter en SSH à la préproduction » ne dit presque rien. Une commande limitée qui récupère l’état d’un service n’a pas les mêmes conséquences qu’un accès shell sur un compte capable de redémarrer des services, de lire des secrets de déploiement ou de modifier les règles du pare-feu. Cataloguez la famille de commandes ou le point d’accès, pas seulement le moyen de transport.

Cette distinction compte, car les équipes mélangent régulièrement trois dimensions de l’exposition :

- **Joignabilité** : l’agent peut-il contacter un système ?
- **Autorité** : que le système autorise-t-il une fois le contact établi ?
- **Conséquence** : que peut-il se passer si l’agent envoie une demande erronée ou manipulée ?

Un point d’accès interne peut être peu joignable et disposer d’une autorité très élevée. Une API publique peut être largement joignable tout en ayant une autorité limitée. Concevoir les approbations uniquement selon qu’un service est « interne » ou non fait manquer les deux cas.

La publication spéciale 800-53 du NIST, contrôle AC-6, décrit le moindre privilège comme l’octroi des seuls accès nécessaires à l’accomplissement des tâches confiées. Cette formulation paraît évidente jusqu’à ce qu’on l’applique à un agent. « Tâche confiée » ne peut pas signifier « aider l’équipe d’ingénierie ». Il faut parler d’une opération avec une cible, une méthode, une limite et un résultat attendu. Si vous ne pouvez pas l’écrire, vous ne pouvez pas prétendre appliquer le moindre privilège.

Commencez par des noms d’actions qu’un responsable peut comprendre sans ouvrir un dépôt de code. « POST /v1/issues » constitue une preuve utile, mais « créer un ticket dans le système de suivi de l’équipe d’ingénierie » indique au responsable ce qu’il autorise. Conservez les deux dans la fiche.

## Une ligne pour chaque opération visible de l’extérieur

Chaque ligne du catalogue doit représenter l’action la plus précise pouvant faire l’objet d’une décision distincte d’accès ou d’approbation. Si deux opérations peuvent raisonnablement avoir des responsables, des impacts ou des exigences d’approbation différents, elles doivent figurer sur deux lignes.

Une ligne pratique contient assez de détails pour qu’un ingénieur puisse appliquer le contrôle, et assez de langage courant pour que le responsable du système puisse le refuser. Utilisez les champs suivants :

| Champ | À consigner | Pourquoi il existe |
|---|---|---|
| Identifiant de l’action | Identifiant stable, par exemple `deploy.production.restart-service` | Conserve la décision lorsque les noms changent |
| Système | Système et environnement de destination | Sépare l’accès à la production de celui aux tests |
| Opération | Verbe et objet compréhensibles | Rend l’autorisation vérifiable |
| Route technique | Méthode et chemin API, modèle de commande ou appel d’outil | Permet aux ingénieurs d’appliquer la limite |
| Identité | Type d’identifiant, compte, scopes et modèle de délégation | Révèle une autorité partagée ou excessive |
| Données traitées | Données envoyées et résultats renvoyés | Met en évidence le risque de fuite |
| Impact | Catégorie de conséquence et réversibilité | Oriente le choix d’approbation |
| Responsable | Décideur métier ou technique nommé | Attribue la responsabilité à une personne |
| Approbation | Aucune, par session ou à chaque appel | Définit le point de contrôle humain |
| Preuve | Test, référence de journal ou emplacement d’implémentation | Prouve que la ligne correspond à la réalité |
| Date de revue | Date et personne chargée de la revue | Empêche les exceptions anciennes de devenir permanentes |

N’écrivez pas « divers », « tâches d’administration », « API complète » ou « selon les besoins » dans le champ de l’opération. Ces expressions indiquent que le catalogue s’est arrêté avant le début du travail. Divisez l’entrée jusqu’à ce qu’une personne puisse répondre oui ou non sans deviner.

Voici un exemple compact pour un agent de développement :

```yaml
action_id: issue-tracker.create-bug
system: issue tracker, production tenant
operation: Create a bug report in the Engineering project
technical_route: POST /api/projects/engineering/issues
identity: service account agent-issues, scope issues:write
inputs: title, body, labels, repository reference
outputs: issue ID and URL
impact: internal write, reversible by project members
owner: Engineering operations manager
approval: per-session
review_date: 2026-09-30
```

La mention « production tenant » doit figurer dans cette ligne, même si l’action ne crée que des tickets. De nombreuses équipes utilisent un même tenant SaaS de production pour des informations réelles sur les clients, les employés et les incidents. Le libellé de l’environnement indique aux responsables quelle limite ils franchissent.

Évitez la fausse précision. Il n’est pas nécessaire de créer une ligne pour chaque modification de champ sans conséquence lorsque la destination, le responsable, l’identité, l’approbation et la conséquence sont réellement identiques. En revanche, créez des lignes distinctes lorsqu’un champ particulier modifie le résultat. « Mettre à jour le statut d’un incident » et « changer le responsable de l’incident » peuvent passer par le même endpoint, mais ne devraient pas recevoir la même décision d’approbation.

## Découvrez les actions en suivant les identifiants et les workflows

Vous ne trouverez pas l’ensemble des actions en lisant le prompt d’un agent. Les prompts décrivent l’intention ; le code, la configuration, les identifiants et le trafic observé montrent ce que l’agent peut réellement demander.

Commencez par les workflows que les utilisateurs attendent de l’agent. Demandez aux ingénieurs de décrire les dix dernières tâches qu’ils lui ont confiées, ou qu’ils souhaitent lui confier, en utilisant des verbes. « Examiner un build qui a échoué » peut inclure la lecture de journaux, l’interrogation d’un service de déploiement, l’ouverture d’un ticket, le redémarrage d’un environnement de test et la publication d’un message. Notez chaque limite externe franchie.

Remontez ensuite jusqu’à chaque identifiant. Examinez les scopes API, les autorisations OAuth, les rôles des comptes de service, les clés SSH autorisées, les wrappers de commandes, les variables CI et les coffres de secrets locaux. Un identifiant révèle souvent des opérations que personne n’a nommées pendant la discussion sur le workflow. Un jeton API doté d’un scope d’administration des utilisateurs constitue une action potentielle, même si l’équipe affirme que l’agent ne fait que créer des tickets.

Enfin, comparez l’intention aux preuves. Les traces réseau, les journaux de passerelle API, les audits de commandes et les définitions des outils de l’agent révèlent des appels absents du document de workflow. Faites-le d’abord dans un environnement de test sûr lorsque c’est possible. Les journaux de production restent importants, car les agents comme les humains cherchent plus facilement des raccourcis sous pression.

Utilisez cette routine en cinq passages :

1. Listez chaque workflow d’agent qui sort du périmètre de la tâche locale.
2. Extrayez de la configuration et du code de l’agent chaque appel d’outil, endpoint et modèle de commande shell.
3. Énumérez ce que chaque identifiant autorise, y compris les rôles hérités et les scopes génériques.
4. Examinez les journaux d’actions récents à la recherche de destinations ou de verbes absents de la liste.
5. Réconciliez les différences avec la personne responsable du système de destination.

C’est au quatrième passage que les découvertes inconfortables apparaissent. Vous trouverez peut-être un ancien jeton doté de droits d’administration étendus sur les dépôts, une clé SSH de préproduction acceptée par des hôtes de production ou un webhook « interne » capable de déclencher une publication. Ne réduisez pas discrètement l’entrée pour la faire correspondre au plan initial. Inscrivez l’opération effective dans le catalogue et demandez à quelqu’un de décider si elle doit rester.

Un test utile consiste à donner une ligne à un collègue qui n’a pas créé l’intégration. Il doit pouvoir expliquer ce que l’agent envoie, ce qu’il reçoit et quelle serait l’erreur plausible la plus grave. S’il n’y arrive pas, la ligne n’est qu’un déchet technique, pas une trace de contrôle.

## L’impact doit décrire les conséquences, pas un score de risque générique

Classez l’impact selon ce qu’une mauvaise action modifie, expose, dépense ou engage. Une simple note « élevé, moyen, faible » échoue, car elle masque la raison pour laquelle une action requiert l’attention d’un humain.

J’utilise cinq catégories de conséquences dans le catalogue : divulgation, intégrité, disponibilité, engagement externe et modification des privilèges. Une ligne peut relever de plusieurs catégories. La lecture d’un export client entraîne une conséquence de divulgation. La suppression d’un déploiement modifie la disponibilité. L’ajout d’un administrateur modifie les privilèges. L’envoi d’un contrat crée un engagement externe, même si l’action est techniquement réversible.

Ajoutez deux modificateurs : la réversibilité et le rayon d’impact. La réversibilité demande si une personne compétente peut annuler l’action sans perte ni confusion. Le rayon d’impact demande si l’erreur touche un brouillon, un projet, de nombreux utilisateurs ou tout un environnement.

Vous obtenez ainsi des décisions que les responsables peuvent défendre. « Supprimer une branche de test temporaire » peut modifier l’intégrité tout en restant réversible et limité. « Faire tourner les identifiants de la base de données de production » peut préserver la sécurité, mais aussi affecter la disponibilité de nombreux services. Les deux actions écrivent des données, mais elles appartiennent à des catégories d’approbation différentes.

Ne laissez pas l’existence d’une fonction d’annulation dans l’API régler la question de la réversibilité. Un remboursement peut être annulé dans le registre alors que le client a déjà reçu un e-mail déroutant. Un paquet publié peut être retiré après avoir été récupéré par des systèmes en aval. Un compte supprimé peut être restauré alors que son ancien propriétaire perd l’accès pendant un incident. Considérez la conséquence opérationnelle, pas seulement l’opération de base de données.

Les données renvoyées par une action méritent autant d’attention que les données envoyées. Une requête d’état apparemment inoffensive qui renvoie toutes les variables d’environnement, des conversations d’assistance ou des clés privées constitue une action de divulgation. Les équipes se concentrent souvent trop sur la capacité d’écriture d’un agent, parce que l’écriture semble active. Un agent capable de lire tous les secrets puis d’appeler un endpoint externe dispose de suffisamment d’accès pour provoquer un incident grave.

Employez un langage concret pour décrire l’impact. Remplacez « impact élevé » par « peut modifier les autorisations de production pour tous les membres de l’espace de travail » ou « peut transmettre des identifiants client à une API tierce ». La première formulation indique au responsable ce qu’il doit décider. L’étiquette seule ne le fait pas.

## La responsabilité doit revenir à la personne qui peut dire non

Chaque action doit avoir un responsable nommé capable de la refuser, de la réduire ou de la supprimer. Cette personne est responsable de la décision d’autorisation, pas de tous les résultats opérationnels produits par l’agent.

Le meilleur responsable appartient généralement au système de destination ou assume la conséquence métier. Un responsable de l’ingénierie peut posséder les actions de déploiement en production. Le service financier possède l’envoi des remboursements. L’équipe sécurité peut définir les conditions d’administration des accès, mais elle ne doit pas devenir le responsable par défaut de chaque ligne simplement parce qu’elle est l’équipe sécurité.

La responsabilité partagée est l’endroit où les catalogues se dégradent. « Sécurité et ingénierie » signifie que chaque groupe suppose que l’autre fera la revue. Notez un seul responsable et indiquez les équipes consultées dans les remarques si nécessaire. Si un responsable change de poste ou d’équipe, transférez les lignes du catalogue lors de cette passation.

Les responsables ont besoin d’un dossier de décision qui tient sur un écran. Donnez-leur l’opération, le système, l’identité effective, les données concernées, la conséquence, l’approbation proposée et une brève raison justifiant le besoin de l’agent. Ne leur remettez pas une liste brute de scopes OAuth en prétendant qu’il s’agit de gouvernance.

Le responsable doit répondre à quatre questions :

- L’agent a-t-il besoin de ce résultat, ou le workflow le trouve-t-il simplement pratique ?
- Un endpoint, un rôle, un compte, une cible ou une commande plus limité pourrait-il fournir ce résultat ?
- Quelle erreur créerait une conséquence inacceptable ?
- Qui doit approuver l’utilisation et quand cette décision doit-elle expirer ?

La première question est généralement la plus gênante. Les équipes accordent souvent une opération étendue pour éviter une future discussion. Ce n’est pas une exigence. C’est une revue d’accès différée, attachée à un identifiant.

Rendez la responsabilité visible dans le chemin d’exécution. Si personne ne peut identifier le responsable pendant un incident, le catalogue n’a pas rempli son rôle. Un responsable nommé rend aussi la revue périodique possible, car elle pose une question directe : « Autorisez-vous toujours l’action X pour cet agent et cette identité ? »

## L’approbation doit correspondre au moment de l’engagement

L’approbation est utile lorsqu’elle intervient avant que l’agent ne provoque une conséquence et lorsque le réviseur comprend ce qu’il autorise. Un bouton indiquant « autoriser l’utilisation de l’outil » après que l’agent a regroupé dix opérations sans rapport relève de la mise en scène sécuritaire.

Utilisez trois états d’approbation dans le catalogue. « Aucune » signifie que l’action peut continuer une fois que l’agent a obtenu l’autorité de sa session. « Par session » signifie qu’un humain approuve un processus d’agent précis avant qu’il puisse appeler les actions autorisées. « À chaque appel » signifie qu’un humain examine chaque utilisation de cette action.

L’approbation par session convient aux actions précises et courantes dont les conséquences restent modérées, comme lire l’état d’un build ou créer des tickets internes à l’état de brouillon. Elle établit que le processus d’agent prévu est actif, puis lui permet de terminer le travail ordinaire sans demander à une personne de cliquer à répétition.

L’approbation à chaque appel convient aux actions qui créent un engagement ou franchissent une limite difficile. Utilisez-la pour modifier les accès de production, supprimer des enregistrements importants, déclencher des déploiements qui touchent les clients, envoyer des messages hors de l’entreprise, gérer de l’argent et exporter des jeux de données sensibles. Demander à un humain d’examiner chaque requête constitue ici une friction appropriée.

La demande d’approbation doit fournir du contexte. Affichez au minimum l’identité du processus appelant, l’opération, la destination, l’environnement cible et les paramètres importants. « L’agent demande POST » oblige le réviseur à reconstituer l’action sous pression. « Redémarrer le service de paiements en production, à la demande du processus signé X » lui donne une décision qu’il peut prendre.

N’utilisez pas les demandes d’approbation pour compenser une autorisation qui ne devrait pas exister. Une demande à chaque appel pour « exécuter une commande shell arbitraire en production » laisse toujours au réviseur le soin d’approuver à répétition un chèque en blanc. Remplacez la capacité shell étendue par des commandes limitées ou des opérations distinctes, puis approuvez-les lorsque cela est nécessaire.

La passerelle d’actions joue ici un rôle important, car elle peut garder les identifiants hors de portée de l’agent tout en plaçant la décision humaine près de l’exécution. Sallyport utilise une échelle de décision fixe : un coffre verrouillé refuse chaque action, un nouveau processus d’agent reçoit par défaut une autorisation par session et certaines clés peuvent exiger une approbation à chaque utilisation.

Cette structure évite une erreur fréquente : inventer un langage de règles tentaculaire avant d’avoir catalogué les actions assez précisément pour écrire des règles sûres. Les politiques complexes paraissent mûres dans un document de conception, puis deviennent impossibles à examiner lorsque les exceptions arrivent. Commencez par des opérations claires, des identités limitées et une approbation qui correspond à l’impact.

## Un catalogue révèle le chemin d’échec avant la production

Un catalogue prouve sa valeur lorsqu’il détecte une chaîne de choix ordinaires qui paraît acceptable prise séparément. Prenons un agent de programmation chargé d’enquêter sur l’échec d’un workflow de commande.

Un ingénieur lui donne un jeton de service parce que ce jeton peut lire les journaux. Le même jeton peut aussi interroger l’API des commandes. L’agent trouve une commande malformée et reçoit l’instruction de « nettoyer les données de test ». Il appelle un endpoint de suppression sur le tenant de production parce que l’intégration ne distingue pas clairement les noms des tenants. L’endpoint accepte la requête. Un humain constate ensuite que la commande était réelle, mais sa restauration exige une réconciliation entre les systèmes de paiement, d’inventaire et d’assistance client.

Chaque phrase semblait inoffensive : lire les journaux, interroger les commandes, supprimer des données de test. Le catalogue d’actions aurait séparé la chaîne en plusieurs lignes :

| Opération | Problème caché | Meilleure décision |
|---|---|---|
| Lire les journaux du workflow de commande | Les journaux contiennent des identifiants client | Limiter les champs renvoyés et consigner l’impact de divulgation |
| Interroger une commande par son identifiant | Le jeton donne un accès étendu aux commandes | Utiliser une identité en lecture seule limitée au tenant requis |
| Supprimer une commande de test | La production et les tests partagent une famille d’endpoints | Séparer les environnements cibles et exiger une approbation à chaque appel |
| Corriger la commande d’un client | Il ne s’agit pas d’un nettoyage | Attribuer la responsabilité à l’équipe opérationnelle et retirer l’action du périmètre de l’agent |

La conclusion utile n’est pas que « les agents font des erreurs ». Les humains commettent la même chaîne d’erreurs lorsque les limites d’accès sont floues. Les agents exécutent plus vite, réessaient plus facilement et peuvent suivre une instruction localement raisonnable sans remarquer le contexte métier qu’un humain aurait déduit.

Écrivez les chemins d’échec dans les notes des lignes à fortes conséquences. Utilisez un format simple : déclencheur, mauvaise cible ou mauvaise interprétation, action effectuée, effet immédiat, effort de récupération. Cela rend les choix d’approbation moins abstraits et donne aux réviseurs une raison de refuser un accès étendu.

Un catalogue détecte aussi les combinaisons dangereuses. Lire des notes d’incident peut être acceptable. Publier sur une page d’état publique peut l’être avec revue. Autoriser un même agent à faire les deux sans limite de contenu peut exposer des informations internes sur l’incident. Examinez les combinaisons dans lesquelles une action fournit une donnée sensible et une autre l’envoie hors de l’organisation.

## Rendez le catalogue applicable, puis vérifiez qu’il correspond à la réalité

Un catalogue qui ne vit que dans un tableur devient une liste de souhaits d’autorisations. Reliez chaque ligne approuvée à une limite technique : identifiant distinct, scope API restreint, liste blanche de destinations, commande SSH limitée ou configuration d’approbation.

Utilisez les identifiants d’action dans la configuration et les journaux. Vous obtenez un test simple : chaque action externe observée doit correspondre à un identifiant du catalogue, et chaque identifiant actif du catalogue doit correspondre à un point d’application actuel. Examinez les deux écarts. Une action observée sans ligne correspond à un accès clandestin. Une ligne sans application peut être un projet obsolète ou un chemin non contrôlé.

Pour les appels HTTP, vérifiez la méthode, l’hôte, le modèle de chemin, l’environnement cible et le scope de l’identifiant. Pour SSH, vérifiez le compte, le groupe d’hôtes, les restrictions de commande et la possibilité pour l’outil auxiliaire de transmettre des arguments arbitraires. « L’accès SSH est approuvé » n’est pas une déclaration applicable techniquement.

Par exemple, cette entrée du catalogue affirme que l’agent peut uniquement récupérer l’état d’un déploiement :

```text
Action ID: deploy.status.read
Host: deploy.internal.example
Command: deployment-status --service <approved-service>
Identity: agent-deploy-read
Approval: per-session
```

Cette implémentation contredit cette affirmation :

```sh
command="/usr/local/bin/deployment-status $SSH_ORIGINAL_COMMAND" ssh-ed25519 AAAA... agent
```

Le wrapper transmet une commande originale arbitraire comme argument. Si `deployment-status` invoque un shell ou accepte une option non vérifiée, la limite du catalogue est fictive. Une conception plus sûre associe un nom de service approuvé à une commande fixe et rejette toute autre entrée. Testez volontairement le chemin de rejet.

```sh
case "$1" in
  checkout) exec /usr/local/bin/deployment-status --service checkout ;;
  search) exec /usr/local/bin/deployment-status --service search ;;
  *) echo "service not permitted" >&2; exit 1 ;;
esac
```

Ne copiez pas cet extrait sans réflexion dans une configuration authorized-keys. Il illustre la propriété recherchée : l’agent sélectionne des actions définies, et non un langage de commandes arbitraire. Votre environnement a toujours besoin d’une validation des entrées, de restrictions de compte et de tests menés par une personne qui comprend le comportement de la commande.

Pour les preuves d’action, consignez un test qui démontre les deux côtés de la limite. Un test positif prouve que l’appel approuvé fonctionne. Un test négatif prouve qu’un appel interdit proche échoue. Les équipes ne conservent souvent que le test positif, ce qui permet aux identifiants étendus de survivre discrètement.

Sallyport enregistre les sessions d’agent et les appels individuels dans un même journal d’audit chiffré et chaîné par hachage. Sa commande `sp audit verify` peut vérifier cette chaîne hors ligne sur le texte chiffré, sans accès à la clé du coffre. Ces preuves aident à comparer le catalogue au comportement réel, mais elles ne remplacent pas la décision de supprimer une action inutile.

## Réexaminez les accès lorsque le travail change, pas après une surprise trimestrielle

Réexaminez le catalogue lorsque vous ajoutez un outil, modifiez un workflow d’agent, émettez ou faites tourner un identifiant, changez de responsable système ou découvrez un quasi-incident. Ces événements modifient l’accès effectif. Attendre une revue calendaire laisse les anciennes hypothèses persister pendant que les intégrations s’accumulent.

Définissez malgré tout une date de revue pour chaque ligne. Les opérations à fortes conséquences méritent un intervalle plus court que les lectures internes inoffensives. Une revue ne doit pas demander si le tableur existe encore. Elle doit demander si l’agent a toujours besoin de cette opération précise, si l’identité reste limitée, si le responsable est toujours le bon et si l’utilisation observée justifie sa conservation.

Supprimez activement les actions inutilisées. Les équipes hésitent, car elles craignent qu’un agent ait besoin de l’autorisation plus tard. Si cela arrive, ajoutez-la de nouveau en passant par le même responsable et la même décision d’approbation. Réaccorder une opération connue demande moins d’efforts que nettoyer une action qui n’aurait jamais dû subsister.

Le premier catalogue utile n’a pas besoin d’être parfaitement exhaustif. Choisissez un agent, listez chaque opération externe qu’il peut effectuer aujourd’hui et obligez un responsable à prendre une décision pour chaque ligne. Vous découvrirez des accès qui existent parce que personne n’avait encore eu besoin de les nommer. Ce sont ces accès qu’il faut supprimer avant qu’ils ne soient utilisés au pire moment.