Gouverner un agent IA comme un utilisateur du système

Brancher un agent sur le système d'information, ce n'est pas poser une couche magique au-dessus de l'existant. C'est ajouter un utilisateur de plus — et la vraie question n'est pas ce que le modèle sait faire, mais avec quels droits il agit.

Un agent qui « comprend » le métier et « décide » seul donne l'illusion d'une intelligence flottant au-dessus du SI. C'est une fiction dangereuse. Dans les faits, un agent émet des appels, lit et écrit des données, déclenche des effets : il consomme le système comme n'importe quel utilisateur. Le concevoir autrement, c'est lui accorder un privilège diffus que personne ne maîtrise.

Le prompt n'est pas une frontière

La tentation est de cadrer l'agent par son prompt : « tu ne dois pas supprimer de données », « limite-toi à tel périmètre ». Mais un prompt est une consigne, pas une barrière. Il se contourne par une formulation habile, par une injection indirecte dans une donnée qu'on lui fait lire, ou par une simple dérive du modèle. Une frontière d'architecture est ce que l'agent ne peut pas franchir, pas ce qu'on lui demande de ne pas franchir.

Cette frontière, c'est l'interface et les droits. Un agent ne peut appeler que les capacités qu'on lui expose, et n'obtient que ce que ses droits autorisent. Le reste — les bonnes manières dictées par le prompt — relève du confort, pas de la sécurité.

Ce risque porte un nom en sécurité : le député confus — un acteur légitime, doté de droits, qu'un tiers manipule pour s'en servir à son insu. Un agent y est exposé comme aucun composant classique, parce que son comportement est piloté par du langage naturel : il suffit de glisser une instruction dans une donnée qu'il lit (injection indirecte) pour la lui faire exécuter. Simon Willison a nommé la configuration la plus dangereuse la « trifecta létale » : un agent qui cumule l'accès à des données privées, l'exposition à du contenu non fiable et la capacité de communiquer vers l'extérieur peut être retourné en outil d'exfiltration par un seul message piégé. Aucun prompt ne referme cette porte ; seuls des droits le font.

Un acteur gouverné, pas une entité mystérieuse

Traiter l'agent comme un utilisateur du SI a des conséquences concrètes. Il agit dans un périmètre défini ; il passe par des interfaces explicites ; il laisse des traces ; ses droits, ses outils et ses effets se gouvernent et s'auditent. On ne lui confie pas « la cave et l'argenterie » au prétexte qu'il est intelligent : on lui remet un trousseau précis, et l'on sait à tout instant ce qu'il a ouvert.

La bonne question de conception n'est donc pas « que sait faire le modèle ? » mais : quel rôle joue-t-il dans le processus, de quelles interfaces dispose-t-il, quels invariants ne doit-il pas violer, quelles traces laisse-t-il, et comment le retirer sans refondre le système.

BYOK : l'agent n'a aucun droit propre

Reste la question décisive : avec quels droits ? Le réflexe courant est une clé d'API « applicative » unique, ou un compte de service dédié à l'agent. À éviter : cela crée une identité de confiance autonome et opaque, qui dilue la responsabilité et élargit la surface d'attaque. Si l'agent possède ses propres droits, un détournement du modèle est un détournement de ses droits.

Le danger qu'on écarte ainsi a, lui aussi, un nom : la prolifération des identités non-humaines. Donnez à un agent son propre compte et il finit par cumuler les accès — cloud, messagerie, dépôt de code, dizaines de services — et présente un rayon d'explosion qu'aucun compte de service n'a jamais été conçu pour porter. Un agent sans identité propre, qui n'emprunte que celle de son utilisateur, n'accumule rien : son périmètre est exactement celui d'un humain identifié, ni plus, ni moins.

Le modèle inverse est plus sûr — le BYOK (bring your own key) et l'héritage des droits. Chaque utilisateur configure ses propres autorisations et identifiants : clés, délégations OAuth2, accès aux services tiers. L'agent — et tout composant qu'il crée à la volée — hérite des droits de l'utilisateur appelant, partout dans la chaîne, et n'a aucun privilège en propre. C'est un principe de zero-trust appliqué à l'agent : il n'est jamais une identité de confiance en soi ; il n'agit que sous l'autorité d'un humain, dans le périmètre que cet humain détient déjà.

Le BYOK n'est pas qu'une garantie de sécurité, c'est aussi un choix économique et de capacité. Comme chaque utilisateur apporte ses propres clés de modèle, le coût d'inférence est porté et maîtrisé par lui : la plateforme ne supporte aucune facture mutualisée, et l'usage de chacun reste sous son propre contrôle. Et chaque utilisateur accède aux modèles et fournisseurs que ses clés autorisent — un compte qui dispose d'un modèle particulier l'emploie, sans être ramené au plus petit dénominateur commun d'un modèle imposé par la plateforme.

La traçabilité tombe alors d'elle-même

La conséquence est précieuse : tout effet — un appel d'API, une écriture, une dépense — remonte jusqu'à un utilisateur identifié, jamais à un « compte agent » anonyme derrière lequel chacun se cache. L'audit retrouve toujours un responsable humain. Et l'invariant de sécurité devient limpide : un agent ne peut, par construction, rien faire que son utilisateur appelant ne pourrait faire lui-même. On ne raisonne plus sur les intentions du modèle, mais sur des droits.

Chaque outil sous les clés de son utilisateur

Ce modèle a un corollaire concret. Un outil qui consomme un service tiers résout les identifiants de l'utilisateur appelant — portés par leur emplacement, propriétaire et fournisseur — et non une configuration partagée par la plateforme. Le même outil sert chaque utilisateur sous ses propres clés, et n'expose jamais celles d'un autre. La sécurité ne tient pas à un secret applicatif partagé : elle découle de l'identité de l'appelant.

L'agent est cadré comme un utilisateur, ses droits sont ceux d'un humain identifiable. Reste à lui donner ses moyens d'action : par quelles interfaces agit-il ? La réponse courante — une bibliothèque d'outils sur mesure — est, elle aussi, une fausse bonne idée.