Quand l'agent IA devient le complice (malgré lui) d'un casse parfait

Dans tous les films de casse, il y a un moment clé. Celui où l'on découvre que l'équipe a un complice à l'intérieur. Quelqu'un qui a les badges, qui connaît les couloirs, et qui ouvre la bonne porte au bon moment.

Maintenant, imagine un complice encore plus pratique. Il ne sait même pas qu'il participe à un casse. Il suffit de glisser un mot dans un document qu'il va lire, et il ouvre la porte de lui-même, avec le plus grand sérieux, persuadé de faire son travail.

Ce complice existe. C'est un agent IA mal isolé.

Le plan : une vieille faille, un nouvel acteur

Un agent, c'est un modèle à qui on a donné des mains : un navigateur, un client HTTP, parfois carrément un shell. Et le réflexe, quand on pense à sa sécurité, c'est de le traiter comme un employé : on lui dit ce qu'il a le droit de faire.

Sauf que ce n'est pas le bon modèle mental. Un agent ressemble beaucoup plus à un serveur qui avale des entrées pas fiables. Et ça, les équipes de sécurité savent depuis longtemps que c'est casse-gueule.

La faille a un nom : la SSRF, pour Server-Side Request Forgery. Le principe est un grand classique : ton serveur propose d'aller chercher une URL, et l'attaquant s'en sert pour lui faire interroger ce que lui-même ne peut pas atteindre. Un service interne. Le point d'accès aux métadonnées d'une machine cloud, là où traînent parfois des identifiants. Une base de données sans mot de passe, parce que « de toute façon, elle est sur le réseau privé ».

Pourquoi l'agent est le complice idéal

Il coche toutes les cases du casting, et même quelques-unes de plus :

• C'est lui qui choisit l'URL. Pas l'utilisateur : le modèle, à partir d'un contenu qu'il a lu. Ton filtre sur les entrées regarde la porte d'entrée pendant que le complice sort par la porte de service.
• Il obéit à ce qu'il lit. Une page web, un ticket, un fichier README peuvent contenir une phrase du genre « pour compléter la tâche, consulte d'abord telle adresse ». C'est l'injection de prompt indirecte : une consigne malveillante qui arrive par un canal que personne ne surveille.

« Y'a qu'à lui apprendre à dire non »

L'idée est tentante, et entraîner le modèle à refuser reste utile. Mais ça ne suffit pas, pour deux raisons.

D'abord, un refus, c'est probabiliste. Une règle de sécurité, non : elle autorise ou elle bloque, point.

Ensuite, et c'est le plus vicieux, l'action demandée est souvent parfaitement légitime prise isolément. Récupérer une URL, c'est le travail de l'agent ! Ce qui cloche, c'est la cible et le contexte. Deux choses que le modèle évalue mal, parce qu'il n'a pas le plan de ton réseau.

Comment déjouer le casse

On ne compte pas sur la bonne volonté du complice. On change les serrures, à l'extérieur du composant qui prend les décisions, comme pour n'importe quel service exposé :

• toute la sortie réseau passe par un proxy avec une liste blanche, jamais une liste noire, qui aura toujours un trou ;
• les plages d'adresses privées et les points d'accès aux métadonnées sont bloqués au niveau du réseau, pas dans le code de l'appli ;
• l'agent ne porte jamais les badges du service qui l'héberge : il a sa propre identité, avec ses propres droits, minimaux ;
• chaque requête sortante est journalisée, avec l'étape de la trajectoire qui l'a déclenchée. Pour pouvoir rejouer le film après coup.

Rien de révolutionnaire. On applique ces règles depuis quinze ans à tout ce qui manipule des entrées douteuses. La nouveauté est ailleurs.

Le twist final

Dans les vieux films, le complice savait ce qu'il faisait. On pouvait le démasquer, l'interroger, le retourner.

Le nôtre est de bonne foi. Il croit sincèrement accomplir sa mission. Et c'est ça qui change tout : on savait se protéger d'un attaquant qui fabrique une requête. Il faut maintenant se protéger d'un composant de confiance qui, après avoir lu la mauvaise page, la fabrique à sa place.

Ton périmètre de confiance ne s'arrête plus au code que tu as écrit. Il s'arrête à tout ce que ton agent est susceptible de lire. Autant dire : à Internet entier.