Resumen Técnico: ChannelGuard: Los modelos seguros no se componen en sistemas multi-agente seguros

1. Planteamiento del problema

Las aplicaciones modernas de Modelos de Lenguaje Extensos (LLM) dependen cada vez más de sistemas multi-agente donde un planificador descompone tareas, agentes trabajadores las ejecutan (a menudo llamando a herramientas o leyendo memoria compartida) y un verificador/sintetizador produce un resultado final. Los autores identifican una brecha de seguridad crítica: mientras que las defensas existentes se centran en el límite de entrada (Usuario $\to$ Planificador) o dependen de filtros opacos y estocásticos del lado del proveedor (por ejemplo, Azure Content Safety), los canales inter-agente (Planificador $\to$ Trabajador, Herramienta $\to$ Trabajador, Memoria $\to$ Trabajador, etc.) permanecen sin monitorear.

El artículo argumenta que las métricas de evaluación actuales, específicamente la Tasa de Éxito de Ataque (ASR), son engañosas. Un pipeline puede mostrar un ASR de 0.000 en un backend específico (por ejemplo, Azure GPT-5) no porque la aplicación sea segura, sino porque el filtro del lado del servidor del proveedor de la nube interceptó el ataque. Esto crea un problema de "sustitución de mecanismo": si el backend se cambia a un modelo sin tales filtros (por ejemplo, Anthropic Sonnet), el resultado de seguridad sigue siendo 0.000, pero el mecanismo de protección se desplaza enteramente al alineamiento interno del modelo, el cual está fuera del control y es inobservable para el desarrollador. En consecuencia, los profesionales no pueden razonar sobre la verdadera robustez de sus sistemas.

2. Metodología: El marco de trabajo ChannelGuard

ChannelGuard es un marco de trabajo de defensa en profundidad que no requiere entrenamiento, diseñado para instrumentar cada canal inter-agente. No modifica los modelos de los agentes ni requiere reentrenamiento.

Componentes principales

1. Puertas de Cuello de Botella de Información (IB Gates):

   • Ubicación: Se colocan seis puertas en canales específicos: Entrada (IB-0), Planificador-a-Trabajador (IB-1), Herramienta-a-Trabajador (IB-3), Memoria-a-Trabajador (IB-3-mem), Trabajador-a-Verificador (IB-2/IB-4) y Trabajador-a-Sintetizador (IB-5).
   • Mecanismo: Cada puerta procesa el texto en su canal dividiéndolo en oraciones, generando sus embeddings (usando un modelo local all-MiniLM-L6-v2) y calculando la similitud de coseno máxima contra un banco de frases adversarias fijo y curado por humanos.
   • Lógica de decisión: La puerta calcula un puntaje de riesgo y toma una decisión determinista de tres vías:
     • Pasar (Pass): Riesgo < $\alpha\theta$ (el texto pasa sin cambios).
     • Comprimir (Compress): $\alpha\theta \le$ Riesgo < $\theta$ (el texto se trunca a las primeras $N=2$ oraciones).
     • Bloquear (Block): Riesgo $\ge \theta$ (el texto se reemplaza con una cadena vacía, interrumpiendo el pipeline).
   • Propiedades: La puerta no añade llamadas a LLM, no requiere datos de entrenamiento y su decisión es independiente del modelo de agente descendente.

2. Verificador consciente de la incertidumbre:

   • Un LLM separado (Claude Sonnet 4.5) califica las salidas supervivientes de los trabajadores utilizando 5 muestras de Monte Carlo para determinar un puntaje de seguridad promedio y su dispersión.
   • Marca las salidas como "inseguras" o "inciertas".

3. Sintetizador de Triple Filtro:

   • El sintetizador final solo acepta respuestas que pasen la puerta IB-5, tengan un puntaje de seguridad promedio $\ge 0.5$ y no hayan sido marcadas como tanto inseguras como inciertas.
   • Si ninguna salida sobrevive, se devuelve un rechazo estricto sin invocar más llamadas a LLM.

Metodología de evaluación

El artículo introduce una metodología de atribución por traza. En lugar de solo reportar el ASR, el sistema registra exactamente qué capa (puerta IB, filtro del proveedor, verificador o alineamiento del modelo) detuvo primero un ataque. Esto permite un análisis de "sustitución de mecanismo", distinguiendo entre el bloqueo propiedad de la aplicación y el bloqueo prestado del proveedor.

3. Contribuciones clave

1. Atribución por traza: Una metodología que convierte el ASR basado solo en resultados en una cuenta a nivel de mecanismo, haciendo medible y visible la "sustitución de mecanismo" (la dependencia de los filtros del proveedor).
2. Análisis de dependencia del proveedor: Evidencia empírica que muestra que en Azure GPT-5, un pipeline sin defensa deriva el 90% de su protección de ASR cero de la filtración del proveedor, y que al cambiar a backends de Anthropic, esta protección se reasigna enteramente al alineamiento del modelo, demostiendo que el resultado de seguridad es idéntico pero la procedencia es diferente e incontrolable.
3. El marco de trabajo ChannelGuard: Un sistema de seis puertas de similitud de embeddings que proporciona un bloqueo dependiente de la aplicación e invariante al proveedor.
4. Delimitación precisa de límites: El artículo identifica explícitamente dónde falla el marco (parafraseo adaptativo de caja blanca) y dónde tiene éxito, respaldado por extensos estudios de ablación y líneas base.

4. Resultados

La evaluación cubrió 2,100 trazas a través de ocho familias de ataques, cinco defensas y tres backends de modelos (Azure GPT-5, Anthropic Sonnet 4.5, Anthropic Haiku 4.5).

• Envenenamiento de herramientas (Tool Poisoning): ChannelGuard logró 30/30 bloqueos en la puerta IB-3 (Herramienta $\to$ Trabajador) en todos los tres backends. En contraste, el pipeline sin defensa dependió 100% del filtro del proveedor de Azure para el bloqueo en Azure, y 100% del alineamiento propio del modelo en los backends de Anthropic. El mecanismo de ChannelGuard se mantuvo fijo y propiedad de la aplicación.
• Inyección de Prompts (Prompt Injection): ChannelGuard redujo el ASR en un 50% (0.333 $\to$ 0.167) en comparación con la línea base sin defensa.
• Envenenamiento de Memoria (Memory Poisoning): En el stack de Azure, el filtro del proveedor dominó el bloqueo para ambos sistemas. Sin embargo, en los backends de Anthropic, la puerta IB-3-mem de ChannelGuard proporcionó un bloqueo parcial, con el resto manejado por el alineamiento del modelo, demostrando un resultado de "crédito compartido" en lugar de una sustitución total.
• Paráfrasis Adaptativa (Caja Blanca): Tanto ChannelGuard como la línea base sin defensa fallaron, con un ASR de ~0.667. El banco de frases estático no pudo detectar reescrituras semánticamente equivalentes pero léxicamente distantes. El artículo señala que una línea base de no-firma (SmoothLLM) funcionó mejor en este ataque específico.
• Eficiencia: ChannelGuard es 1.19$\times$ más rápido en la carga de trabajo adversaria combinada. Específicamente en Inyección de Prompts, es 3.30$\times$ más rápido porque su puerta IB-0 interrumpe el pipeline antes de que ocurran las llamadas costosas al modelo.
• Fidelidad del Razonamiento: En tareas benignas de GSM8K (sin ataques), ChannelGuard preservó la precisión del razonamiento exactamente (CTCA = 0.867 para ambos sistemas).

5. Significación y Reivindicaciones

El artículo afirma que los modelos seguros no se componen en sistemas multi-agente seguros sin un monitoreo explícito de los canales inter-agente. Su principal significación radica en:

• Exponer la "Ilusión de Seguridad": Demostrar que un ASR de cero en las evaluaciones actuales a menudo enmascara una dependencia total de los filtros estocásticos y opacos de los proveedores que los desarrolladores no pueden controlar ni auditar.
• Invarianza al Proveedor: Probar que ChannelGuard proporciona un mecanismo de bloqueo determinista e inspeccionable que permanece constante independientemente del backend del modelo subyacente, a diferencia de la seguridad "prestada" de los pipelines sin defensa.
• Defensa en Profundidad: Posicionar a ChannelGuard no como un reemplazo para los filtros de los proveedores o las defensas de solo entrada, sino como una capa necesaria que asegura la superficie interna del pipeline.

Los autores son modestos sobre las limitaciones del marco, reconociendo que los bancos de frases estáticos no pueden derrotar el parafraseo adaptativo de caja blanca y que la implementación actual depende de plantillas curadas a mano y exclusivas para el inglés. Concluyen que el siguiente paso es aprender el banco de frases de forma adversaria para igualar la cobertura de los canales.