Resumen Técnico: LACUNA: Agentes Seguros como Huecos de Programa Recursivos

Enunciado del Problema

Los agentes actuales de Modelos de Lenguaje Grande (LLM) enfrentan una división arquitectónica fundamental entre el tiempo de ejecución que impulsa el bucle del agente y el código que el modelo escribe. En enfoques dominantes como ReAct, el tiempo de ejecución posee el flujo de control, la gestión del contexto y la distribución de herramientas, mientras que el modelo simplemente emite llamadas individuales a herramientas o pasos de razonamiento. En los agentes de "código-como-acción", el modelo escribe código para componer herramientas y lógica, pero este código permanece distinto del tiempo de ejecución.

Esta separación crea un dilema de seguridad. Si el tiempo de ejecución controla estrictamente el bucle, el agente carece de expresividad. Si el modelo moldea el propio tiempo de ejecución para aumentar la expresividad, los riesgos de seguridad se escalan: un modelo desviado por inyección de prompts, un error en una llamada a herramienta o una falla parcial pueden dejar el entorno en un estado inconsistente o comprometer el tiempo de ejecución. Las defensas existentes (entornos aislados, intérpretes restringidos, lenguajes de política) suelen ser fragmentarias, operando en tiempo de ejecución o sobre las entradas, y ninguna verifica una acción generada completa contra el contexto del programa circundante antes de que comience la ejecución.

Metodología: LACUNA

Los autores proponen LACUNA, un modelo de programación que cierra la brecha entre el tiempo de ejecución del agente y el código escrito por el modelo, preservando la seguridad mediante la tipificación estática. El primitivo central es un "hueco" tipado en el programa anfitrión:

def agent[T](task: String): T

Mecanismo Central

1. Huecos Tipados: Una llamada a agente actúa como un marcador de posición donde el programa circundante espera estáticamente un valor de tipo T. Se solicita al LLM que genere código Scala que produzca este valor.
2. Compilación Consciente del Contexto: Cuando la ejecución alcanza la llamada agent, el LLM genera código basado en la task en lenguaje natural, el tipo esperado T y el alcance léxico en vivo (variables, funciones, herramientas e importaciones disponibles en ese punto específico).
3. Verificación Pre-ejecución: El código generado es compilado por el compilador anfitrión (Scala 3) en el contexto del programa circundante antes de que se ejecute nunca.
   • Verificación de Tipos: El código debe producir un valor de tipo T.
   • Verificación de Alcance: Todos los nombres utilizados deben estar en el alcance.
   • Verificación de Capacidades: Si está habilitado, la verificación de captura asegura que el código solo acceda a recursos (archivos, red, herramientas) concedidos explícitamente en el alcance léxico.
4. Ejecución Todo o Nada: Si el código supera todas las verificaciones, se ejecuta. Si falla (por ejemplo, incompatibilidad de tipos, herramienta faltante, acceso no autorizado), todo el fragmento es rechazado. No ocurre ejecución parcial, lo que previene estados inconsistentes. Los diagnósticos del compilador se retroalimentan al LLM para impulsar un bucle de reintento.

Implementación

El prototipo está construido en Scala 3, aprovechando dos características específicas:

• Recompilación en proceso: La capacidad de invocar al compilador dentro de un programa en ejecución para insertar y compilar una cadena de código fuente contra el contexto actual.
• Verificación de Captura: Un mecanismo para rastrear qué efectos y recursos se permite usar a un fragmento de código, haciendo cumplir la seguridad basada en capacidades.

El primitivo agent es un envoltorio delgado alrededor de una operación eval de nivel inferior. Gestiona la construcción del prompt (incluyendo el código fuente envolvente y los enlaces disponibles), llama al LLM, pasa el resultado a eval y maneja el bucle de reintento tras una falla de compilación.

Contribuciones Clave

1. Un Modelo de Código-como-Acción con Garantías Estáticas: Un modelo donde el LLM escribe acciones como código que se ejecuta como parte de su propio tiempo de ejecución, verificado en el punto de llamada antes de la ejecución.
2. Análisis de Seguridad: Demuestra que el rechazo pre-ejecución de nombres no disponibles e incompatibilidades de tipos, combinado con la ejecución atómica (sin ejecuciones parciales), proporciona fuertes garantías de seguridad. Además, muestra cómo el alcance de capacidades limita la autoridad del agente y el flujo de información.
3. Expresividad mediante Flujo de Control Ordinario: Muestra que las llamadas anidadas a agentes y las estructuras de código estándar pueden expresar patrones complejos de agentes (bucles ReAct, sub-agentes, habilidades, descomposición paralela, planificación multi-modelo) sin necesidad de un protocolo de agente separado.
4. Evaluación Empírica: Una realización en Scala 3 evaluada en casos de prueba de verificador, BrowseComp-Plus (búsqueda de información difícil) y $\tau^2$-bench (conversaciones multi-turno con uso de herramientas).

Resultados

La evaluación destaca el compromiso entre seguridad, expresividad y capacidad del modelo:

• Seguridad y Tasas de Rechazo: En BrowseComp-Plus, el 8.6% de las generaciones fueron rechazadas antes de la ejecución debido a errores de tipo o de alcance. El sistema promedió 0.7 reintentos por consulta, con una tasa de éxito de compilación de extremo a extremo del 91.4%. Esto confirma que el compilador bloquea eficazmente acciones mal tipadas o fuera de alcance.
• Rendimiento en Tareas Complejas:
  • BrowseComp-Plus: Utilizando el modelo deepseek-flash, LACUNA logró una precisión del 27.1%, comparable a los agentes de referencia, mientras impulsaba investigación genuina de múltiples pasos (promedio de 5.9 rondas, 15.5 búsquedas).
  • $\tau^2$-bench: A través de 392 tareas en cuatro dominios (Retail, Aerolínea, Telecomunicaciones, Tel.-WF), LACUNA resolvió el 76.0% de las tareas con un modelo capaz, desempeñándose al nivel de un agente de llamada a herramientas de referencia.
• Dependencia del Modelo: El éxito del sistema depende en gran medida de la capacidad de codificación del modelo. Los modelos más débiles (por ejemplo, gemini-3.1-flash-lite) tuvieron dificultades con dominios complejos (por ejemplo, una tasa de rechazo del 89% en telecomunicaciones), lo que llevó a tasas de resolución más bajas. La garantía de seguridad se mantiene independientemente de la competencia del modelo (los intentos fallidos nunca se ejecutan), pero el progreso se detiene si el modelo no puede generar código válido.
• Robustez Adversarial: En las pruebas de inyección de prompts (AgentDojo), la capa de capacidades confinó con éxito las acciones del agente a su alcance concedido. Incluso cuando fue influenciado por contenido inyectado, el agente no pudo acceder a recursos fuera de su alcance léxico.

Significado y Afirmaciones

El artículo posiciona a LACUNA no como un reemplazo de las arquitecturas de agentes existentes, sino como una base más segura y flexible.

• Unificación de Ejecución y Razonamiento: Al fusionar la ejecución del programa y el razonamiento del modelo en un solo proceso donde el modelo escribe el flujo de control, LACUNA permite que los agentes sean más expresivos mientras mantienen las garantías de seguridad del lenguaje anfitrión.
• Seguridad mediante Compilación: La contribución principal es desplazar la seguridad de los entornos aislados en tiempo de ejecución hacia la verificación estática pre-ejecución. Un fragmento rechazado deja el entorno intacto, y los diagnósticos del compilador impulsan la autocorrección.
• Seguridad de Capacidades: El sistema demuestra que la "mínima autoridad" se puede hacer cumplir a través del alcance léxico y la verificación de captura, limitando lo que un modelo adversario o erróneo puede hacer incluso si es influenciado por inyección de prompts.
• Limitaciones Modestas: Los autores reconocen que "bien tipado" no significa "correcto" (los errores semánticos no se detectan), que el sistema depende de la competencia de codificación del modelo (que varía según el lenguaje y el dominio), y que el agotamiento de recursos (latencia, recursión infinita) debe gestionarse mediante presupuestos en tiempo de ejecución en lugar de sistemas de tipos.

En resumen, LACUNA propone que tratar las acciones del agente como huecos tipados en un lenguaje anfitrión de tipado estático permite un diseño de agente recursivo y expresivo donde la seguridad está garantizada por la solidez del compilador en lugar de heurísticas en tiempo de ejecución.