Arbiter: Detecting Interference in LLM Agent System Prompts

El artículo presenta Arbiter, un marco de evaluación que combina reglas formales y el escaneo con múltiples modelos de lenguaje para detectar patrones de interferencia en los prompts de sistema de agentes de codificación, revelando vulnerabilidades críticas y correlaciones arquitectónicas en herramientas de Anthropic, OpenAI y Google por un costo mínimo.

Lo esencial

Imagina que los agentes de IA (como los que escriben código para ti) son como obreros muy inteligentes que trabajan en una obra. Pero hay un problema: nadie les ha dado un manual de instrucciones claro. En su lugar, tienen un "prompt del sistema", que es básicamente una constitución o un libro de reglas gigante que les dice qué hacer, qué no hacer y cómo comportarse.

El problema es que estos libros de reglas están escritos por humanos, a veces por diferentes equipos, y nadie los ha revisado. Contienen contradicciones, instrucciones confusas y agujeros que hacen que el obrero (la IA) se confunda, pero como la IA es muy "amable", intenta adivinar qué hacer en lugar de decir "¡Oye, esto no tiene sentido!".

Aquí es donde entra Arbiter, el nuevo sistema que presentan en este paper.

¿Qué es Arbiter? (El Inspector de Obras)

Piensa en Arbiter como un inspector de construcción super-rápido y barato que revisa esos manuales de instrucciones antes de que empiece el trabajo.

El sistema funciona de dos formas, como si tuviera dos tipos de ojos:

1. El Ojo Lógico (Evaluación Dirigida):

   • Imagina que tomas el manual y lo cortas en pedacitos. Luego, usas una regla estricta: "Si en la página 1 dice 'Usa siempre el martillo' y en la página 50 dice 'Nunca uses el martillo', ¡ALERTA! Hay un error".
   • Este ojo busca contradicciones obvias, como si fuera un corrector ortográfico que busca errores de lógica. Encontraron 21 errores graves en el manual de Claude Code (el de Anthropic).

2. El Ojo Curioso (Rastrillaje Indirecto):

   • Aquí es donde se pone divertido. En lugar de usar reglas fijas, Arbiter le pide a 10 robots diferentes (distintas IAs) que lean el manual y digan: "¿Qué te parece raro o interesante aquí?".
   • Como cada robot ha sido entrenado de forma distinta, uno se fija en el dinero, otro en la seguridad, otro en la memoria. Uno puede decir: "Oye, si borras el historial, se te olvidan las preferencias del usuario". Otro puede decir: "Aquí hay una forma de gastar todo el presupuesto de la empresa".
   • Al usar muchos robots diferentes, descubren cosas que un solo robot o un humano nunca vería.

¿Qué encontraron? (Los Tres Tipos de Manuales)

El paper descubre que la forma en que está escrito el manual determina el tipo de error que tiene. Es como la arquitectura de un edificio:

• El Manual "Monolítico" (Todo en uno, como Claude Code):

  • Es un libro gigante de 1,490 páginas.
  • El problema: Como es tan grande y lo escribieron muchos equipos diferentes, hay secciones que se pelean entre sí. Por ejemplo, una sección dice "Usa siempre esta herramienta" y otra dice "Nunca la uses".
  • La analogía: Es como una casa donde el fontanero instaló tuberías que chocan con las del electricista porque nadie revisó el plano final.

• El Manual "Plano" (Simple, como Codex CLI):

  • Es corto y directo (298 páginas).
  • El problema: Al ser tan simple, tiene menos errores, pero también hace menos cosas.
  • La analogía: Es una cabaña pequeña. No tiene fugas porque no tiene muchas tuberías, pero tampoco tiene piscina ni jacuzzi.

• El Manual "Modular" (Piezas ensambladas, como Gemini CLI):

  • Está hecho de piezas que se unen al momento de usarlo.
  • El problema: Cada pieza funciona bien por sí sola, pero cuando se unen, hay un hueco.
  • El hallazgo estrella: Descubrieron que en el manual de Google, había una regla que decía "Guarda las preferencias del usuario" y otra que decía "Cuando el espacio se llene, borra todo y guarda un resumen". El resumen no tenía espacio para las preferencias.
  • La consecuencia: Si un usuario guardaba sus gustos, al día siguiente, la IA los olvidaba para siempre. ¡Y Google ya había arreglado el síntoma (que la IA se colgaba) pero no el verdadero problema (que se borraban los datos)!

¿Por qué es importante esto?

1. La IA no puede juzgarse a sí misma: Si le pides a la IA que revise sus propias reglas, ella intentará "suavizar" los errores para que parezcan lógicos. Necesitamos un juez externo.
2. Es increíblemente barato: Analizar los manuales de tres gigantes tecnológicos (Google, OpenAI, Anthropic) costó 27 centavos de dólar. Menos de lo que cuesta un café. Es menos de 3 minutos de trabajo de un humano.
3. Necesitamos "Linters" para la IA: Así como los programadores usan herramientas para revisar su código antes de lanzarlo, necesitamos herramientas para revisar los "prompts" de la IA.

En resumen

Este paper nos dice que los "cerebros" de nuestras IAs (sus instrucciones) están llenos de agujeros, contradicciones y olvidos, y que nadie los está revisando. Arbiter es la herramienta que demuestra que podemos encontrar estos errores de forma automática, barata y muy efectiva, usando un equipo de "detectives" (diferentes IAs) que se complementan entre sí.

Es como decir: "Oye, hemos construido un coche muy rápido, pero el manual de instrucciones tiene una página que dice 'pisa el freno' y otra que dice 'pisa el acelerador' al mismo tiempo. Vamos a arreglarlo antes de que alguien se estrelle".

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "Arbiter: Detecting Interference in LLM Agent System Prompts" en español:

1. El Problema: Prompts como Artefactos de Software Sin Pruebas

Los autores identifican que los prompts del sistema que gobiernan a los agentes de codificación basados en LLM (como Claude Code, Codex CLI y Gemini CLI) son, en esencia, artefactos de software complejos. Estos prompts definen comportamientos, jerarquías de precedencia, contratos de herramientas y gestión de estado. Sin embargo, a diferencia del software tradicional, carecen de infraestructura de pruebas: no tienen verificadores de tipos, linters ni suites de pruebas.

El problema central es que cuando un prompt contiene instrucciones contradictorias (ej. "siempre usa TodoWrite" vs. "NUNCA uses TodoWrite"), el LLM que ejecuta el prompt resuelve el conflicto silenciosamente mediante sus heurísticas de entrenamiento, sin generar errores ni advertencias. El artículo argumenta que el agente que resuelve el conflicto no puede ser el mismo que lo detecta, ya que el mecanismo de "juicio" que hace útil al LLM también lo hace poco fiable como auditor de sus propias instrucciones.

2. Metodología: El Marco Arbiter

Se presenta Arbiter, un marco de evaluación que combina reglas formales con el escaneo multi-modelo para detectar patrones de interferencia. El enfoque consta de dos fases complementarias:

A. Evaluación Dirigida (Arqueología de Prompts)

• Descomposición: El prompt se divide en bloques contiguos clasificados por nivel (sistema/dominio/aplicación), categoría, modalidad (mandato, prohibición, guía) y alcance.
• Aplicación de Reglas: Se aplican reglas formales para detectar tipos específicos de interferencia (ej. conflictos mandato-prohibición, redundancia de superposición de alcance, ambigüedad de marcadores de prioridad).
• Filtrado: Se utilizan pre-filtros para reducir el espacio de búsqueda, evaluando solo pares de bloques relevantes.
• Limitación: Es exhaustiva dentro de su marco definido, pero ciega a vulnerabilidades para las cuales no existe una regla predefinida.

B. Escaneo Indirecto (Multi-Model Scouring)

• Diseño: Se envía el prompt a múltiples LLMs con instrucciones deliberadamente vagas ("lee esto cuidadosamente y nota lo que encuentres interesante").
• Composición Multi-paso: Cada paso recibe los hallazgos acumulados de pasos anteriores y se le pide que explore territorios no cubiertos.
• Ejecución Multi-modelo: Cada paso utiliza un modelo LLM diferente (ej. Claude Opus, DeepSeek, Kimi, Grok, etc.). La premisa es que diferentes modelos, entrenados en datos distintos, traen sesgos analíticos complementarios.
• Criterio de Terminación Convergente: El proceso se detiene cuando tres modelos consecutivos declinan encontrar nuevo material, asegurando que la exploración ha convergido.

C. Análisis Estructural (AST)

Se utiliza un parser de dos capas para generar un Árbol de Sintaxis Abstrata (AST) del prompt, permitiendo el análisis de la estructura del documento (secciones, directivas) independiente del contenido, facilitando la detección de clones y diferencias entre versiones.

3. Contribuciones Clave

1. Taxonomía de Fallos: Una clasificación de modos de fallo en prompts basada en evidencia empírica de tres proveedores principales.
2. Metodología Híbrida: Una combinación de reglas dirigidas (exhaustivas) y escaneo indirecto multi-modelo (descubridor de lo desconocido).
3. Descubrimiento de Vulnerabilidades: Evidencia de que la evaluación multi-modelo descubre clases de vulnerabilidades categóricamente diferentes a las encontradas por un solo modelo.
4. Validación Externa: Un hallazgo de diseño (pérdida de datos estructurales en Gemini CLI) fue confirmado independientemente por el proveedor (Google) mediante un informe de error y parche, aunque el proveedor no abordó la causa raíz a nivel de esquema.
5. Bajo Costo: Demostración de que un análisis exhaustivo multi-vendedor costó solo $0.27 USD en llamadas a API.

4. Resultados Principales

Hallazgos Cuantitativos

• Análisis de Claude Code (Anthropic): 1,490 líneas. Se identificaron 21 patrones de interferencia en el análisis dirigido y 116 hallazgos en el escaneo indirecto.
• Análisis de Codex CLI (OpenAI) y Gemini CLI (Google): Se identificaron 15 y 21 hallazgos respectivamente en el escaneo.
• Costo: El costo total para analizar los tres prompts fue de $0.27 USD.

Correlación entre Arquitectura y Fallos

El estudio establece una fuerte correlación entre la arquitectura del prompt y el tipo de fallo observado:

1. Monolítica (Claude Code): Los prompts largos y únicos acumulan errores de crecimiento en los límites de los subsistemas. Ejemplo: Mandatos universales que contradicen flujos de trabajo específicos (ej. gestión de tareas vs. commits).
2. Plana (Codex CLI): Prompts cortos y simples. Los fallos son compensaciones de simplicidad; hay menos contradicciones operativas, pero se pierden capacidades complejas.
3. Modular (Gemini CLI): Prompts compuestos dinámicamente. Los fallos son errores de diseño en las costuras de composición. Los módulos funcionan bien aisladamente, pero los contratos entre ellos (ej. compresión de historial vs. guardado de memoria) no están especificados, llevando a la pérdida de datos.

Complementariedad de Modelos

Los diferentes modelos LLM no solo encontraron más hallazgos, sino hallazgos de tipos diferentes:

• Kimi K2.5 se centró en explotación económica y agotamiento de recursos.
• DeepSeek V3.2 encontró referencias ocultas y brechas de delegación.
• Claude Opus se centró en contradicciones estructurales y superficies de seguridad.
  Esto demuestra que la diversidad de modelos es necesaria para una cobertura completa, ya que sus sesgos de entrenamiento revelan diferentes ángulos de ataque.

Caso de Estudio: Gemini CLI

El escaneo detectó que el sistema de compresión de historial de Gemini CLI elimina estructuralmente las preferencias guardadas por el usuario (save_memory) porque el esquema XML de compresión no tiene un campo para ellas. Google parcheó un síntoma relacionado (bucle infinito) pero no corrigió la pérdida de datos a nivel de esquema, validando la utilidad del escaneo estático para encontrar causas raíz que los pruebas dinámicas podrían pasar por alto.

5. Significado e Implicaciones

• Prompts como Software: El artículo establece que los prompts deben tratarse con la misma disciplina de ingeniería de software que el código tradicional: necesitan linters, pruebas de integración y revisiones de consistencia interna.
• Paradoja del Observador: Un LLM no puede auditar sus propias instrucciones contradictorias; se requiere una evaluación externa y formal.
• Accesibilidad: La barrera de entrada para un análisis de seguridad profundo de prompts es extremadamente baja ($0.27), lo que sugiere que la industria está negligente al no implementar estas verificaciones sistemáticas.
• Ley de Conway: La estructura del prompt refleja la estructura del equipo que lo creó (ej. monolitos reflejan falta de integración entre equipos), prediciendo los tipos de errores que surgirán.

En conclusión, Arbiter demuestra que los prompts de sistema son el componente más crítico y menos probado de los agentes de IA actuales, y que su análisis requiere una combinación de reglas formales y perspectivas múltiples de modelos de lenguaje para garantizar la seguridad y consistencia operativa.