Right to History: A Sovereignty Kernel for Verifiable AI Agent Execution

1. El Problema: La Brecha de Responsabilidad en la Era de los Agentes de IA

El artículo identifica un vacío crítico en la infraestructura actual de los agentes de IA. Aunque estos agentes ejecutan acciones cada vez más complejas en nombre de los humanos (enviar correos, modificar archivos, ejecutar código), no existe ningún sistema que proporcione un registro inmutable, independiente y verificable de lo que realmente hicieron.

• Limitaciones actuales:
  • Los mecanismos de auditoría del sistema operativo (como auditd o eBPF) operan a nivel de llamadas al sistema (syscalls), no pueden atribuir acciones a la semántica del agente ni soportar la gobernanza humana en tiempo real.
  • Los sistemas de logs transparentes (como Certificate Transparency) existen pero no se han aplicado a las acciones de los agentes.
  • Marcos regulatorios emergentes, como la Ley de IA de la UE, exigen registros automáticos para sistemas de alto riesgo. Sin embargo, estos marcos asumen implícitamente un proveedor centralizado. Cuando los agentes se ejecutan en hardware personal, no hay "nube" ni proveedor que garantice la integridad de los registros.
• La consecuencia: Los usuarios carecen de la capacidad de probar a terceros qué hizo un agente, si fue autorizado y si se mantuvo dentro de sus límites declarados.

2. Metodología y Marco Teórico

El autor propone el "Derecho a la Historia": el principio de que los individuos tienen derecho a un registro completo, verificable y a prueba de manipulaciones de cada acción realizada por un agente de IA en su propio hardware.

Para formalizar esto, se presenta PunkGo, un kernel de soberanía escrito en Rust que actúa como la Base de Computación Confiable (TCB). El diseño se basa en los siguientes pilares:

A. Modelo de Amenazas y Confianza

• TCB (Trusted Computing Base): Solo el kernel de PunkGo es confiable.
• No confiable: Los agentes (LLMs), herramientas externas y la capa de comunicación.
• Suposición clave: Los agentes son no deterministas y potencialmente maliciosos; el sistema no confía en su comportamiento, sino en el registro que el kernel hace de dicho comportamiento.

B. Los Cinco Invariantes del Sistema

El núcleo teórico del paper define cinco invariantes formales que garantizan la seguridad:

1. Solo Adición (Append-Only): El registro de eventos es inmutable. Una vez escrito, no se puede modificar ni borrar.
2. Completitud: Toda acción que pasa la verificación de límites y tiene energía suficiente se registra.
3. Integridad: La raíz del árbol de Merkle compromete el contenido actual del registro, permitiendo pruebas de inclusión y consistencia.
4. Aplicación de Límites (Boundary Enforcement): Los agentes no pueden actuar fuera de sus objetivos declarados (writable_targets).
5. Conservación de Energía: Un modelo económico que limita la tasa de acciones para prevenir ataques de denegación de servicio (DoS) y desincentivar la exploración de límites.

C. Mecanismos Técnicos Clave

• Logs de Árbol de Merkle (RFC 6962): Utiliza la misma estructura que Certificate Transparency para generar pruebas de inclusión de $O(\log n)$ y consistencia.
• Control de Acceso Basado en Capacidades: Implementa el principio de menor privilegio. Los agentes solo pueden actuar sobre objetivos específicos que les fueron asignados.
• Modelo de Energía: Cada acción tiene un costo. Los agentes reciben un presupuesto de energía basado en la capacidad de hardware. Esto actúa como un freno económico contra el abuso.
• Mecanismo hold_on (Aprobación Humana): Para acciones de alto riesgo, el kernel puede pausar la ejecución y solicitar aprobación humana. Si el agente intenta eludir esto o falla, se le cobra un "costo de compromiso" (20% de la energía reservada), disuadiendo intentos de prueba de límites.

3. Contribuciones Principales

1. Marco Formal (C1): Un modelo matemático que define primitivas (Actor, Energía, Estado) y acciones atómicas, junto con pruebas estructuradas de los cinco invariantes de seguridad.
2. Implementación PunkGo (C2): Un kernel en Rust que unifica logs de auditoría criptográfica, aislamiento de capacidades y gobernanza de energía. A diferencia de sistemas como AIOS, aquí el TCB es el kernel verificado, no el LLM.
3. Inversión de Soberanía (C3): Cambia el enfoque de "cómo los agentes mantienen su soberanía frente a los humanos" a "cómo los humanos mantienen la soberanía sobre los agentes".
4. Validación (C4): Implementación funcional y pruebas de estrés que confirman que los invariantes se mantienen bajo ataques adversarios.

4. Resultados de Evaluación

El sistema fue evaluado en un entorno de hardware moderno (Intel Core i7-14700K) con una implementación en modo release.

• Latencia: La latencia mediana por acción es de < 1.3 ms (aprox. 665 µs para observaciones, ~1.2 ms para mutaciones y ejecución).
• Rendimiento (Throughput): Aproximadamente 400 acciones por segundo en un flujo secuencial.
• Pruebas de Merkle:
  • Tamaño de la prueba de inclusión: 448 bytes para 10,000 entradas (14 hashes).
  • Tiempo de generación de prueba: ~19 ms para 10,000 entradas (actualmente limitado por la carga de nodos de hash, con potencial de optimización a $O(\log n)$).
• Verificación de Invariantes: Se realizaron pruebas adversarias para cada invariante (modificación directa de la base de datos, intentos de exceder límites, agotamiento de presupuesto, etc.). Todos los invariantes se mantuvieron válidos, detectando manipulaciones en milisegundos.

5. Significado e Impacto

El artículo propone un cambio de paradigma en la infraestructura de agentes de IA:

• Cumplimiento Regulatorio: Permite a los usuarios individuales cumplir con regulaciones como la Ley de IA de la UE (Artículos 12 y 14) al proporcionar logs auditables sin depender de proveedores centralizados.
• Seguridad por Diseño: Al colocar el kernel como la única fuente de verdad y usar criptografía para la integridad, se cierra la brecha entre la "capa de política" (lo que se permite) y la "capa de evidencia" (lo que realmente ocurrió).
• Soberanía Computacional: Extiende el concepto de soberanía de datos (Local-First Software) a la soberanía del historial computacional. Los usuarios no solo poseen sus datos, sino que poseen la prueba verificable de cómo sus agentes manipularon esos datos.
• Arquitectura Escalable: Demuestra que es posible integrar auditoría criptográfica de alto rendimiento en un kernel de usuario sin sacrificar la latencia, haciendo viable la verificación en tiempo real para agentes personales.

En conclusión, PunkGo no es solo una herramienta de registro, sino una afirmación arquitectónica de que la verificación de la historia de los agentes debe ser un derecho fundamental y un componente central del sistema, no una característica opcional añadida posteriormente.