Resumen Técnico: Frontera de Aseguramiento Soberano para Infraestructura Agéntica

1. Declaración del Problema

La integración de agentes de Modelos de Lenguaje Extensos (LLM) en flujos de trabajo operativos introduce una brecha crítica de autorización en el plano de control. Mientras que los agentes pueden proponer mutaciones de alto impacto en recursos de producción (por ejemplo, escalar nodos, rotar credenciales, modificar grupos de seguridad de red), los mecanismos de seguridad existentes son insufentes para gobernar estos sistemas de razonamiento no deterministas.

• Estático vs. Dinámico: La Gestión de Identidad y Acceso (IAM) tradicional y los motores de políticas imponen permisos estáticos o cumplimiento estructural, pero no pueden determinar si una propuesta autónoma está semánticamente justificada por evidencia en vivo.
• Limitaciones Post-Hoc: Los registros de auditoría y los protocolos de consenso registran acciones o acuerdan transiciones de estado solo después de la ejecución o sin evaluar la seguridad semántica de la transición.
• Acumulación de Riesgo: Las acciones de los agentes, aunque individualmente plausibles, pueden acumularse en fallos sistémicos, incluyendo interrupciones de disponibilidad, exposición de datos, elusión de políticas y pérdida de contexto forense.
• La Brecha Central: No existe una frontera de admisión en tiempo de ejecución que convierta la propuesta de un agente en autoridad de ejecución solo después de haber sido vinculada a evidencia, política y estado de revocación.

2. Metodología: La Frontera de Aseguramiento Soberano (SAB)

El artículo propone la Frontera de Aseguramiento Soberano (SAB), una frontera de admisión en tiempo de ejecución vinculada a certificados que se interpone entre el razonamiento del agente y la mutación de la infraestructura. La SAB opera bajo el principio de que la institución retiene el control local sobre la política, la evidencia y la autoridad de ejecución, tratando al entorno de ejecución del agente como un proponente no confiable.

2.1 Arquitectura: Modelo de Esclusa–Corredor (Airlock–Broker)

La SAB separa el sistema en dos capas distintas:

1. Entorno de Ejecución del Agente No Confiable: Genera propuestas pero no posee credenciales permanentes ni privilegios de ejecución directa.
2. Corredor de Ejecución Soberano Confiable: Es la única entidad permitida para invocar las API de infraestructura. Ejecuta mutaciones exclusivamente tras verificar un Certificado de Aseguramiento Soberano ($\Omega$) firmado.

El pipeline de admisión consta de las siguientes etapas:

• Compilación de Contrato: Los comandos brutos del agente se normalizan en un Contrato de Ejecución ($C$) fuertemente tipado, que define objetivos, precondiciones, postcondiciones y reversiones (rollbacks).
• Vinculación de Evidencia: Un recolector de evidencia ensambla telemetría, registros y tickets para computar un digest criptográfico $H(E)$ del estado del sistema en el momento de la decisión.
• Puntuación de Consecuencias: Un evaluador calcula una métrica de riesgo $R(C)$ basada en el radio de explosión (blast radius), expansión de privilegios, sensibilidad de los datos, irreversibilidad e incertidumbre. Esto determina el Nivel de Autonomía ($L(C)$) (que oscila desde L0 de Asesoría hasta L5 de Prohibición).
• Enrutamiento de la Ruta de Certificación: Basándose en $L(C)$ y la política, el contrato se enruta a través de una ruta específica (por ejemplo, PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman).
  • Aseguramiento de Quórum Semántico (SQA): Una malla de validadores externos no confiables proporciona atestaciones firmadas ($\Gamma_{SQA}$) respecto a la admisibilidad semántica de la acción.
  • Aprobación Humana: Para acciones de alto riesgo, los operadores proporcionan aprobaciones de firma múltiple vinculadas al contrato y la evidencia específicos.
• Emisión de Certificado: La Esclusa de Aseguramiento (parte de la Base de Computación Confiable o TCB) verifica todos los requisitos de la ruta y emite un Certificado de Aseguramiento Soberano ($\Omega$) firmado.
  • $\Omega$ contiene: $C$, $H(E)$, $R(C)$, $L(C)$, ruta de certificación, firmas de validadores, identidad de ejecución ($ID_{exec}$), ventana de validez ($T_{valid}$), versión de política ($P_{ver}$) y época de revocación ($\rho_{rev}$).
• Verificación del Corredor: Antes de la ejecución, el Corredor Soberano verifica la firma de $\Omega$, comprueba la época de revocación, valida la versión de la política y realiza una comprobación de deriva de estado ($\Phi_{drift}$) para asegurar que el estado en vivo no haya desviado de la evidencia vinculada $E$.

2.2 Invariantes Formales

La SAB impone cinco invariantes de la frontera de autoridad:

1. Desacoplamiento de Propuesta-Ejecución: Ninguna propuesta de agente dispara una mutación sin la admisión de la esclusa.
2. Ejecución Vinculada al Certificado: La ejecución ocurre solo si el corredor verifica un $\Omega$ válido que contenga el contrato específico $C$.
3. Vinculación de Evidencia: Las aprobaciones y atestaciones están vinculadas criptográficamente a $C$ y $H(E)$, evitando su reutilización en diferentes contextos.
4. Selección de Ruta Monótona: Los contratos solo se admiten si se satisfacen todos los requisitos de su ruta de certificación seleccionada; las rutas de menor aseguramiento no pueden invalidar los requisitos de mayor riesgo.
5. Autoridad Efímera: Los certificados son rechazados si la época de revocación es obsoleta o si el tiempo de ejecución cae fuera de la ventana de validez.

3. Contribuciones Clave

El artículo presenta cuatro contribuciones principales:

1. Admisión Vinculada a Certificados: Define una frontera de admisión en tiempo de ejecución que convierte la autoridad de ejecución autónoma de un permiso ambiental en un artefacto revocable y vinculado a evidencia.
2. Arquitectura de Esclusa–Corredor: Introduce los componentes específicos (Contrato $C$, Digest de Evidencia $H(E)$, Certificado $\Omega$ y Corredor Soberano) que separan la propuesta, la admisión y la ejecución.
3. Certificación Consciente de Consecuencias: Formaliza la puntuación de consecuencias, los niveles de autonomía, las rutas de certificación y los mecanismos de revocación que permiten la escalada, el rechazo y la suspensión antes de la ejecución.
4. Prototipo y Evaluación de Factibilidad: Implementa un prototipo en Go que demuestra la factibilidad del sistema, incluyendo la serialización de contratos, verificaciones de política OPA/Rego, firma Ed25519 y un libro de contabilidad respaldado por PostgreSQL.

4. Resultados y Evaluación

Los autores evaluaron el prototipo utilizando 500 contratos de ejecución etiquetados a través de 2,500 intentos de admisión en un banco de pruebas local.

• Latencia:
  • Admisión de solo política: ~1.84 ms (p50).
  • Admisión SQA (con malla de validadores): ~185 ms (p50) / 380 ms (p95).
  • Verificación del Corredor: ~0.15 ms (p50).
  • Propagación de revocación: ~12.4 ms (p95).
• Precisión:
  • Precisión de enrutamiento (acuerdo con un oráculo etiquetado por expertos): 96.8%.
  • Tasa de admisión insegura: 0.4%.
• Eficiencia:
  • Reducción de aprobación humana: 68.2% en comparación con una cola gestionada únicamente por humanos.
  • Sobrecarga de almacenamiento de certificados: ~3.4 KB por acción.
• Rejugabilidad: El 100% de las entradas del libro de contabilidad eran rejugables con el contexto del esquema.

Los resultados indican que la sobrecarga del plano de control es factible en una sola estación de trabajo, sacrificando latencia por aseguramiento y rejugabilidad.

5. Significado y Reivindicaciones

El artículo sostiene que la SAB aborda un vacío de autorización específico sin reemplazar las capas de seguridad existentes.

• Soberanía Operativa: La SAB define la soberanía como la retención por parte de la institución del control local sobre la evaluación de políticas, la retención de evidencia, las claves de firma y la autoridad de ejecución. Los modelos externos se restringen a la generación de propuestas y no pueden eludir la certificación local.
• Componibilidad: La SAB no es un reemplazo para IAM, verificación formal, protocolos de consenso o revisión humana. En su lugar, compone estos mecanismos en una frontera de admisión a nivel de sistema. Trata la autoridad de ejecución delegada como un artefacto de tiempo de ejecución vinculado a un certificado, vinculado a evidencia, revocable y rejugable.
• Mitigación de Riesgos: Al desacoplar la generación de propuestas de la ejecución y vincular la ejecución a evidencia fresca y política activa, la SAB evita que el razonamiento autónomo por sí solo pueda mutar el estado, mitigando así los riesgos de fallos sistémicos, filtración de datos y elusión de políticas.

Los autores mantienen una postura modesta, reconociendo que la SAB depende de la integridad de la Base de Computación Confiable (TCB), la frescura de la evidencia externa y la calibración de los validadores. Señalan que los resultados del prototipo dependen de la carga de trabajo y no garantizan un rendimiento general, sugiriendo una estrategia de despliegue incremental comenzando por dominios de alta consecuencia.