Google et Meta publient une alerte : les agents IA ne sont pas fiables

Tu fais confiance aux agents IA pour tes tâches quotidiennes ? Google et Meta viennent de publier une alerte qui devrait te refroidir. Leurs propres chercheurs traitent désormais les modèles IA comme des composants non fiables.

Les agents IA ne se polissent pas eux-mêmes

Les chercheurs de Google et Meta tirent la sonnette d’alarme. Le papier “Agent Security Is a Systems Problem” est clair. Les modèles IA ne peuvent pas assurer leur propre sécurité.

Les développeurs font trop confiance au modèle. Ils lui demandent de se policer lui-même. Les attaquants trouvent toujours un moyen de contourner ces garde-fous. Le modèle n’a aucun jugement réel.

Les agents IA explorent tous les répertoires accessibles. Ils le font à vitesse machine. Une instruction mal placée et c’est la catastrophe.

Des attaques documentées et concrètes

Onze attaques réelles figurent dans le papier. Deux méritent ton attention particulière.

La première touche la mémoire de ChatGPT. Des instructions malicieuses s’injectent via un document tout ce qu’il y a de plus ordinaire. Le système envoie alors les conversations de l’utilisateur vers un serveur externe. Une URL image invisible fait le travail.

La seconde vise Claude Code. L’attaquant injecte un prompt dans un fichier de code. La commande ping déclenche une requête DNS. Les clés API fuient par ce canal.

Les limites du modèle “self-policing”

Le problème fondamental identifié par Google et Meta est le suivant : on demande au modèle IA de se surveiller lui-même. C’est comme demander à un employé de vérifier si lui-même vole dans la caisse.

Les développeurs intègrent des prompts système du type “ne fais jamais X”. Mais le modèle n’a pas de conscience. Il ne “refuse” pas vraiment. Il suit des patterns statistiques. Et un attaquant habile trouve toujours un pattern qui bypass le refus.

La solution proposée par les chercheurs n’est pas d’améliorer le refus du modèle. C’est de construire des barrières externes. Sandboxing, contrôle d’accès, monitoring réseau. Des systèmes qui ne dépendent pas de l’intelligence du modèle.

Trois principes de sécurité à appliquer

Les chercheurs proposent trois axes concrets. Tu peux les appliquer dès maintenant.

• Séparation instruction et données : ne mélange jamais ce que l’agent doit faire avec les fichiers qu’il lit.
• Sandboxing least privilege : limite l’accès au strict nécessaire. Un agent n’a pas besoin de lire tout ton système.
• Contrôle du flux d’information : surveille chaque sortie réseau. Bloque les requêtes DNS inattendues.

Les 11 attaques documentées en détail

Le papier catalogue onze attaques réelles contre des agents IA. Voici les plus préoccupantes.

• Injection via mémoire ChatGPT : un document PDF contient des instructions invisibles. Quand l’utilisateur demande “résume ce document”, les instructions s’activent et exfiltrent les conversations vers un serveur externe.
• Extraction de clés via Claude Code : un fichier de code contient un prompt caché. Quand Claude Code le lit, il exécute une commande ping qui fuit les clés API via DNS.
• Manipulation de sandbox : l’agent est convaincu de désactiver ses propres garde-fous en modifiant sa configuration.
• Chaîne d’outils compromise : un outil autorisé par l’agent est remplacé par une version malveillante. Toutes les actions suivantes sont compromises.

Le point commun de toutes ces attaques : elles exploitent la confiance excessive entre le système et le modèle. Le modèle est traité comme un processus fiable. Il ne l’est pas.

Pourquoi cette étude change la donne

Ce papier vient de Google et Meta eux-mêmes. Ce ne sont pas des chercheurs externes qui critiquent. Ce sont les créateurs de ces systèmes qui admettent le problème.

UC San Diego et plusieurs universités ont co-signé. La crédibilité du papier est maximale. Les exemples sont concrets et reproductibles.

Questions fréquentes

Avant de connecter ton agent à tes fichiers sensibles, pose-toi une question simple. Qui contrôle vraiment ce qu’il lit ? La réponse devrait te pousser à mettre en place un sandboxing strict.