OpenKedge: Governing Agentic Mutation with Execution-Bound Safety and Evidence Chains

El artículo presenta OpenKedge, un protocolo que garantiza la seguridad de los sistemas de agentes autónomos al transformar las mutaciones de estado en procesos gobernados mediante propuestas de intención declarativas, contratos de ejecución estrictos y una cadena de evidencia criptográfica que permite la auditoría determinista y la prevención de acciones inseguras.

Lo esencial

Imagina que estás construyendo una casa muy compleja con un equipo de robots autónomos (Inteligencias Artificiales) y algunos humanos.

En el sistema actual (el que usamos hoy), le dices a un robot: "Por favor, quita esa pared". El robot lo hace inmediatamente, sin pensar si hay alguien detrás de la pared, si la pared sostiene el techo o si otro robot acaba de poner una viga allí. Si el robot se equivoca o "alucina" (se confunde), la casa se cae. Es como darle las llaves de la casa a un robot que nunca ha dormido y que a veces cree que ve cosas que no existen.

OpenKedge es un nuevo sistema de seguridad que cambia las reglas del juego. En lugar de dejar que los robots actúen directamente, OpenKedge actúa como un jefe de obra supremo y un juez estricto que interviene antes de que se mueva un solo ladrillo.

Aquí te explico cómo funciona, paso a paso, con analogías sencillas:

1. La Propuesta de Intención (El "Qué quiero hacer")

En lugar de que el robot ejecute la orden directamente, primero debe escribir una propuesta formal.

• Analogía: Imagina que el robot no puede simplemente apretar un botón para demoler. Primero debe llenar un formulario que dice: "Quiero demoler la pared del norte porque creo que no es necesaria".
• La magia: El sistema no ejecuta nada todavía. Solo recibe la intención.

2. El Juez y el Contexto (La "Evaluación")

Aquí entra el cerebro de OpenKedge. Antes de aprobar la propuesta, el sistema revisa tres cosas:

• Contexto Global: ¿Hay alguien en la pared? ¿Es de noche? ¿Otro robot está trabajando ahí?
• Políticas: ¿Está permitido demoler paredes sin permiso humano?
• Confianza: ¿Este robot es confiable o ha estado actuando raro últimamente?
• Analogía: Es como un guardia de seguridad en un aeropuerto. El robot (el pasajero) dice: "Quiero pasar". El guardia (OpenKedge) revisa tu pasaporte (identidad), tu destino (intención) y si hay una alerta de terrorismo (conflicto con otros robots). Si todo está bien, te da un pase. Si no, te detiene.

3. El Contrato de Ejecución (El "Permiso Limitado")

Si la propuesta es aprobada, el sistema no le devuelve las llaves maestras al robot. En su lugar, le crea un contrato temporal y limitado.

• Analogía: Imagina que el robot necesita abrir una caja fuerte. En lugar de darle la llave maestra de todo el banco, OpenKedge le da una llave de plástico temporal que solo abre esa caja específica, solo por 5 minutos, y solo para girar la manija una vez.
• Seguridad: Si el robot se vuelve loco y trata de abrir otra caja o quedarse más tiempo, la llave simplemente no funciona. El daño está "encerrado" en una jaula muy pequeña.

4. La Cadena de Evidencia (El "Libro de Actas Inmortal")

Este es el corazón de OpenKedge. Cada paso, desde la idea del robot hasta la acción final, se escribe en un libro de actas digital que no se puede borrar ni alterar.

• Analogía: Es como un cine de seguridad que graba todo. No solo graba qué pasó (se rompió la pared), sino por qué se decidió hacerlo (el robot dijo X, el juez aprobó Y, el contexto era Z).
• Por qué importa: Si algo sale mal, puedes revisar el video y decir: "El robot no estaba loco; el sistema aprobó mal la orden porque le faltó información". O al revés: "El robot se equivocó, pero el sistema lo detuvo a tiempo". Todo es transparente y auditable.

¿Por qué es esto un cambio gigante?

Hoy en día, confiamos en que los robots son "buenos" y que las órdenes que dan son correctas. OpenKedge dice: "No confíes en nadie. Verifica todo".

• Antes: Un robot dice "Borra la base de datos" y la borra. Si se equivocó, la empresa quiebra.
• Con OpenKedge: El robot dice "Quiero borrar la base de datos". El sistema revisa: "¿Hay tráfico? ¿Hay copias de seguridad? ¿Es un humano quien lo pide?". Si la respuesta es "No, es peligroso", el sistema bloquea la acción antes de que ocurra. Si la respuesta es "Sí, es seguro", le da al robot una llave temporal para hacerlo, y graba todo el proceso.

En resumen

OpenKedge transforma a la Inteligencia Artificial de ser un conductor borracho con las llaves del coche a ser un pasajero que pide ir a un destino, mientras un chofer experto y un sistema de navegación deciden si el viaje es seguro, toman el volante, limitan la velocidad y graban el viaje entero para que nadie pueda decir "no fue mi culpa".

Es la forma de permitir que las máquinas trabajen rápido y autónomamente, sin tener miedo de que se destruyan la casa mientras juegan.

Resumen técnico

Resumen Técnico: OpenKedge

1. El Problema: La Falla Fundamental en Arquitecturas Centradas en API

El artículo identifica una vulnerabilidad crítica en los sistemas modernos operados por agentes de IA autónomos. Las arquitecturas actuales dependen de APIs pasivas que ejecutan mutaciones de estado (cambios en la base de datos, infraestructura en la nube, etc.) de manera inmediata tras la invocación, asumiendo implícitamente que el llamador es:

• Determinista y correcto.
• Consciente del contexto global.
• Aislado de otros actores.

En entornos de agentes probabilísticos (como LLMs), estas suposiciones fallan, lo que genera:

• Ceguera Contextual: Los agentes ejecutan acciones válidas sintácticamente pero destructivas debido a datos desactualizados o dependencias ocultas.
• Conflictos Multi-Agente: Múltiples actores (humanos y AI) intentan actualizar el mismo recurso simultáneamente sin un mecanismo de resolución determinista, causando estados corruptos u oscilantes.
• Mutaciones Inseguras: Alucinaciones de los modelos pueden generar comandos catastróficos (ej. borrar una base de datos en producción) que las APIs tradicionales aceptan sin cuestionar el "por qué" o el "cuándo".
• Falta de Trazabilidad: Las arquitecturas actuales carecen de un registro end-to-end que vincule la intención original con la ejecución física, dificultando la auditoría y el razonamiento post-incidente.

2. Metodología: El Protocolo OpenKedge

OpenKedge propone un cambio de paradigma: transformar la mutación de un efecto secundario inmediato de una llamada a API a un proceso gobernado basado en intenciones declarativas. La arquitectura se basa en cuatro pilares fundamentales:

1. Propuestas de Intención (Intent Proposals):

   • En lugar de ejecutar comandos directamente, los agentes deben someter propuestas de intención declarativas.
   • El sistema evalúa estas propuestas contra el estado global del sistema, señales temporales y políticas estrictas antes de permitir cualquier ejecución.

2. Contratos de Ejecución y Identidades Orientadas a Tareas:

   • Las intenciones aprobadas se compilan en contratos de ejecución explícitos: $C = (a, r, t)$, donde $a$ es la acción permitida, $r$ el alcance de recursos y $t$ la validez temporal.
   • Estos contratos se hacen cumplir mediante identidades efímeras y orientadas a tareas. En lugar de usar cuentas de servicio con permisos amplios, se generan credenciales temporales que están estrictamente limitadas al contrato aprobado, impidiendo la escalada de privilegios o acciones fuera de alcance.

3. Cadena de Evidencia de Intención a Ejecución (IEEC):

   • Se introduce una estructura de datos inmutable y encriptada que vincula criptográficamente: la intención, el contexto recuperado, la decisión de la política, los límites de ejecución y el resultado final.
   • Esto crea un linaje causal verificable, permitiendo reconstruir determinísticamente por qué y cómo se autorizó cada cambio.

4. Estado Derivado de Eventos (Event Sourcing):

   • El estado del sistema no se sobrescribe; se deriva determinísticamente de un registro de eventos inmutable. Esto garantiza la auditabilidad completa y la capacidad de reproducir estados históricos para depuración o entrenamiento.

3. Contribuciones Clave

El artículo presenta tres contribuciones principales:

• Protocolo de Mutación Gobernado por Intención: Desacopla la intención del mecanismo de ejecución, evaluando las propuestas contra el contexto global y las políticas para admitir solo mutaciones semánticamente válidas y libres de conflictos.
• Seguridad Vinculada a la Ejecución (Execution-Bound Safety): Garantiza que incluso si un agente alucina o es malicioso, la ejecución física está confinada matemáticamente dentro de los límites del contrato (acción, recurso y tiempo) mediante identidades efímeras.
• Cadena de Evidencia IEEC: Establece una nueva invariante para sistemas agénticos: toda mutación debe ser tanto limitada en su ejecución como explicable en su linaje, permitiendo una auditoría determinista.

4. Resultados y Evaluación

Los autores implementaron un prototipo llamado Riftront y lo evaluaron en dos dominios: operaciones de negocio en tiempo real e infraestructura en la nube (AWS).

• Arbitraje de Conflictos: En escenarios de alta concurrencia con operadores humanos y agentes (verificados y no verificados), OpenKedge resolvió conflictos de autoridad y temporalidad de manera determinista, rechazando intenciones de baja confianza o desactualizadas sin necesidad de bloqueos distribuidos.
• Seguridad ante Alucinaciones:
  • Escenario 1: Un agente propuso eliminar una instancia de computación "no utilizada". El sistema detectó dependencias activas en el grafo de recursos y rechazó la mutación antes de la ejecución.
  • Escenario 2: Un agente propuso reducir la capacidad del clúster durante un pico de tráfico. La capa de evaluación bloqueó la acción al violar las restricciones de disponibilidad.
• Rendimiento: En una configuración de AWS (instancia m5.2xlarge), el sistema procesó 3,200 mutaciones por segundo con una latencia de evaluación de políticas de ~11 ms y una latencia de derivación de estado del percentil 99 de <30 ms, demostrando escalabilidad empresarial.
• Determinismo: Cargas de trabajo concurrentes idénticas produjeron contratos de ejecución, registros de eventos y estados derivados idénticos, eliminando condiciones de carrera observables.

5. Significado e Impacto

OpenKedge representa un cambio de paradigma fundamental en la ingeniería de sistemas de IA:

• De Pasivo a Activo: Pasa de confiar en la corrección del cliente (agente) a imponer una gobernanza activa en el sistema.
• Seguridad Física: Transforma la seguridad de una propiedad heurística ("hacer lo mejor posible") a una propiedad física garantizada mediante contratos criptográficos y límites de identidad.
• Auditoría Determinista: La IEEC convierte las mutaciones de infraestructura de "efectos secundarios opacos" a "artefactos de decisión reconstruibles", esencial para el cumplimiento normativo y la confianza en sistemas autónomos a escala.

En conclusión, OpenKedge proporciona la base principista necesaria para operar sistemas agénticos en producción, asegurando que la evolución del estado del sistema ocurra exclusivamente a través de transiciones válidas, acotadas y libres de conflictos derivadas de intenciones aprobadas.