💻 computer science

Context-to-Execution Integrity for LLM Agents

Este artículo introduce la Integridad de Contexto a Ejecución (CXI, por sus siglas en inglés), un sistema que asegura a los agentes de LLM mediante la imposición de controles de autoridad estrictos sobre campos de sumidero, cargas útiles y eventos de invocación protegidos para garantizar que solo se ejecuten acciones con autoridad de campo, efecto e invocación vinculante, logrando así cero escapes de seguridad observados a través de diversos bancos de pruebas.

Autores originales: Igor Santos-Grueiro

Publicado 2026-07-08

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Igor Santos-Grueiro

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina a un asistente altamente capacitado pero ingenuo (el agente de IA) que intenta hacer cosas por ti, como enviar correos electrónicos, editar archivos o ejecutar código. Este asistente lee un cuaderno masivo lleno de instrucciones, notas y mensajes. El problema es que un tramposo astuto (el atacante) puede colar notas en este cuaderno, intentando engañar al asistente para que realice algo peligroso, como borrar una base de datos o enviar dinero a la persona equivocada.

El artículo presenta un sistema llamado Context-to-Execution Integrity (CXI). Piensa en CXI como un guardia de seguridad súper estricto parado en la puerta de la "Sala de Acción". Su trabajo no es leer toda la historia o decidir si la tarea es una buena idea; su trabajo es verificar si el asistente tiene las llaves específicas y válidas para abrir la puerta para esta acción específica.

Así es como funciona, usando analogías simples:

1. El Problema: "Lavado de Autoridad" (Authority Laundering)

Normalmente, si el asistente lee una nota en el cuaderno que dice, "El archivo falló, así que ejecuta el comando delete_all", podría simplemente hacerlo. El artículo llama a esto Lavado de Autoridad. Es como si un ladrón tomara una tarjeta de identificación de apariencia legítima (la nota sobre el fallo del archivo) e intentara usarla para abrir la bóveda de un banco (el comando de eliminar). La nota explica por qué algo sucedió, pero no debería tener el poder de hacer que algo suceda.

2. La Solución: La Verificación de Tres Partes

CXI actúa como un portero. Antes de que el asistente pueda realmente hacer algo (como escribir un archivo o enviar un correo electrónico), el portero verifica tres cosas. Todas las tres deben coincidir con el mismo plan específico (llamado "Manifiesto").

Verificación 1: El "Quién" (Autoridad de Campo)
- Analogía: Imagina que el asistente quiere escribir una carta a una persona específica. La nota en el cuaderno podría decir, "Enviar a Bob". Pero el guardia de seguridad verifica: "¿Un jefe de confianza o un sistema verificado dijo realmente 'Enviar a Bob'?".
- Si el nombre "Bob" proviene simplemente de una nota aleatoria que escribió el atacante, el guardia dice NO. El nombre debe provenir de un "Typed Release" (Liberación Tipificada): un papel especial y verificado que dice: "Sí, este nombre específico está permitido para este campo específico".
Verificación 2: El "Qué" (Autoridad de Efecto)
- Analogía: Imagina que el asistente quiere aplicar un parche a un programa informático. La nota dice, "Aplica este código". El guardia verifica: "¿Este código realmente hace lo que creemos que hace?".
- El guardia no solo mira las palabras; mira el resultado. Si el código es un "parche", el guardia verifica exactamente qué cambios realizará en el sistema. Si el atacante intenta colar un comando que parece un parche pero que en realidad elimina archivos, el guardia lo detectará porque el "efecto" no coincide con el plan autorizado.
Verificación 3: El "Cuándo" (Autoridad de Invocación)
- Analogía: Imagina que el asistente quiere presionar el botón de "Ir". El guardia verifica: "¿Tiene el asistente un boleto válido para presionar el botón justo ahora?".
- Incluso si el nombre y el plan son correctos, el asistente necesita una "capacidad" o boleto específico para activar la acción. Si el atacante intenta engañar al asistente para que presione el botón dos veces o en el momento equivocado, el guardia dice NO porque el boleto falta o ha expirado.

3. El "Manifiesto" (El Plan Maestro)

El artículo llama al plan final aprobado un Manifiesto. Piensa en esto como un contrato.

El asistente propone una acción.
El guardia verifica el "Quién", el "Qué" y el "Cuándo".
Si las tres partes coinciden perfectamente y están ligadas al mismo contrato, el guardia sella el contrato y le entrega al asistente un "Lease" (permiso) para ejecutarlo.
Si incluso una parte falta o no coincide (por ejemplo, el nombre es correcto, pero el boleto del "Cuándo" es incorrecto), el guardia cierra la puerta.

4. ¿Qué pasa con las notas "malas"?

El artículo señala que el asistente aún puede leer las notas del atacante.

Datos Opacos: Si el atacante escribe, "El sistema está roto", el asistente puede copiar ese texto en un cuadro de "Comentario" o "Evidencia". Esto es como poner la nota en una vitrina de cristal. Es visible para que los humanos la lean, pero no tiene poder para abrir puertas o activar acciones. Es solo información, no una llave.

5. ¿Qué probaron?

Los autores probaron este sistema de varias maneras:

Simulaciones en Vivo: Utilizaron un "dojo" (un campo de entrenamiento) con 720 escenarios de la vida real donde los atacantes intentaron engañar a los agentes. El sistema bloqueó cada una de las acciones no autorizadas.
Agentes de Código: Probaron agentes que escriben código. Incluso cuando los atacantes intentaron inyectar comandos maliciosos, el sistema solo permitió las acciones que tenían las "llaves" correctas.
Resultado: En todas las pruebas, cero acciones no autorizadas lograron pasar la puerta. El sistema detuvo con éxito el "lavado de autoridad".

Resumen

CXI es un sistema que evita que los agentes de IA sean engañados. Asegura que, solo porque un agente de IA lea una instrucción peligrosa en una nota, eso no signifique que tenga el poder de hacerla. La IA solo puede actuar si un sistema de confianza le otorga explícitamente las llaves específicas para ese trabajo específico, en ese momento específico. Convierte al agente de IA de un lector ingenuo en un trabajador disciplinado que solo sigue órdenes verificadas.

Resumen Técnico: Integridad de Contexto a Ejecución (CXI) para Agentes de LLM

1. Declaración del Problema

Los agentes de Modelos de Lenguaje Extensos (LLM) operan cada vez más leyendo contexto escribible por el atacante (por ejemplo, registros de CI, comentarios en issues, fragmentos de recuperación, salidas de herramientas) para proponer acciones que desencadenan efectos secundarios en el mundo real (por ejemplo, escrituras de archivos, consultas a bases de datos, llamadas a API). El fallo de seguridad central identificado es el lavado de autoridad: un sistema donde el texto no confiable, que debería servir únicamente como evidencia, adquiere la autoridad para seleccionar herramientas, autorizar operaciones o parametrizar efectos secundarios privilegiados.

Los enfoques de seguridad actuales suelen depender de la validación de esquemas o de la confianza en la llamada completa, los cuales son insuficientes. Una llamada a una herramienta puede ser sintácticamente válida (estructura JSON correcta) mientras que sus campos semánticos (por ejemplo, tool, operation, approval_state) derivan de fuentes no confiables. El artículo argumenta que el límite de seguridad debe cambiar de "¿es el texto plausible?" a "¿posee el valor específico en cada campo protegido la autoridad necesaria para ejecutar este efecto secundario específico?".

2. Metodología: Integridad de Contexto a Ejecución (CXI)

CXI es un sistema de frontera de ejecución diseñado para mediar la transición de la propuesta del modelo a la ejecución del sumidero (sink). Enforce una política de admisión estricta donde un efecto secundario ocurre solo si tres componentes de autoridad distintos se vinculan al mismo manifiesto de acción canónico:

Autoridad de Campo: Los campos protegidos del sumidero (por ejemplo, rutas de archivos, nombres de herramientas) deben estar autorizados.
Autoridad de Efecto: Las cargas útiles interpretadas por el sumidero (por ejemplo, parches, SQL, comandos de shell) deben estar autorizadas para su efecto semántico específico.
Autoridad de Invocación: El evento de llamar al sumidero (incluyendo reintentos, procesamiento por lotes y programación) debe estar autorizado.

Mecanismos Principales

Liberaciones Tipadas (D): El contexto escribible no confiable ( $W$ ) no puede autorizar directamente los campos protegidos ( $X$ ). En su lugar, código confiable (desclasificadores) debe validar $W$ y acuñar una Liberación Tipada estrecha y de alcance de destino. Por ejemplo, una línea de registro puede ser validada para producir una liberación de FilePath para el argumento file_path, pero ese mismo texto no puede autorizar la selección de la tool.
Datos Opacos (O): El texto no confiable puede copiarse en "ranuras de datos opacos" para evidencia (por ejemplo, comentarios, registros) pero no conlleva autoridad. Si estos datos reingresan a una frontera de efecto secundario más tarde, se tratan nuevamente como contexto escribible.
Autorización de Efecto Exacto: Para cargas útiles constructivas (parches, SQL, YAML de CI), el sistema no solo verifica los bytes de la carga útil. Utiliza Adaptadores de Efecto para computar el efecto semántico exacto que el sumidero aplicará bajo un estado instantáneo (snapshot) confiable (por ejemplo, estado del repositorio, época de la política). La ejecución se vincula a este compromiso de efecto específico.
Puerta Vinculada al Manifiesto: Una puerta determinista canonicaliza la acción propuesta en un Manifiesto de Acción. Este manifiesto registra el nonce de la acción, los digests de evidencia de los campos, los digests de autorización de efecto y los digests de autoridad de llamada.
Capacidades de Invocación: La puerta consume una Capacidad de Invocación vinculada al manifiesto (un arrendamiento linealizable) antes de la ejecución. Esto evita ataques de repetición (replay attacks), reintentos no autorizados o cambios en la cardinalidad de procesamiento por lotes.

Procedencia y Evidencia

CXI rastrea la procedencia de la influencia, no solo el origen de los bytes.

Vía de Pesos Abiertos: Para modelos con acceso al estado interno (por ejemplo, vLLM), el sistema genera registros de evidencia de backend que vinculan la decodificación de campos protegidos a rangos de tokens específicos y máscaras de atención, asegurando que ningún contexto no confiable haya influido en la generación del campo protegido.
Vía de Host/API: Para APIs donde el estado interno está oculto, el sistema depende de la evidencia de construcción local al campo. Aquí, el host asegura que los escritores de campos solo vean el estado confiable y las liberaciones tipadas válidas, mientras que los datos opacos se excluyen del contexto del escritor.

3. Contribuciones Clave

El artículo define y evalúa tres contribuciones primarias:

Definición de CXI: Un requisito formal de que las selecciones protegidas, los efectos interpretados por el sumidero y los eventos de invocación deben cada uno portar autoridad para la misma acción canónica antes de que una propuesta del modelo sea ejecutable.
Sistema de Admisión Vinculado al Manifiesto: Un diseño que compone la evidencia de campos protegidos, la autorización de efecto exacto y las capacidades de invocación consumibles en una única decisión de sumidero, enforced por una puerta determinista.
Evaluación Exhaustiva: Una evaluación a través de rutas de proyección de campo de pesos abiertos, episodios en vivo de AgentDojo, un benchmark de efecto exacto para agentes de código, inyección de fallos en el libro mayor (ledger) y trazas de compatibilidad de host/API.

4. Resultados de la Evaluación

La evaluación separa la utilidad de la tarea (¿resolvió el agente el problema?) de la integridad de admisión (¿cruzó la autoridad no autorizada el límite?).

Episodios en Vivo de AgentDojo: A través de 720 episodios en vivo y 1,739 llamadas de LLM, CXI observó cero escapes de campo, efecto o invocación en admisiones protegidas.
Benchmark de Efecto Exacto para Agentes de Código: En 400 episodios de repositorio, el sistema produjo 231 finalizaciones de tareas seguras. Crucialmente, hubo cero escapes observados de campo, efecto o invocación.
- Nota sobre Fallos: Las no finalizaciones se atribuyeron a fallos de parseo (73 casos), falta de autorización de efecto (61 casos) o problemas de calidad de la tarea (35 casos), no a brechas de seguridad.
Presión de Propuesta: El sistema observó una significativa "presión de propuesta" donde los modelos intentaron seleccionar campos no autorizados (por ejemplo, 196/300 propuestas no autorizadas en entornos de utilidad adversaria). Sin embargo, la puerta bloqueó con éxito todos estos intentos, resultando en cero escapes ejecutados.
Fallos de Ledger: En pruebas de libro mayor vinculadas al manifiesto, el sistema rechazó con éxito las admisiones duplicadas y suprimió los gastos dobles (double-spends), confirmando la integridad del consumo de la capacidad de invocación.
Comparación con Baselines:
- Validación solo de esquema: Permitió el 100% de las ejecuciones no autorizadas (valores derivados de W llenaron campos protegidos).
- Aproximaciones de procedencia de rol de argumento: Fallaron al bloquear fallos de evento de llamada y de vinculación de backend.
- CXI: Bloqueó 20/20 casos de ataque mientras preservaba 6/6 casos de utilidad en los baselines de mecanismos.

5. Significado y Reivindicaciones

El artículo posiciona a CXI como una propiedad de sistemas concreta para sumideros mediados, en lugar de una solución general para todos los problemas de seguridad de agentes.

Frontera Explícita: CXI hace que la transición de contexto a ejecución sea explícita, verificable y de cierre seguro (fail-closed). No pretende que los validadores sean completos, que las tareas sean correctas o que los internos del proveedor sean observables; más bien, asegura que si una acción se ejecuta, es porque la cadena de autoridad específica para esa acción está completa.
Alcance Modesto: Los autores declaran explícitamente que la calidad de la tarea, la completitud del validador y la entrega de exactamente una vez externa son obligaciones separadas. CXI asegura que la autoridad para ejecutar sea la correcta, no que el contenido de la ejecución sea deseable o que el razonamiento del modelo sea sólido.
Centrado en la Política: El sistema depende de un trabajo de política confiable (clasificación de campos, contratos de desclasificador, validadores de efecto). No infiere la política faltante; si un campo no está clasificado o un sumidero no está mediado, la garantía no se sostiene.
Variación de la Evidencia: El artículo reconoce que la evidencia difiere según el régimen de despliegue. Los despliegues de pesos abiertos pueden probar la ejecución de backend mediante máscaras de atención, mientras que los despliegues de host/API solo pueden probar los límites de construcción observados por el host. Ambos, sin embargo, alimentan la misma lógica de puerta vinculada al manifiesto.

En resumen, CXI proporciona un mecanismo para prevenir el lavado de autoridad asegurando que el texto no confiable solo pueda influir en los efectos secundarios a través de canales explícitos, validados y delimitados (liberaciones tipadas, compromisos de efecto exacto y capacidades de invocación) que están vinculados a un único manifiesto de acción canónico.