Identity and Permissions for an AI Agent

Un agent n’est pas un utilisateur. C’est un programme qui agit au nom de quelqu’un, avec des outils. Sans identité, il hérite du droit le plus large de la pièce : la clé API partagée, le compte de service admin, la boîte mail de l’équipe.

Le prompt injection devient grave à ce moment-là. Un document malveillant ne vole pas un mot de passe. Il demande à l’agent d’utiliser un outil qu’il n’aurait jamais dû avoir. La défense n’est pas une phrase de plus dans le prompt. C’est un droit qu’on n’a pas accordé.

Trois séparations

Qui parle

L’humain qui a lancé la tâche a une identité. L’agent en a une autre, de service, étroite, journalisée. On ne fait pas agir l’agent avec la session de l’utilisateur « pour aller plus vite ». On trace les deux.

Ce qu’il peut toucher

Chaque outil a un périmètre : lire tel référentiel, écrire dans telle file, jamais envoyer, jamais supprimer. Le défaut est le refus. Une capacité nouvelle est une décision, pas un import de SDK.

Jusqu’où il va seul

Lire et proposer est large. Écrire dans un système d’enregistrement est étroit et souvent soumis à une validation. Payer, effacer, écrire à un client : un humain confirme. Le niveau suit le risque du geste, pas l’élégance de la démo.

Journaliser chaque geste

L’identité sans journal ne sert à rien. Chaque appel d’outil garde qui, quoi, sur quelle donnée, avec quel résultat. C’est ce qui permet de rejouer un incident et de retirer un droit sans éteindre l’agent.

Le test est simple. Si demain l’agent lit un document qui lui dit d’exfiltrer un fichier, que peut-il réellement faire ? Si la réponse est « tout ce que la clé permet », il n’y a pas d’architecture. Il y a un compte partagé.

Position YOWE

L’autonomie se borne par les permissions, pas par le prompt. On nomme l’agent, on lui donne le minimum, et on journalise chaque geste.