Le zero trust a gagné l’argument. Plus personne ne défend le périmètre implicite, et les organisations qui ont fait le travail vérifient réellement chaque utilisateur, chaque appareil et chaque requête.
Puis un agent est déployé, et il reçoit un compte de service.
L’écart d’attribution
L’OWASP le classe sous ASI03, abus d’identité et de privilèges. Le terme est utile parce qu’il nomme la conséquence plutôt que la cause.
Le test se fait avec une seule question, posée après un incident : qui a fait ça ?
Reconstituez la chaîne réelle. Un agent a exécuté une action. Il l’a fait pour le compte d’une personne, qui a formulé une demande. Il s’est authentifié auprès du système cible avec un principal de service. Il est passé par un outil, lequel avait ses propres droits, souvent plus larges que ceux du demandeur.
Quatre éléments. Dans la plupart des déploiements, le journal du système cible en contient un : le principal de service.
Il ne dit pas quel agent, parce que trois agents partagent le même. Il ne dit pas pour le compte de qui, parce que la délégation n’a pas été transmise. Il ne dit pas quel outil, parce que l’appel est arrivé comme n’importe quel autre appel d’API.
Ce n’est pas un défaut de journalisation qu’on corrige en journalisant davantage. C’est ce qui arrive quand une identité partagée est utilisée par quelque chose qui prend des décisions.
Pourquoi le compte de service partagé est le défaut
Il vaut la peine de comprendre pourquoi c’est arrivé, parce que ça n’a rien d’irrationnel.
Un agent est déployé comme un logiciel : il lui faut des credentials pour appeler des systèmes, et le modèle disponible pour du logiciel qui appelle des systèmes est le compte de service. C’est ce que les équipes font depuis vingt ans avec les tâches planifiées et les intégrations.
La différence est que ces composants faisaient une chose précise, de manière déterministe. Un agent choisit ce qu’il fait, en fonction de ce qu’il lit — y compris de contenu qui vient de l’extérieur.
Le compte de service n’a pas été conçu pour porter cette propriété-là.
Les quatre mouvements
1. Une identité par agent
Pas un compte de service partagé, pas le jeton personnel de quelqu’un.
Trois propriétés en dépendent, et elles tombent ensemble. Révoquer un agent sans casser les autres. Limiter son débit indépendamment. L’auditer séparément.
Le test de vérification est direct : demandez sous quelle identité l’agent s’authentifie, et si la révoquer casserait autre chose. Si la réponse est oui, vous n’avez pas d’identité d’agent — vous avez un secret partagé qui se trouve être utilisé par un agent.
2. Des credentials à portée limitée et de courte durée
Le défaut de la plupart des cadres agentiques est de donner à l’agent l’accès à tous les outils connectés, pour la durée complète de la session. C’est large par conception, parce que c’est ce qui rend l’outil agréable à utiliser en démonstration.
La portée devrait suivre la tâche, pas la session. Un agent qui traite un billet de support n’a pas besoin, pendant qu’il le traite, de l’outil qui envoie des courriels externes ni de celui qui écrit dans le dépôt.
Sur la durée : des jetons de courte durée plutôt que des clés durables, et une identité de charge de travail plutôt qu’un secret statique dans une variable d’environnement. C’est exactement le contrôle qui aurait limité les vagues de compromission de paquets npm, et c’est le même ici pour la même raison — ce qui est récoltable finit par être récolté.
3. Une approbation humaine sur les actions irréversibles
La liste doit rester courte pour rester crédible. Quatre catégories couvrent presque tout : ce qui touche la production, ce qui détruit ou exfiltre des données, ce qui déplace de l’argent, ce qui publie vers l’extérieur.
L’erreur symétrique mérite d’être nommée. Une approbation humaine devant tout produit une file d’attente, et une file d’attente produit du contournement. Une barrière systématiquement contournée est pire qu’une barrière absente, parce qu’elle donne une assurance qui n’existe pas.
Et la vérification porte sur le flux de travail, pas sur la politique : l’approbation existe-t-elle dans le système qui exécute, ou seulement dans le document qui décrit ce qui devrait se passer.
4. Une ligne de journal qui nomme trois choses
L’agent. La personne pour le compte de qui il agit. L’outil utilisé.
Sur la même ligne, parce que la corrélation après coup entre trois systèmes de journalisation est le genre de travail qui prend une semaine quand il en reste trois jours.
C’est le seul des quatre contrôles qui ne peut pas être ajouté rétroactivement. Les trois autres se mettent en place n’importe quand. Un journal que vous n’avez pas activé en mars ne vous dira rien sur mars.
Ce qui ne change pas
Aucun des quatre mouvements n’est nouveau. Ce sont l’identité, le moindre privilège, la séparation des tâches et la journalisation — les contrôles que vous avez déjà, appliqués à un principal qui n’est pas une personne et qui n’est pas non plus un script.
C’est la raison pour laquelle personne n’a besoin de bâtir une équipe de sécurité IA pour commencer. Chacun de ces contrôles a déjà un propriétaire dans votre organisation.
Ce qui manque n’est pas la compétence. C’est que personne n’a encore posé la question à voix haute.
Pouvez-vous répondre à « qui a fait ça » quand c’est un agent ?
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.