PAODO
Sécurité /

Les agents ont besoin d’internet, et c’est bien le problème

Un agent coupé du réseau ne peut pas faire grand-chose. Il ne peut ni appeler une interface, ni récupérer un document, ni installer la dépendance dont il a besoin. Mais si vous lui ouvrez internet sans restriction, il lira des contenus que n’importe qui peut écrire.

Une silhouette marche vers une porte marquée Internet, enlacée par des bras rouges porteurs d’instructions piégées, à côté d’une clé dorée sous une vitrine

L’injection de prompt n’a rien d’une attaque exotique. Normalement, les instructions d’un agent viennent de vous. Tout ce qu’il lit en chemin (pages web, documents, fichiers) n’est que du contexte. Le problème, c’est que l’agent ne fait pas toujours la différence : une consigne cachée dans une page web ou un document peut ressembler à une vraie instruction, et il risque de l’exécuter comme si elle venait de vous.

Trois conditions pour une attaque

Pour qu’une attaque réussisse, trois conditions doivent être réunies : l’agent a accès à quelque chose de précieux, comme vos secrets ; il lit des contenus écrits par quelqu’un d’autre ; et il peut envoyer des données vers l’extérieur. Simon Willison appelle cette combinaison la « lethal trifecta ». S’il manque une seule de ces conditions, l’attaquant ne peut rien voler. Si les trois sont réunies, une consigne cachée peut pousser l’agent à récupérer votre secret et à l’envoyer à l’attaquant. C’est ce qu’on appelle l’exfiltration, et c’est le but de l’attaque.

Le premier réflexe est de bloquer les sorties. C’est pourtant le plus difficile. Pour faire sortir une donnée, pas besoin d’un canal prévu pour ça : un appel d’API, une image téléchargée, un lien dans un rapport, tout ce qui quitte la machine peut emporter une clé avec lui. On peut bloquer toutes les sorties, mais c’est une solution lourde pour un agent autonome.

Empêcher l’agent de lire des contenus extérieurs n’est pas plus simple. Lire une page, ouvrir un document, reprendre un fichier laissé par un autre agent : c’est précisément son travail. Il reste donc une seule condition sur laquelle agir : ce que l’agent a entre les mains.

L’agent n’a pas besoin de la clé

On pourrait croire le contraire. Pour appeler le service, signer la requête et récupérer les données, l’agent doit bien avoir la clé.

En réalité, l’agent a besoin que la porte s’ouvre, pas d’avoir la clé en poche. Une secrétaire peut très bien réserver un vol d’avion sans jamais voir le numéro de la carte bancaire.

Nous avons donc arrêté de demander à l’agent de garder des secrets. Garder un secret demande du jugement, et c’est justement le jugement de l’agent que l’injection de prompt cherche à tromper.

La protection doit se trouver là où aucun texte ne peut l’atteindre. Même si l’agent se fait entièrement manipuler, il n’a rien de précieux à livrer. Le dévaliser ne rapporte rien.

Soyons clairs sur les limites de cette approche. Même sans détenir la clé, un agent qui agit en votre nom peut toujours être poussé à mal agir : dépenser, supprimer, envoyer. Chaque droit que vous lui avez accordé peut être détourné au profit de quelqu’un d’autre. C’est le problème du « confused deputy », et il est connu depuis longtemps.

En revanche, les secrets auxquels l’agent n’a jamais accès ne peuvent pas être exfiltrés. Si l’agent est détourné, les dégâts restent limités aux droits que vous lui avez accordés, vous les voyez au moment où ils se produisent, et vous pouvez couper l’accès dès que vous les remarquez. Un identifiant volé n’offre aucune de ces garanties : une fois sorti, il vous échappe.