Agents Rule of Two : la réponse pragmatique de Meta au prompt injection

Qu’est-ce que l’Agents Rule of Two ?

L’équipe AI Security de Meta a publié l’Agents Rule of Two le 31 octobre 2025. Depuis, le cadre a été repris par Databricks (guide anti-prompt-injection de mai 2026), Oso, Xano et la plupart des éditeurs de plateformes d’agents. C’est la réponse opérationnelle la plus citée à un problème que l’industrie reconnaît désormais ouvertement comme structurellement insoluble côté modèle.

La règle tient en une phrase : au cours d’une même session d’agent, ne satisfaire au maximum que deux des trois propriétés suivantes.

• (A) L’agent traite des entrées non fiables (pages web, e-mails, sorties d’outils, documents RAG, contenu généré par l’utilisateur).
• (B) L’agent accède à des systèmes sensibles ou à des données privées (secrets d’entreprise, PII clients, code source, identifiants).
• (C) L’agent peut modifier l’état ou communiquer vers l’extérieur (écrire en base, envoyer un e-mail, appeler une API payante, pousser sur git, poster sur Slack).

Vous en choisissez deux. Vous ne câblez jamais les trois dans la même boucle sans humain dans le chemin.

Comment ça fonctionne

L’Agents Rule of Two est une reformulation structurelle du lethal trifecta de Simon Willison (formulé en septembre 2024) et s’inspire explicitement de la Rule of Two de Chromium pour les frontières de sandbox. Les deux partagent la même intuition : quand une surface vulnérable connue (un parseur, un LLM) se trouve entre des données non fiables et des capacités sensibles, on ne « répare » pas le parseur — on retire un côté du triangle.

Traduit en patterns d’architecture :

• A + B, sans C — un assistant de recherche en lecture seule qui résume des tickets clients, sans capacité d’envoi ni d’écriture.
• A + C, sans B — un chatbot public qui peut répondre mais ne voit que le message en cours, sans accès aux données internes.
• B + C, sans A — une automatisation qui touche aux données privées et écrit en retour, mais ne consomme que des champs structurés produits par du code de confiance (jamais de texte libre venu de l’extérieur).

Le billet de Meta (oct. 2025) explicite le mode de défaillance : quand les trois propriétés sont présentes, une seule injection indirecte dans un document non fiable suffit à transformer l’agent en confused deputy — il exécute des actions autorisées avec une intention malveillante. C’est exactement le schéma que la divulgation Comment and Control (mai 2026) a exploité contre Claude Code, Gemini CLI et GitHub Copilot Agent, et c’est ce que rendent possible les CVE 2026 contre PraisonAI (CVE-2026-44338), Semantic Kernel (CVE-2026-25592, CVE-2026-26030) ou LMDeploy (CVE-2026-33626).

Pourquoi c’est important

Le papier d’octobre 2025 The Attacker Moves Second (Nasr, Carlini et al., arXiv:2510.09023) a testé douze défenses publiées contre des attaquants adaptatifs. Onze ont été contournées avec des taux de succès supérieurs à 90 %. Même conclusion dans Output filtering beats model self-defense (Swept AI / Michigan, mai 2026) : sur 20 000 attaques adaptatives, chaque défense côté modèle a fini par céder.

Si les défenses côté modèle ne sont pas fiables, le déploiement devient un problème d’architecture plutôt que de prompt. La Rule of Two y répond sans détour : on cesse d’essayer de rendre le LLM sûr ; on contraint ce qu’on lui permet d’atteindre.

Le guide Databricks de mai 2026 opérationnalise cette logique avec neuf contrôles en couches sur Unity Catalog et Agent Bricks : redaction PII au niveau de l’AI Gateway, modèles Llama Protection en entrée et en sortie, allow-list d’egress, jetons de capacité liés à une session utilisateur unique, et validation humaine quand les trois propriétés sont inévitables.

Défenses

Étapes concrètes avant de mettre un agent en production :

• Classer chaque outil selon les trois propriétés (A, B, C). C’est un travail de tableur — la plupart des équipes découvrent que leur agent enfreint déjà la règle.
• Séparer les sessions, pas seulement les prompts. Toute utilisation d’outil nécessitant C doit s’exécuter dans un processus distinct sans accès aux secrets de B.
• Mettre en quarantaine le contenu non fiable. Rendre les pages web et les e-mails comme des données, ne jamais les réinjecter comme des instructions. Le smuggling par tags ASCII et l’injection indirecte supposent que l’agent traite les sorties d’outil comme faisant autorité.
• Lier les capacités à l’identité utilisateur via des jetons à durée courte, pas à la session de l’agent. Un agent compromis ne doit pas pouvoir agir hors du périmètre de l’appelant.
• Imposer un human-in-the-loop quand A + B + C est vraiment nécessaire (réponse à incident, agents code-review-then-merge, runbooks ops).
• Loguer le trifecta. Émettre un événement structuré à chaque session qui franchit deux seuils ; alerter sur trois.

Les critiques — notamment Ken Huang dans Rule of Two vs. Reality (nov. 2025) — soulignent que le cadre ne couvre pas l’empoisonnement de mémoire, la collusion multi-agents, ni les attaques à l’entraînement. C’est exact : la Rule of Two est un contrôle architectural au runtime, pas un modèle de menace complet. Compléter avec MITRE ATLAS et l’OWASP LLM Top 10 pour le reste.

Statut

Élément	Date	État
Billet Meta	31 oct. 2025	Public
Endossement Simon Willison	2 nov. 2025	Public
Analyse Michael Bargury	1ᵉʳ nov. 2025	Public
Guide opérationnel Databricks	2026 (mai)	Public
Revue critique (Ken Huang)	nov. 2025	Public
Adoption OWASP LLM Top 10 2026	En attente	En discussion

La Rule of Two n’est pas un patch. C’est une posture de déploiement, et en mai 2026 c’est ce qui se rapproche le plus d’un consensus industriel sur la manière de mettre des agents LLM en production sans attendre une percée côté modèle qui pourrait ne jamais venir.