Imaginez un agent IA capable d’enquêter sur un incident de production et de réinitialiser un compte compromis. Une identité de charge de travail distincte permet d’attribuer ses actions ; des identifiants à courte durée de vie et un accès limité restreignent sa portée. Aucun de ces contrôles ne détermine s’il peut réinitialiser ce compte à cet instant.
Une réinitialisation valide peut exiger un incident actif qui nomme le compte, des preuves conformes à la politique et l’approbation du responsable de l’incident. Sans ces conditions, un agent parfaitement authentifié peut tout de même effectuer une modification non autorisée à deux heures du matin.
L’identité établit qui agit. L’autorité définit ce que cet acteur peut recommander, approuver, exécuter, déléguer ou arrêter dans les conditions propres à l’incident. Une revue de production doit traiter les deux.
Le National Cybersecurity Center of Excellence du NIST a clos, le 2 avril 2026, la consultation publique sur un document de réflexion consacré à l’identité et à l’autorisation des agents logiciels et d’IA. Ce document examine l’application des pratiques d’identité existantes aux agents et aborde l’autorisation, l’audit, la non-répudiation et l’injection d’instructions comme des sujets liés mais distincts.
L’Identité Établit L’Acteur
Un agent de production ne doit pas emprunter les identifiants d’un développeur, partager un compte avec des automatisations sans rapport ni hériter de toutes les permissions de l’application hôte. Donnez-lui une identité non humaine distincte, associée à un seul rôle opérationnel. L’organisation peut alors émettre et renouveler les identifiants, attribuer des permissions de base, journaliser les requêtes et révoquer l’accès.
L’authentification prouve seulement l’origine d’une requête. Elle ne prouve pas que les preuves actuelles justifient la réinitialisation d’un compte, que celui-ci appartient au périmètre de confinement ni que l’approbation requise existe. Le contrôle d’accès traditionnel demande si un principal peut appeler une API. Le flux doit aussi décider si cet appel est autorisé maintenant.
L’Autorité Réside Dans La Décision
Un rôle tel que security-assistant peut accorder un accès de base. Pour déterminer si une action particulière est autorisée dans les conditions présentes, le flux doit relier les preuves, la politique, l’autorité d’approbation, l’exécution, la reprise et les résultats observables. Evodant appelle l’ingénierie de ce chemin l’Ingénierie Décisionnelle.
Un ticket d’incident ne suffit pas lorsque les preuves sont périmées, que le compte se trouve hors du plan de confinement approuvé ou que sa réinitialisation interromprait un service métier. Exprimez l’autorité dans des termes que l’équipe de sécurité peut tester :
Cet agent peut réinitialiser le compte X pendant l’incident Y si les preuves requises sont actuelles, si l’action respecte le plan de confinement approuvé et si le responsable de l’incident a autorisé toute exception.
Une permission générique account-reset omet ces conditions opérationnelles.
Adapter L’Autorité Aux Conséquences
Le principe du moindre privilège s’applique au type d’autorité détenu par l’agent, pas seulement aux systèmes qu’il peut atteindre. Choisissez le niveau d’automatisation selon les conséquences de l’action :
| Niveau D’Autorité | Ce Que L’Agent Peut Faire | Contrôle Requis |
|---|---|---|
| Aide à la décision | Organiser les preuves et présenter les options | Une personne habilitée interprète les preuves et décide |
| Augmentation de la décision | Formuler une recommandation limitée | Une personne habilitée l’approuve, la modifie ou la rejette |
| Automatisation limitée | Exécuter une action définie et récupérable lorsque les conditions de politique sont remplies | La politique limite l’exécution ; un responsable nommé surveille les résultats et peut la suspendre |
L’automatisation limitée doit s’arrêter et transmettre la décision à une personne habilitée dès que les preuves, la politique ou l’autorité sortent du périmètre prévu. Conservez l’aide ou l’augmentation de la décision jusqu’à ce que des preuves opérationnelles représentatives justifient l’exécution.
Limiter Les Dommages Lorsque Le Modèle Échoue
Les agents peuvent lire des e-mails, des tickets, des documents, des sites web et des dépôts. Un attaquant peut placer des instructions dans ces contenus afin de détourner l’agent, une technique appelée détournement d’agent ou injection indirecte d’instructions.
Le 23 mars 2026, le NIST a publié une analyse d’une vaste compétition de red teaming consacrée aux agents IA. Plus de 400 participants ont mené plus de 250 000 tentatives d’attaque contre 13 modèles de pointe. Au moins une attaque a réussi contre chaque modèle ciblé, et certaines familles d’attaques se sont transférées entre modèles et scénarios.
La compétition a testé des modèles, pas des flux de production complets. Les défenses au niveau des instructions et les tests de modèles ne peuvent donc pas porter seuls toute la charge de sécurité. Le périmètre des outils, l’autorisation propre à chaque action, l’approbation éclairée, la surveillance et la révocation doivent limiter ce qui suit une mauvaise décision du modèle. De larges droits d’exécution peuvent convertir une faiblesse du modèle en modification de production.
Rendre La Délégation Et La Reprise Explicites
Un agent peut agir dans le cadre de son propre rôle opérationnel ou pour le compte d’une personne. Lorsqu’une personne délègue une tâche, liez cette autorité à un objectif, à des actions autorisées, à un périmètre de ressources et à une date d’expiration. L’agent ne doit ni hériter de toutes les permissions de l’utilisateur ni continuer à agir une fois le contexte métier expiré.
Si un agent demande à un autre de récupérer des preuves ou d’exécuter une étape, l’agent destinataire a besoin d’un contexte de délégation vérifiable. Celui-ci doit identifier le principal d’origine, l’action autorisée, le périmètre de ressources, l’expiration et le droit éventuel de déléguer à nouveau. Des identités valides à chaque transmission ne peuvent pas légitimer une action qui dépasse le périmètre initial.
Planifiez la révocation et la reprise avant le déploiement. Les opérateurs doivent pouvoir suspendre directement l’agent, supprimer une permission d’outil, invalider une délégation et arrêter un flux sans désactiver les services sans rapport. Pour chaque action exécutable, documentez comment ils détecteront l’échec, en contiendront les effets, l’annuleront si possible et reconstitueront la décision.
Exiger Un Dossier Consultable
Avant l’approbation en production, créez un dossier pour l’agent et son flux. Il doit répondre à cinq questions :
- Quel objectif opérationnel l’agent sert-il, et qui est responsable du résultat ?
- Quelle identité utilise-t-il, et comment les opérateurs peuvent-ils la révoquer ?
- À quelles preuves, quels outils, quelles ressources et quels environnements peut-il accéder ?
- Quelles décisions peut-il soutenir, et quelles actions peut-il recommander ou exécuter, selon quelle politique et quelles conditions d’approbation ?
- Comment les opérateurs arrêteront-ils l’exécution, assureront-ils la reprise et examineront-ils ce qui s’est passé ?
Reliez ce dossier à la version déployée du flux. Un changement de modèle, d’outil, de source de preuves, de permission ou de règle d’approbation peut modifier le périmètre de décision et doit déclencher une revue.
Commencez par une action à fort enjeu, puis testez les cas courants ainsi que les preuves périmées, les instructions hostiles, les délégations expirées et les approbations qui échouent. N’élargissez l’autorité que lorsque le comportement observé le justifie.
Vous définissez l’autorité d’un agent avant sa mise en production ? Planifiez une consultation.