# Contrôles d’approbation des agents IA : règles ou décisions claires

Un agent IA n’a pas besoin d’un programme miniature d’autorisation d’entreprise chaque fois qu’il lui faut un jeton API ou une clé SSH. La plupart des équipes ont besoin de trois décisions qui restent compréhensibles sous pression : le coffre de secrets est-il disponible, ce processus d’agent peut-il agir pendant cette exécution et cet identifiant précis nécessite-t-il une nouvelle décision humaine ?

Les moteurs de politiques peuvent répondre à bien plus de questions. Ils peuvent aussi transformer chaque changement de permission en petit projet logiciel, avec des données auxquelles faire confiance, des règles à tester, des exceptions à expliquer et des erreurs qui surviennent lorsqu’une personne modifie une condition au pire moment. Utilisez un moteur de règles lorsque votre problème d’accès comporte réellement des responsabilités et des contraintes variables. N’en utilisez pas un comme décoration autour d’une simple limite d’approbation.

## Un moteur de règles transforme l’autorisation en maintenance logicielle

Un moteur de politiques est du code, même lorsque sa syntaxe n’en a pas l’air. Quelqu’un doit définir les faits disponibles, écrire les règles, décider de leur priorité, tester les changements, publier les versions, analyser les correspondances inattendues et retirer les règles qui ne correspondent plus à l’organisation.

Ce travail peut être justifié. Une entreprise peut avoir besoin que différents propriétaires de ressources définissent des conditions d’accès, limitent les actions selon la région ou l’environnement, ou appliquent des exigences légales et contractuelles. Dans ces situations, un petit ensemble de contrôles fixes peut contraindre des cas sans rapport à entrer dans une même approbation trop générale. L’erreur consiste à considérer cette complexité comme gratuite parce qu’un langage de politiques la dissimule derrière une syntaxe déclarative.

Prenons une règle familière :

```text
allow if
  agent.project == "payments"
  and request.host ends_with ".internal.example"
  and request.method in ["GET", "POST"]
  and time.weekday in ["Mon", "Tue", "Wed", "Thu", "Fri"]
```

Elle semble raisonnable jusqu’à ce qu’il faille répondre aux questions opérationnelles. Qui attribue `agent.project` ? L’agent peut-il l’influencer ? `ends_with` accepte-t-il `not-internal.example` ? Que permet POST sur un point de terminaison qui peut créer, rembourser, supprimer ou déclencher un transfert ? Que se passe-t-il pendant un incident le samedi ? Un refus ultérieur remplace-t-il une autorisation précédente ?

Chaque question ajoute une sémantique. Chaque élément sémantique nécessite un test. Chaque exception devient une partie du modèle d’autorisation, même si elle reste dans un message de discussion rédigé à la hâte et est copiée dans une règle une semaine plus tard.

La documentation d’Open Policy Agent décrit à juste titre les politiques comme du code et recommande de les tester. Ce n’est pas un slogan marketing en faveur de la souplesse. C’est la reconnaissance d’un contrat opérationnel : si une politique contrôle un accès important, l’équipe doit traiter ses modifications comme des changements de code. Les réviseurs ont besoin de cas de test. L’intégration continue doit vérifier les décisions attendues. Une personne d’astreinte doit pouvoir savoir quelle version de la politique a autorisé une requête.

Beaucoup d’équipes ignorent ce contrat. Elles copient quelques règles dans un fichier de configuration, puis découvrent six mois plus tard que personne ne sait si un refus vient d’une faute de frappe, d’une donnée manquante ou d’une limite volontaire. Un agent IA rend cet échec plus visible, car il génère des suites d’appels inhabituelles et peut parcourir une branche oubliée bien plus vite qu’un opérateur humain.

Les contrôles fixes réduisent la surface de maintenance en refusant d’exprimer des conditions arbitraires. Cela semble limitatif parce que c’est effectivement limitatif. La bonne question est de savoir si cette limite exclut une exigence réelle ou seulement une règle future que quelqu’un voudra peut-être ajouter un jour.

## La clarté des décisions compte lorsqu’un appel a des conséquences

Un opérateur doit pouvoir expliquer en une phrase pourquoi un appel a été autorisé. Si la réponse exige de lire un ensemble de règles, de résoudre les priorités et d’examiner les attributs fournis par l’agent, l’opérateur ne peut pas approuver ou révoquer l’accès de manière fiable pendant un incident.

La clarté des décisions évite aussi une erreur de catégorie discrète : une règle peut rendre une action techniquement permise sans la rendre compréhensible pour la personne qui en assume les conséquences. Une invite indiquant qu’un processus anonyme a demandé l’accès à une capacité générique ne donne presque rien à évaluer à l’opérateur. C’est une formalité, pas une approbation.

Un écran d’autorisation utile répond à des questions concrètes :

- Quel exécutable a demandé l’action et qui l’a signé ?
- S’agit-il d’un nouveau processus ou d’un processus déjà approuvé pour cette session ?
- Quel identifiant l’action utilisera-t-elle ?
- Où la requête sera-t-elle envoyée, ou quel hôte SSH contactera-t-il ?
- La personne approuve-t-elle une exécution ou une utilisation sensible ?

Le premier point mérite davantage d’attention qu’il n’en reçoit habituellement. Les noms d’agents sont des étiquettes. L’identité du processus est une preuve. Un processus peut s’appeler `release-agent`, tandis qu’une autorité de signature du code ou un chemin d’exécutable donne au réviseur un élément qui résiste au simple changement de nom d’un script shell. Les éléments d’identité ne prouvent pas que chaque instruction est sûre, mais ils ramènent la question à un principal réel.

La publication spéciale 800-207 du NIST présente le zero trust autour de la vérification explicite et de l’évaluation continue, plutôt que de la confiance héritée du réseau. Pour les actions d’agents locaux, la leçon pratique est plus simple que ne le suggèrent de nombreuses implémentations : évaluez l’acteur et la requête au moment de l’action. N’accordez pas un jeton à un agent en espérant que la limite restera pertinente après que le jeton aura quitté votre contrôle.

La clarté des décisions est aussi une propriété de sécurité. Lorsque les utilisateurs peuvent prévoir une approbation, ils peuvent repérer une approbation inattendue. Si un agent de programmation qui lit habituellement des données de tickets demande soudainement à utiliser un identifiant d’écriture en production, la différence doit être évidente avant que l’appel ne quitte la machine.

## L’identité, l’autorité et l’utilisation des secrets sont des questions différentes

Les équipes réunissent souvent trois questions distinctes dans une seule déclaration de politique, puis ne savent plus quelle hypothèse a échoué. Gardez-les séparées.

L’identité demande qui a effectué la requête. Pour un agent local, cela peut inclure le processus, son autorité de signature du code, son processus parent et sa durée de vie. Une étiquette lisible peut aider, mais elle ne doit pas porter seule la décision de sécurité.

L’autorité demande si le processus identifié peut effectuer des actions pendant cette exécution. Une approbation de session répond à cette question. Elle indique qu’une personne a examiné un nouveau processus et l’a autorisé à utiliser une passerelle d’actions définie jusqu’à sa fin ou jusqu’à la révocation par l’opérateur.

L’utilisation d’un secret demande si la clé API ou SSH concernée peut être utilisée pour cette action. C’est ici que se placent le verrouillage du coffre et l’approbation par identifiant. Un coffre verrouillé doit refuser toute action, quelle que soit une décision de session antérieure. Un identifiant particulièrement sensible peut exiger une approbation humaine à chaque utilisation, même lorsque le processus dispose déjà de l’autorité de session.

Confondre ces questions entraîne des erreurs prévisibles. Une équipe approuve une fois un processus d’agent, puis considère cette approbation comme une permission d’utiliser tous les identifiants. Ou elle déverrouille un coffre et confond disponibilité et autorisation. Ou elle écrit une politique qui vérifie le nom du processus et l’hôte cible, tout en laissant l’agent récupérer le jeton et le réutiliser ailleurs.

Ce dernier échec est le plus important. Si un agent détient des identifiants en clair, votre politique n’a vérifié que la première utilisation. L’agent peut transmettre la valeur à un sous-processus, l’inclure dans un journal, l’envoyer à un autre service ou l’utiliser après l’expiration de l’approbation initiale. Une passerelle qui garde les secrets hors de l’agent modifie la limite : l’agent demande une action et la passerelle effectue elle-même l’action authentifiée.

Cette distinction est plus nette que le simple « masquage des secrets ». Masquer une sortie après que le jeton a atteint l’agent ne retire pas le jeton de sa mémoire, de l’historique de ses invites, de son environnement shell ou de ses processus enfants. Empêcher la remise du secret à l’agent supprime toute une catégorie de réutilisations accidentelles.

## Trois contrôles explicites couvrent le cas courant des agents

Un petit ensemble de contrôles fonctionne lorsque chacun prend en charge une décision et qu’aucun ne prétend résoudre les autres. Pour les agents locaux de développeurs, trois contrôles couvrent une grande part du risque réel sans créer de langage de politiques.

Premièrement, utilisez une barrière de coffre absolue. Tant que le coffre est verrouillé, toute action échoue. Cela donne à l’opérateur une condition d’arrêt physique et conceptuelle. Elle ne doit pas dépendre d’une évaluation de règle, d’une session mémorisée ou d’une vérification réseau. Sur Mac, le déverrouillage protégé par le matériel via Secure Enclave et Touch ID peut rendre cette décision particulièrement claire : l’opérateur a ouvert le coffre ou ne l’a pas fait.

Deuxièmement, autorisez un nouveau processus d’agent pendant toute sa durée de vie. L’approbation doit identifier le processus d’une manière qui résiste à un simple changement de nom, puis expirer lorsque le processus se termine. Ce contrôle évite une invite pour chaque demande anodine sans rendre l’approbation permanente par défaut.

Troisièmement, marquez certains identifiants pour une approbation à chaque utilisation. Faites-le avec mesure et intention. Un identifiant de déploiement capable de modifier l’infrastructure de production, une identité SSH ayant un accès étendu aux hôtes ou un jeton permettant de déplacer de l’argent peut justifier une décision immédiate à chaque appel. Un jeton de développement en lecture seule utilisé fréquemment par un agent ne le justifie généralement pas.

La séquence de décision obtenue est facile à comprendre :

```text
if vault is locked:
    deny action
else if this agent process has no current session approval:
    ask for session approval
else if the selected credential requires approval per use:
    ask for credential approval
else:
    execute the action
```

Ce n’est pas un substitut au moindre privilège. L’identifiant doit conserver une portée limitée, et le chemin de la requête doit toujours bénéficier de la sécurité du transport et de la validation de la cible. La séquence rend explicite le point de contrôle humain. Elle ne transforme pas un identifiant d’administrateur en identifiant sûr.

L’ordre compte. Une demande par appel ne doit jamais contourner un coffre verrouillé. Une session mémorisée ne doit jamais contourner une décision d’identifiant à chaque utilisation. Avec un moteur de règles général, ces relations de priorité résident souvent dans des politiques différentes et deviennent étonnamment difficiles à auditer. Avec une séquence fixe, l’ordre constitue le modèle.

## Un moteur de politiques mérite son coût lorsque les responsabilités varient

Un moteur de politiques est justifié lorsque la décision d’autorisation doit varier entre de nombreuses ressources gérées indépendamment et que cette variation ne peut pas être représentée par le choix de l’identifiant ou par un petit ensemble de catégories d’approbation.

Supposons qu’un service d’automatisation partagé gère plusieurs unités métier. Chaque unité possède des dépôts, des comptes cloud et des magasins de données différents. Les propriétaires doivent accorder un accès temporaire à des groupes définis, imposer différentes conditions de conservation et auditer les décisions dans le cadre d’une gouvernance centrale. Une couche de politiques peut être le bon choix, car l’organisation a besoin d’une gestion déléguée des règles et d’une application uniforme à grande échelle.

Un autre cas pertinent est celui d’un service côté serveur qui reçoit des requêtes de nombreux clients non fiables. Le service peut devoir évaluer le locataire, le rôle, la propriété de l’objet, l’origine de la requête et l’état de la transaction avant d’agir. Une approbation de session locale fixe ne peut pas remplacer cela. Le serveur doit prendre une décision pour chaque requête, même lorsqu’aucun humain n’est disponible à proximité pour approuver.

Ne transformez pas ces cas en raison d’installer un moteur de politiques devant chaque agent local de programmation. Sur une machine de développeur, la question est généralement plus limitée : ce processus d’agent signé peut-il utiliser cet identifiant stocké via cette passerelle d’actions pendant que l’opérateur l’autorise ? L’humain dispose déjà du contexte local. Ajouter des conditions sur les créneaux horaires, les étiquettes de projet et des scores de risque hypothétiques peut créer davantage de fausse confiance que de contrôle.

Il existe une autre limite stricte. Une politique ne peut pas réparer un identifiant trop étendu. Une règle peut autoriser uniquement les requêtes vers un hôte, mais si l’agent peut extraire le jeton porteur, l’émetteur du jeton doit appliquer sa propre portée. Gardez le secret dans la passerelle et limitez-le chez le fournisseur. Considérez l’autorisation de la passerelle comme une couche, pas comme un remplacement du contrôle d’accès côté ressource.

## La lassitude face aux approbations indique que la portée est mauvaise

Les demandes répétées rendent les utilisateurs plus rapides, pas plus attentifs. Si une personne voit vingt fois la même carte d’approbation pendant qu’un agent récupère les métadonnées d’un dépôt, elle comprend que cliquer permet au travail de continuer. La onzième demande, pourtant différente sur un point important, reçoit alors le même clic réflexe.

La réponse courante consiste à créer des règles plus intelligentes qui suppriment les demandes dans des conditions toujours plus précises. Cela remplace souvent une lassitude visible par une complexité invisible. Quelqu’un ajoute une exception pour les appels de lecture, puis découvre qu’un point de terminaison apparemment en lecture déclenche un calcul distant ou expose des données qui auraient dû être examinées. Le nombre d’approbations diminue alors que la décision devient plus difficile à inspecter.

Définissez la portée de l’approbation selon le jugement humain requis. Une approbation de session signifie : « Je reconnais ce processus et je l’autorise à travailler avec les identifiants ordinaires affectés à cette exécution. » Une approbation par appel signifie : « L’utilisation de cet identifiant a suffisamment de conséquences pour que je l’examine individuellement. » Aucune des deux demandes ne doit exister simplement parce qu’une implémentation veut afficher une boîte de confirmation.

Une bonne conception des identifiants facilite les choses. Séparez les identifiants selon leurs conséquences au lieu de conserver un jeton puissant et d’espérer qu’une politique filtre chaque appel. Donnez à l’agent un jeton limité pour le développement normal. Gardez séparé le jeton qui modifie la production et exigez une décision explicite lorsqu’il est utilisé. Cela peut créer davantage d’identifiants, mais élimine l’analyse fragile des requêtes de la limite d’autorisation.

Une recommandation rejetée mérite une réponse directe : « Exiger une approbation pour chaque action de l’agent » semble sûr parce que cela crée un relevé complet des clics humains. C’est généralement une mauvaise idée pour les appels répétés et peu importants. Les utilisateurs ne peuvent pas examiner correctement un flot de demandes similaires. Exigez une approbation là où le réviseur peut porter un jugement distinct et journalisez le reste afin que l’équipe puisse enquêter sur le comportement réel.

## Une règle inoffensive peut autoriser une demande dangereuse

Un échec courant commence par une équipe qui souhaite permettre à un agent de mettre à jour un service de préproduction. Elle configure une règle autorisant les requêtes POST vers `api.example.internal` lorsque l’agent indique le projet `staging`. L’agent reçoit un jeton dans son environnement, car la passerelle ne peut pas l’injecter directement.

Pendant une tâche de débogage, l’agent suit une commande copiée qui utilise le même nom d’hôte, mais un point de terminaison d’administration. Celui-ci accepte POST et prend en charge une opération qui déploie une configuration en production. La politique voit une méthode autorisée, un hôte autorisé et une étiquette de projet autorisée. Elle renvoie « autoriser ».

L’équipe peut parler d’un bug de politique, mais plusieurs problèmes se combinent :

1. La méthode était trop générale pour décrire l’intention.
2. L’attribut de projet contrôlé par l’agent n’établissait pas la responsabilité.
3. L’hôte contenait des points de terminaison aux conséquences très différentes.
4. Le jeton existait hors du point d’application et pouvait être réutilisé après la requête.
5. L’opérateur n’a jamais vu de décision distinguant les mises à jour de préproduction d’un déploiement en production.

Ajouter des motifs de routes peut fermer cette faille précise. Puis quelqu’un ajoute un chemin versionné, un autre nom d’hôte, un point de terminaison par lots ou un paramètre de requête qui change le comportement. La politique grossit parce que l’identifiant sous-jacent fait trop de choses.

Une meilleure conception sépare les identifiants de préproduction et de production. La session normale peut utiliser l’identifiant de préproduction via la passerelle. L’identifiant de production exige une approbation à chaque utilisation, et cette approbation indique la cible et l’action. La passerelle injecte l’identifiant et renvoie le résultat, tandis que l’agent n’en reçoit jamais la valeur.

Cette conception dépend toujours du fournisseur de l’API pour limiter correctement les deux identifiants. Elle n’empêche pas non plus un agent approuvé d’effectuer une mauvaise modification en préproduction. Elle garantit qu’un flux de préproduction ne peut pas hériter discrètement d’une autorité de production à cause d’une règle trop souple et d’un jeton réutilisable.

## Testez les chemins de refus avant que l’agent ne le fasse à votre place

Les tests d’autorisation doivent prouver que le système refuse les actions dans les conditions attendues, pas seulement qu’une requête normale réussit. Les scénarios utiles sont assez petits pour être exécutés avant de modifier les identifiants ou les intégrations d’agents.

Pour une séquence de décision fixe, écrivez les résultats attendus dans un tableau et gardez-le à côté de l’implémentation :

| État du coffre | Approbation de session | Paramètre de l’identifiant | Résultat attendu |
| --- | --- | --- | --- |
| verrouillé | présente | ordinaire | refus |
| déverrouillé | absente | ordinaire | demander une approbation de session |
| déverrouillé | présente | ordinaire | exécuter |
| déverrouillé | présente | par appel | demander une approbation de l’identifiant |
| déverrouillé | révoquée | ordinaire | refuser ou demander une nouvelle approbation de session |

Ce tableau détecte une catégorie sérieuse de régressions : un ingénieur ajoute un chemin pratique qui vérifie l’autorité de session avant l’état du coffre ou permet à un processus mémorisé d’ignorer une décision d’identifiant à chaque utilisation. Le tableau rend l’ordre prévu vérifiable sans devoir apprendre un langage de politiques.

Pour un moteur de politiques, testez plus que les exemples qui devraient être autorisés. Testez les attributs manquants, les URL mal formées, les noms d’hôte alternatifs, les changements de version des politiques, les conflits de règles, les changements d’horloge et les refus explicites. Le modèle de test d’Open Policy Agent prend en charge les tests de règles, mais le travail difficile reste le vôtre : choisir les données qu’un attaquant, un agent défectueux ou une future intégration peut influencer.

Testez aussi la révocation pendant qu’un agent est actif. Démarrez une session, approuvez-la, effectuez une action ordinaire, révoquez l’accès, puis répétez la même requête. La seconde tentative doit produire un refus à la passerelle d’actions. Une révocation qui ne modifie qu’un enregistrement dans un tableau de bord tout en laissant un processus détenir un identifiant utilisable n’a pas révoqué l’autorité effective.

Pour HTTP, inspectez le résultat renvoyé afin d’obtenir assez de contexte pour diagnostiquer l’échec sans exposer les en-têtes d’autorisation. Pour SSH, vérifiez que l’assistant utilise l’identité sélectionnée pour se connecter, sans transmettre le contenu de la clé privée à l’agent appelant. Ces détails semblent ordinaires jusqu’à ce qu’un incident oblige une équipe à établir ce que le processus possédait réellement.

## Un journal d’audit doit répondre à une question différente de celle d’une demande

Les contrôles d’approbation empêchent ou autorisent une action sur le moment. Un journal d’audit indique ensuite ce qui s’est passé, qui l’a approuvé et si quelqu’un a modifié l’enregistrement. Ne réunissez pas ces fonctions dans une vague fonctionnalité de « responsabilité ».

Un enregistrement utile contient l’identité de la session, la décision prise, la référence de l’identifiant plutôt que sa valeur secrète, le type d’action, la cible, le résultat et les informations d’ordre. Il doit aussi enregistrer la révocation de la session. Sans ce lien, les enquêteurs voient une requête, mais ne peuvent pas savoir si elle a eu lieu avant ou après le retrait de l’approbation par un opérateur.

La détection des altérations exige une formulation précise. Une chaîne de hachage peut rendre détectables les modifications ou suppressions ultérieures lorsqu’un vérificateur dispose des données de chaîne attendues. Elle ne peut pas prouver qu’un système compromis a enregistré chaque événement au départ. Elle ne peut pas non plus décider si une approbation était judicieuse. Le journal fournit des preuves sur l’historique enregistré, pas une machine à remonter le temps.

Pour une passerelle locale, un journal d’audit chiffré et aveugle à l’écriture offre une séparation utile : le composant qui exécute les actions enregistre les événements, tandis que les lecteurs habituels consultent des journaux projetés au lieu de réécrire l’historique. La vérification hors ligne est particulièrement utile, car elle n’exige ni service disponible ni clé de déchiffrement pour vérifier simplement la structure de la chaîne.

Sallyport enregistre les exécutions d’agents dans un journal Sessions et les actions individuelles dans un journal Activity, tous deux projetés à partir d’un journal d’audit chiffré et chaîné par hachage. Sa commande `sp audit verify` vérifie la chaîne hors ligne sur le texte chiffré, ce qui convient à un journal susceptible d’être important après que la machine est devenue suspecte.

Gardez l’examen de l’audit pratique. Lorsqu’un agent vous surprend, identifiez d’abord le processus qui a reçu l’approbation de session, répertoriez les actions dans l’ordre chronologique, révoquez la session active et examinez les journaux du fournisseur concerné. Le journal local explique ce qui a traversé la passerelle ; le service de destination explique ce que le système distant a accepté.

## Choisissez le plus petit modèle de décision que vous pouvez exploiter

Commencez par le véritable chemin d’autorité, pas par un désir abstrait de souplesse. Listez les identifiants dont l’agent a besoin, identifiez ceux dont les conséquences justifient une nouvelle approbation et décidez comment une personne peut révoquer un processus actif. Si cela produit trois décisions stables, gardez-les explicites.

Adoptez un moteur de politiques lorsque l’organisation a besoin d’une gestion des règles et d’une variation qu’une séparation des identifiants, combinée à une approbation de session et par appel, ne peut pas exprimer. Acceptez alors l’obligation qui en découle : versionner les politiques, tester les données adverses, documenter les priorités, désigner des propriétaires et examiner les exceptions avec autant de soin que le code.

Le mauvais modèle n’est ni celui des « règles » ni celui des « demandes ». Le mauvais modèle est une limite d’autorisation que personne ne peut expliquer pendant qu’un agent attend d’agir. Si votre équipe ne peut pas dire pourquoi une requête est autorisée, réduisez le modèle de décision avant de chercher à le rendre plus intelligent.