Resumen Técnico: Proveniencia de Ruta de Puerta de Enlace Vinculada a Evidencia para Inferencia de LLM de Terceros

1. Declaración del Problema

Las puertas de enlace (gateways) de Modelos de Lenguaje de Gran Escala (LLM) de terceros se han convertido en infraestructura crítica para aplicaciones que utilizan múltiples proveedores de LLM externos. Estos sistemas gestionan el enrutamiento, la selección de modelos, los mecanismos de fallback, el streaming y la facturación. Sin embargo, existe una frontera de confianza fundamental: el operador de la puerta de enlace controla tanto la mediación de la ruta de inferencia como la autoría de los registros que describen dicha ruta.

En despliegues convencionales, aunque la Seguridad de la Capa de Transporte (TLS) protege los saltos de red, la puerta de enlace termina las solicitudes del cliente en texto plano. Esto permite que la puerta de enlace pueda:

• Leer los prompts y reescribir las solicitudes ascendentes (upstream).
• Sustituir endpoints o modelos sin el conocimiento del cliente.
• Alterar las respuestas de streaming o inyectar contenido.
• Falsificar registros de uso, facturación o proveniencia.

Los clientes que reciben únicamente una respuesta y un registro redactado por la puerta de enlace no pueden distinguir entre una mediación honesta y una sustitución de modelo oculta, un fallback no declarado, la reescritura de endpoints o la manipulación de streams. Este riesgo se amplifica en sistemas agénticos donde el texto devuelto puede activar llamadas a herramientas (tool calls) o ediciones de código. El problema central no es meramente quién puede leer el prompt, sino quién puede redactar el registro de la ruta de la puerta de enlace.

2. Metodología: Arquitectura Vinculada a Evidencia

El artículo propone una arquitectura de Puerta de Enlace Vinculada a Evidencia que separa el plano de negocio controlado por el operador de un plano de ejecución atestiguado remotamente. El componente central es el Entorno de Ejecución de la Puera de Enlace Atestiguado (AGR), que opera dentro de un Entorno de Ejecución Confiable (TEE, por sus siglas en inglés, como AWS Nitro Enclaves).

Componentes Arquitectónicos Clave

• Plano de Negocio: Gestiona la autenticación del cliente, la aplicación de cuotas, el reenvío de tráfico y el registro (logging). Reenvía ciphertext opaco, pero no puede descifrar las solicitudes ni acceder a las claves de los streams.
• Entorno de Ejecución de la Puerta de Enlace Atestiguado (AGR): Es el plano de ejecución de seguridad crítica que se ejecuta dentro de un TEE (por ejemplo, AWS Nitro Enclaves). Es el único componente permitido para:
  • Descifrar las solicitudes del cliente.
  • Aplicar políticas de enrutamiento y fallback por solicitud.
  • Construir las llamadas ascendentes hacia los proveedores de LLM.
  • Cifrar los flujos de respuesta (streams).
  • Firmar las Cadenas de Evidencia de Inferencia (IEC).

Flujo del Protocolo

1. Registro y Atestación: Una autoridad de lanzamiento firma un registro de mediciones de runtime y políticas aprobadas. Los clientes verifican este registro y solicitan una atestación fresca al AGR. El AGR proporciona una cita (quote) de hardware que vincula su medición, el hash de la política y las claves de cifrado/evidencia.
2. Contratos con Carga de Política: Los clientes envían solicitudes cifradas que contienen un Contrato de Inferencia (IC) que estrecha la política global para una solicitud específica (por ejemplo, modelos permitidos, bordes de fallback). El AGR calcula la política efectiva ($P_{eff} = P \cap IC$).
3. Ejecución Segura: El AGR descifra la solicitud, valida la política, selecciona la ruta/endpoint, realiza la llamada al proveedor ascendente. Cifra el flujo de respuesta y mantiene un compromiso (commitment) rotativo sobre los fragmentos cifrados.
4. Generación de Evidencia: El AGR firma una Cadena de Evencia de Inferencia (IEC). Este objeto vincula:
   • La atestación de runtime e identidad.
   • El hash de la política efectiva y del contrato.
   • Las decisiones de ruta y fallback.
   • La identidad del endpoint observado (verificación TLS).
   • Los compromisos de la transcripción del stream cifrado (StreamEv).
   • Metadatos de finalización.
5. Verificación: El cliente verifica la IEC contra la identidad del runtime atestiguado y recomputa el compromiso del stream para asegurar que el ciphertext recibido coincide con la evidencia firmada.

3. Contribuciones Clave

El artículo presenta cuatro contribuciones principales:

1. Identificación del Problema: Identifica el problema de la frontera de confianza de múltiples autoridades en las puertas de enlace de LLM de terceros, donde la redacción, el fallback, la admisión de endpoints y la autoría de la evidencia se concentran en un único servicio controlado por el operador.
2. Arquitectura: Presenta una arquitectura de planos divididos que traslada el descifrado, la aplicación de políticas, la construcción ascendente y la firma de evidencia a un runtime atestiguado (AGR), preservando las funciones del plano de negocio.
3. Mecanismos: Introduce contratos de inferencia con carga de política y cadenas de evidencia de inferencia que vinculan la atestación de runtime, la política por solicitud, las decisiones de ruta y las transcripciones de streams cifrados en una proveniencia verificable.
4. Implementación y Evaluación: Implementa un prototipo en Rust en AWS Nitro Enclaves y evalúa las sobrecargas de los mecanismos, la aplicación de rutas y los comportamientos de cierre seguro (fail-closed).

4. Resultados Experimentales

Los autores evaluaron el sistema utilizando un prototipo en Rust con proveedores simulados locales y endpoints reales de GPT.

• Sobrecarga (Overhead): En un entorno de simulación local determinista (concurrencia 16), la puerta de enlace vinculada a evidencia (B2) mostró una latencia p95 de 38.72 ms.
• Rendimiento de Nitro Enclave: Cuando el runtime se colocó en un Nitro Enclave (B3), la latencia p95 aumentó ligeramente a 46.2 ms (aproximadamente 1.1x el runtime local), con un rendimiento (throughput) que mantuvo el 95% de la base local. La sobrecarga fue dominada por el transporte, no por las operaciones criptográficas.
• Costos de Evidencia: Para una transcripción de 100 fragmentos, la construcción y recomputación de StreamEv costó aproximadamente 130 µs y 120 µs (p95), respectivamente. La firma y verificación de la IEC ocurrieron en decenas de microsegundos.
• Validación de Cierre Seguro (Fail-Closed): El sistema rechazó con éxito los intentos de manipulación en todos los escenarios de control negativo, incluyendo:
  • Manipulación de atestación/registro (PCR, nonce, modificación del registro).
  • Violaciones de integridad del canal (manipulación de clave/ciphertext).
  • Sustitución de ruta y fallback (cambios de modelo, omisión de fallbacks).
  • Violaciones de restricciones de endpoint.
  • Reescritura de metadatos de evidencia y manipulación de la transcripción del stream (eliminación, reordenamiento, replay).
  • Envenenamiento de la puerta de enlace (las llamadas a herramientas inyectadas fueron rechazadas).

5. Significancia y Reivindicaciones

El artículo afirma que esta arquitectura establece la autenticidad de la proveniencia de la ruta de la puerta de enlace. Permite a los clientes verificar que:

• La solicitud fue mediada por un runtime específico y medido.
• El enrutamiento, el fallback y la selección de endpoints se adhirieron a la política firmada.
• La transcripción del stream cifrado entregada coincide con el compromiso firmado.
• La evidencia no fue falsificada ni transferida desde un contexto de solicitud diferente.

Alcance y Limitaciones:
Los autores declaran explícitamente lo que el sistema no pretende hacer:

• No oculta los metadatos del tráfico (tiempo, tamaño de paquete, frecuencia).
• No previene la Denegación de Servicio (DoS).
• No prueba que el proveedor de LLM ascendente ejecutó el modelo correcto o generó contenido seguro (el proveedor permanece fuera del TCB).
• No protege contra proveedores de LLM maliciosos, contextos de RAG envenenados o violaciones de política a nivel de agente.
• Depende de la confiabilidad de la plataforma TEE, la raíz de atestación y el proceso de firma de lanzamiento.

La significancia radica en el cambio del modelo de confianza: los clientes ya no necesitan confiar en que el operador de la puerta de enlace medie tanto la ruta como la redacción de los registros. En su lugar, dependen de evidencia criptográfica vinculada a un runtime medido, asegurando que el enrutamiento no autorizado, los fallbacks ocultos, la manipulación de streams y los registros de facturación falsificados sean detectados y rechazados.