Agents Rule of Two: la respuesta pragmática de Meta al prompt injection

¿Qué es la Agents Rule of Two?

El equipo de AI Security de Meta publicó la Agents Rule of Two el 31 de octubre de 2025. Desde entonces, el marco ha sido adoptado por Databricks (guía anti-prompt-injection de mayo de 2026), Oso, Xano y la mayoría de proveedores de plataformas de agentes. Es la respuesta operativa más citada a un problema que la industria reconoce abiertamente como estructuralmente irresoluble desde el lado del modelo.

La regla cabe en una frase: dentro de una misma sesión de agente, satisfacer como máximo dos de las tres propiedades siguientes.

• (A) El agente procesa entradas no confiables (páginas web, correos electrónicos, salidas de herramientas, documentos RAG, contenido generado por el usuario).
• (B) El agente tiene acceso a sistemas sensibles o a datos privados (secretos corporativos, PII de clientes, código fuente, credenciales).
• (C) El agente puede cambiar estado o comunicarse externamente (escribir en una base de datos, enviar un correo, llamar a una API de pago, hacer push a git, publicar en Slack).

Elija dos. Nunca conecte las tres en el mismo bucle sin un humano en el camino.

Cómo funciona

La Agents Rule of Two es una reformulación estructural del lethal trifecta de Simon Willison (acuñado en septiembre de 2024) y se inspira explícitamente en la Rule of Two de Chromium para los límites de sandbox. Ambas comparten la misma intuición: cuando una superficie vulnerable conocida (un parser, un LLM) se sitúa entre datos no confiables y capacidades sensibles, no se “arregla” el parser — se elimina un lado del triángulo.

Traducido a patrones de diseño:

• A + B, sin C — un asistente de investigación de solo lectura que resume tickets de clientes, sin capacidad de envío ni escritura.
• A + C, sin B — un chatbot público que puede responder pero solo ve el mensaje actual, sin acceso a datos internos.
• B + C, sin A — una automatización que toca datos privados y escribe de vuelta, pero solo consume campos estructurados producidos por código confiable (nunca texto libre del exterior).

La publicación de Meta (oct. 2025) hace explícito el modo de fallo: cuando las tres propiedades están presentes, una sola injection indirecta en un documento no confiable basta para convertir al agente en un confused deputy — ejecuta acciones autorizadas con intención maliciosa. Es exactamente el patrón que explotó la divulgación Comment and Control (mayo de 2026) contra Claude Code, Gemini CLI y GitHub Copilot Agent, y lo que hacen posible los CVE de 2026 contra PraisonAI (CVE-2026-44338), Semantic Kernel (CVE-2026-25592, CVE-2026-26030) y LMDeploy (CVE-2026-33626).

Por qué importa

El paper de octubre de 2025 The Attacker Moves Second (Nasr, Carlini et al., arXiv:2510.09023) probó doce defensas publicadas contra atacantes adaptativos. Once fueron eludidas con tasas de éxito superiores al 90 %. La misma conclusión aparece en Output filtering beats model self-defense (Swept AI / Michigan, mayo de 2026): sobre 20 000 ataques adaptativos, todas las defensas del lado del modelo terminaron cediendo.

Si no se puede confiar en las defensas del lado del modelo, el despliegue se vuelve un problema arquitectónico en lugar de un problema de prompting. La Rule of Two responde sin rodeos: dejar de intentar hacer seguro al LLM; restringir aquello a lo que el LLM tiene permitido alcanzar.

La guía de Databricks de mayo de 2026 operacionaliza esta lógica con nueve controles en capas sobre Unity Catalog y Agent Bricks: redacción de PII en el AI Gateway, modelos Llama Protection en entrada y salida, allow-list de egress, tokens de capacidad vinculados a una sesión de usuario única, y aprobación humana cuando las tres propiedades son inevitables.

Defensas

Pasos concretos antes de poner un agente en producción:

• Clasificar cada herramienta según las tres propiedades (A, B, C). Es trabajo de hoja de cálculo — la mayoría de los equipos descubre que su agente ya infringe la regla.
• Separar sesiones, no solo prompts. El uso de herramientas que requiera C debe ejecutarse en un proceso aparte sin acceso a los secretos de B.
• Poner en cuarentena el contenido no confiable. Renderizar páginas web y correos como datos, nunca reinyectarlos como instrucciones. El smuggling por etiquetas ASCII y la injection indirecta asumen que el agente trata la salida de herramientas como autoritativa.
• Vincular capacidades a la identidad del usuario mediante tokens de corta duración, no a la sesión del agente. Un agente comprometido no debe poder actuar fuera del ámbito del llamante.
• Exigir human-in-the-loop cuando A + B + C sea realmente necesario (respuesta a incidentes, agentes code-review-and-merge, runbooks de ops).
• Registrar el trifecta. Emitir un evento estructurado cada vez que una sesión de agente cruce dos umbrales; alertar al cruzar tres.

Los críticos — en particular Ken Huang en Rule of Two vs. Reality (nov. 2025) — señalan que el marco no cubre el envenenamiento de memoria, la colusión multi-agente ni los ataques en tiempo de entrenamiento. Es correcto: la Rule of Two es un control arquitectónico de runtime, no un modelo de amenazas completo. Combinarla con MITRE ATLAS y OWASP LLM Top 10 para el resto.

Estado

Elemento	Fecha	Estado
Publicación de Meta	31 oct. 2025	Público
Respaldo de Simon Willison	2 nov. 2025	Público
Análisis de Michael Bargury	1 nov. 2025	Público
Guía operativa Databricks	2026 (mayo)	Público
Revisión crítica (Ken Huang)	nov. 2025	Público
Adopción en OWASP LLM Top 10 2026	Pendiente	En discusión

La Rule of Two no es un parche. Es una postura de despliegue, y a mayo de 2026 es lo más parecido a un consenso industrial sobre cómo poner agentes LLM en producción sin esperar a un avance del lado del modelo que quizá nunca llegue.