Un agent capable de consulter des données, d’utiliser des outils ou de réaliser une transaction ne doit pas agir avec l’identité et tous les droits de son utilisateur. Le NIST propose dix principes pour encadrer précisément son identité, son mandat et ses autorisations.
Un agent IA peut réserver un voyage, interroger une base de données, modifier un dossier ou déclencher un paiement. Mais comment vérifier qu’il agit bien pour la bonne personne, dans les limites demandées et pendant la durée prévue ?
Le NIST apporte une première réponse structurée. L’organisme américain propose 10 principes de conception pour les systèmes chargés de gérer l’identité et les droits des agents IA. Ils ne constituent pas encore une norme, mais dessinent une architecture beaucoup plus solide que les simples consignes inscrites dans un prompt.
1. Donner une identité propre à chaque agent
Un agent ne doit pas emprunter le compte de son utilisateur. Il doit disposer d’une identité distincte, vérifiable cryptographiquement et rattachée à une version, un environnement et une configuration déterminés. Une action peut ainsi être attribuée à l’agent qui l’a réellement exécutée.
2. Conserver la chaîne de délégation
Le système doit pouvoir retrouver qui a lancé l’agent et pour quelle mission. Si celui-ci délègue une tâche à un autre agent, les droits transmis doivent être réduits, jamais étendus. Un sous-agent ne doit pas pouvoir obtenir davantage de pouvoirs que celui qui l’a mandaté.
3. Ne laisser aucun privilège permanent
Lorsqu’il ne travaille pas, l’agent ne doit conserver aucun droit d’accès. Pendant sa mission, il ne reçoit que les autorisations strictement nécessaires. Cette règle limite les dégâts possibles si l’agent est détourné ou compromis.
4. Utiliser des autorisations courtes et révocables
Les accès doivent être accordés au moment du besoin, pour une durée limitée et pour un service précis. Ils doivent pouvoir être suspendus immédiatement si le comportement de l’agent devient anormal. Les mots de passe permanents et les jetons réutilisables sont donc à proscrire.
5. Fixer les seuils de validation humaine
Une organisation doit déterminer les actions qui exigent une confirmation : paiement dépassant un montant donné, transmission de données sensibles ou modification irréversible, par exemple. L’intervention humaine doit rester ciblée afin d’éviter les validations automatiques par lassitude.
6. Formaliser le mandat
L’agent doit recevoir un mandat signé définissant le résultat attendu et ses limites : objet de la mission, montant maximal, destinataire, durée ou catégories de données accessibles. Ce document permet aux services utilisés de vérifier que l’action demandée correspond réellement à l’intention initiale.
7. Séparer le raisonnement de l’autorisation
C’est le principe central. Le modèle peut proposer une action, mais il ne doit jamais décider seul s’il a le droit de l’exécuter. Cette décision revient à un système de contrôle extérieur. Une instruction malveillante trouvée dans un courriel ou une page web ne peut donc pas élargir ses permissions.
8. Rendre les décisions d’accès déterministes
L’autorisation ne doit pas dépendre principalement d’une réponse probabiliste du modèle. Elle doit reposer sur des règles vérifiables : identité reconnue, mandat valide, plafond non dépassé et ressource autorisée. La politique de sécurité doit produire une décision prévisible.
9. Surveiller les actions en continu
Les agents travaillent plus vite et à une échelle supérieure aux utilisateurs humains. Leur activité doit donc être suivie avec des indicateurs adaptés : volume inhabituel de requêtes, changement soudain de comportement, utilisation d’un nouvel outil ou tentative répétée d’accéder à une ressource interdite.
10. Conserver des preuves inaltérables
Chaque action doit laisser une trace reliant l’identité de l’agent, le mandat reçu, l’autorisation accordée et l’opération exécutée. Ces journaux doivent être conservés en dehors de l’agent et ne pas pouvoir être modifiés par celui-ci.
Appliqués à un agent chargé d’acheter un billet, ces principes donnent un dispositif concret : une identité propre, un mandat limité à un trajet et à un budget, un accès valable quelques minutes, une validation humaine au-delà d’un plafond et un historique indépendant de chaque opération.
Le NIST reconnaît que les technologies actuelles ne permettent pas encore d’appliquer partout ces dix principes. Mais le fait de demander à un agent de « respecter les règles » ne constitue pas une mesure de sécurité. Les limites doivent, en effet, être imposées par l’architecture, en dehors du modèle.
