AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

El artículo presenta AEX, una extensión de atestación no intrusiva para APIs de modelos de lenguaje grandes que añade un objeto firmado para vincular criptográficamente las solicitudes de los clientes con sus respuestas o líneas de origen, garantizando así la integridad y la procedencia de los datos incluso en entornos con intermediarios de confianza o flujos de transmisión.

Lo esencial

Imagina que has pedido un plato de comida a un restaurante muy famoso (el modelo de Inteligencia Artificial). El camarero (la API) te trae el plato. Pero, ¿cómo sabes con certeza que:

1. El plato que tienes en la mesa es exactamente lo que pediste en el menú?
2. Nadie en la cocina le cambió los ingredientes a mitad del camino?
3. El plato no fue robado de otra mesa o preparado por un cocinero desconocido?

Hoy en día, con las Inteligencias Artificiales (como ChatGPT), confiamos ciegamente en que lo que nos devuelve la empresa es lo que realmente pidió el usuario. Pero recientemente se ha descubierto que hay "restaurante fantasma" (APIs no oficiales) que dicen ser el original pero sirven comida diferente, o que intermediarios cambian el pedido sin avisar.

Aquí es donde entra AEX.

¿Qué es AEX? (La "Etiqueta de Seguridad Sellada")

AEX es como un sistema de precinto de seguridad digital que se pega en la respuesta de la Inteligencia Artificial. No cambia la comida (el texto que te devuelve), no cambia el menú (la petición), ni obliga a la cocina a cambiar su forma de trabajar. Simplemente, añade una etiqueta sellada y firmada en la parte superior del plato.

Esta etiqueta dice: "Yo, el Chef Confiable, certifico que este plato específico es el resultado exacto de este pedido específico, y nadie lo ha tocado desde que salió de mi cocina hasta que llegó a tu mesa."

¿Cómo funciona? (Con analogías sencillas)

1. La "Huella Digital" del Pedido (Compromiso de la Petición)

Cuando pides algo, AEX toma tu pedido y le saca una "huella digital" única (un código matemático).

• El problema: A veces, un intermediario (como un traductor o un filtro de seguridad) cambia tu pedido ligeramente (por ejemplo, añade un código de seguimiento).
• La solución de AEX: Permite que tú, el cliente, elijas qué tan estricto quieres ser. Puedes decir: "Solo quiero que se fijen en el texto principal, ignora los códigos de seguimiento" o "Quiero que todo sea idéntico, hasta el último punto". Si alguien cambia algo que no debió, la huella digital no coincidirá y la etiqueta se romperá.

2. La "Cinta de Seguridad" para Mensajes Largos (Streaming)

A veces, la IA no te da la respuesta de golpe, sino palabra por palabra (como si te la fuera dictando).

• El problema: ¿Qué pasa si alguien borra una palabra, añade una mentira en medio o corta la frase antes de tiempo?
• La solución de AEX: Imagina que cada palabra que sale tiene un pequeño eslabón de una cadena. Si alguien intenta cambiar una palabra en medio, rompe la cadena. AEX verifica que la cadena esté completa y en orden. Si la cadena se corta antes de tiempo, la etiqueta te avisa: "¡Ojo! La historia se cortó antes de terminar".

3. La "Cadena de Custodia" (Cuando alguien toca el plato)

A veces, un intermediario confiable (como un filtro de seguridad) necesita editar la respuesta (por ejemplo, borrar una palabra ofensiva o resumir un texto largo).

• El problema: Si alguien edita el texto, la huella digital original ya no sirve. ¿Cómo sabemos que la edición fue legítima?
• La solución de AEX: AEX crea una cadena de custodia firmada.
  • El Chef original firma el plato base.
  • El Filtro de Seguridad (intermediario) firma un recibo que dice: "Tomé el plato del Chef, le quité la salsa picante y lo entregué así".
  • Tú recibes el plato modificado, pero con una etiqueta que muestra toda la historia: "Este plato vino del Chef X, pasó por el Filtro Y, y fue modificado legalmente".
  • Si un hacker intenta cambiar el plato sin firmar el recibo, la etiqueta se rompe y te das cuenta.

¿Qué NO hace AEX? (Lo que no es magia)

Es importante no confundirse. AEX no es un detector de mentiras sobre el contenido:

• No te dice si la IA inventó un hecho falso (alucinación).
• No te dice si la IA usó un modelo diferente al que dice usar (aunque ayuda a detectar si la respuesta no coincide con el pedido).
• No te dice si la IA tiene "pensamientos ocultos" o secretos.

AEX solo garantiza la integridad del viaje: que el pedido que saliste y la respuesta que recibiste están vinculados matemáticamente y que nadie los manipuló en el camino sin permiso.

En resumen

AEX es como poner un sello de garantía oficial en cada interacción con una Inteligencia Artificial.

• Si el sello está intacto, sabes que la respuesta es auténtica y no ha sido manipulada.
• Si alguien intentó cambiar el pedido o la respuesta, el sello se rompe y te avisa.
• Si hubo cambios legítimos (como filtros de seguridad), el sello muestra quién los hizo y cómo, manteniendo la confianza.

Es una herramienta para que, en un mundo donde las IAs pueden ser manipuladas o reemplazadas por "impostores", tú tengas la certeza de que lo que ves es exactamente lo que pediste y lo que el proveedor prometió entregar.

Resumen técnico

Resumen Técnico: AEX (Attestation EXtension)

1. El Problema

El acceso a los Modelos de Lenguaje Grande (LLM) alojados se realiza cada vez más a través de APIs remotas. Sin embargo, la frontera de la API ofrece poca evidencia directa de que la salida devuelta corresponda realmente a la solicitud visible del cliente.

• Vulnerabilidades actuales: Auditorías recientes de "Shadow APIs" (endpoints no oficiales o intermediarios) han demostrado que estos servicios pueden desviarse del comportamiento reclamado, con divergencias de utilidad de hasta el 47% y fallos en la verificación de huellas dactilares.
• Limitaciones de las soluciones existentes:
  • Las técnicas de fingerprinting y pruebas de igualdad de modelos son inferenciales e incompletas.
  • Los esquemas de inferencia verificable (como SVIP) requieren exponer evidencia interna del modelo.
  • La atestación basada en Entornos de Ejecución de Confianza (TEE) garantiza el entorno de ejecución, pero no necesariamente la integridad de la transacción de solicitud/respuesta a nivel de protocolo de aplicación.
• La brecha: Existe una necesidad urgente de un mecanismo que vincule directamente, de forma verificable y en línea, una solicitud específica del cliente con una respuesta específica (o secuencia de transmisión) sin alterar la semántica de la API existente.

2. Metodología y Diseño

El artículo propone AEX, una extensión de atestación no intrusiva diseñada para APIs de LLM basadas en JSON. Su diseño se centra en la frontera de la API y cumple con ocho restricciones clave, incluyendo la preservación de la semántica de solicitud/respuesta, el soporte para transmisión (streaming) y la distinción entre mutaciones no autorizadas y reescrituras confiables.

Componentes Clave del Protocolo:

• Representación Canónica: Utiliza el Esquema de Canonicalización JSON (JCS) para garantizar que las operaciones criptográficas sean invariantes ante cambios en el orden de campos o espacios en blanco.
• Objeto de Atestación Desacoplado: AEX añade un campo de nivel superior llamado attestation a la respuesta JSON. Este objeto contiene la evidencia criptográfica sin alterar el cuerpo de negocio (payload) de la API.
• Compromisos Criptográficos (Commitments):
  • Compromiso de Solicitud: Un hash de la proyección visible del cliente de la solicitud.
  • Compromiso de Solicitud Efectiva: Opcional, para capturar solicitudes modificadas por intermediarios de confianza (ej. inyección de políticas).
  • Compromiso de Salida: Un hash que cubre la respuesta completa o una cadena de transmisión autenticada.
• Modos de Transmisión (Streaming):
  • AEX distingue entre Modo de Prefijo de Flujo Fuente (donde se pueden verificar prefijos de un flujo no transformado mediante checkpoints) y Modo de Linaje de Salida Completa (donde la salida final ha sido transformada, reempaquetada o agregada por intermediarios de confianza).
  • Estos dos modos son mutuamente excluyentes para evitar confusiones sobre la integridad de los datos parciales.
• Cadenas de Transformación Confiable:
  • Recepciones de Transformación de Solicitud: Permiten a intermediarios firmados demostrar cómo transformaron la solicitud original en una solicitud efectiva.
  • Recepciones de Linaje de Salida: Permiten rastrear cómo una salida original firmada por un emisor fuente se transformó (ej. de streaming a objeto único, o redacción de contenido) hasta la salida final entregada al cliente.
• Descubrimiento de Claves: Utiliza un modelo basado en JWKS (JSON Web Key Set) publicado en una URL conocida del emisor, similar a los estándares web actuales.

3. Contribuciones Clave

1. Formulación del Problema: Define claramente el problema de la atestación en la frontera de la API para servicios de LLM alojados, basándose en la evidencia práctica de las Shadow APIs.
2. Diseño de Protocolo AEX: Presenta una extensión no invasiva que incluye compromisos de solicitud, modos de vinculación explícitos (full, top_level_exclude, top_level_include) y metadatos de linaje sensibles al modo de salida.
3. Mecanismos Específicos para LLM:
   • Cadena de hash de transmisión de doble ancla.
   • Cadenas de transformación de solicitud explícitas para intermediarios de confianza.
   • Modelo de recibos de salida fuente / transformación de salida para reescrituras confiables.
4. Análisis de Seguridad y Privacidad: Evalúa el modelo de amenazas, incluyendo adversarios activos en la red, intermediarios no confiables y la importancia de la política de confianza del verificador. Aclara qué AEX no prueba (veracidad factual, ausencia de prompts ocultos).
5. Prototipo y Validación: Proporciona un prototipo de referencia en TypeScript compatible con la API de chat de OpenAI, junto con pruebas de conformidad automatizadas y micro-benchmarks locales.

4. Resultados y Validación

• Implementación: Se desarrolló un prototipo funcional que simula un entorno de prueba con un cliente, un gateway (verificador), proxies de confianza (que reescriben solicitudes) y un proveedor de modelos.
• Pruebas Automatizadas:
  • Se ejecutaron 29 pruebas unitarias y 25 pruebas de integración que cubrieron la vinculación de solicitudes, emisión de atestaciones, verificación de cadenas de transmisión y estados de fallo (ej. truncamiento, manipulación).
  • Todas las pruebas pasaron, validando la corrección de los estados de verificación (ej. verified_complete, tampered, truncated).
• Rendimiento (Micro-benchmarks):
  • Las pruebas locales mostraron una sobrecarga mínima. En el caso de éxito sin transmisión, la latencia de verificación del gateway fue de 0.495 ms.
  • En escenarios de transmisión con checkpoints, la verificación del gateway fue de 0.843 ms.
  • En escenarios con cadenas de transformación de solicitud y linaje de salida, la latencia de verificación se mantuvo por debajo de 1.5 ms, demostrando que el protocolo es viable para implementaciones en tiempo real.
• Escenarios Probados: Se validaron correctamente casos de éxito, reescritura de solicitudes por intermediarios, transformación de flujos a objetos no streaming, y detección de manipulación de datos en tránsito.

5. Significado e Impacto

• Puente de Confianza Práctico: AEX ofrece una solución "lista para usar" que no requiere cambiar la infraestructura subyacente de los proveedores de LLM ni alterar el formato de las APIs existentes (como la de OpenAI).
• Distinción Crítica: Resuelve el dilema de tratar toda modificación como un fallo o ignorarla por completo. AEX permite distinguir entre mutación silenciosa (ataque) y reescritura explícita y firmada (operación confiable de intermediarios como gateways de seguridad o logging).
• Complementariedad: No reemplaza la atestación de TEE ni la auditoría de modelos, sino que se integra con ellos. Mientras TEE prueba dónde se ejecutó el código, AEX prueba qué solicitud y respuesta se intercambiaron en la capa de aplicación.
• Viabilidad de Despliegue: Al ser no intrusivo y compatible con estándares web existentes (JWKS, JSON, SSE), AEX facilita la adopción incremental por parte de SDKs, gateways y proveedores, abordando directamente la fragilidad de la frontera de confianza en la era de las APIs de IA.

En conclusión, AEX establece un nuevo estándar para la integridad y la procedencia en las transacciones de LLM, proporcionando evidencia criptográfica verificable de que una salida específica es el resultado legítimo de una solicitud específica, incluso a través de cadenas complejas de intermediarios de confianza.