AXR/Agent eXecution Receipts/Código abierto · MIT
AXR es una capa de rendición de cuentas de código abierto para agentes de IA y flujos automatizados: recibos de ejecución firmados criptográficamente y a prueba de manipulaciones que convierten el «confía en mí» en «verifícalo». Está hoy en producción, anclado cada hora, y verificable por cualquiera que tenga la clave pública.
El problema
Los agentes de IA ahora toman acciones de peso: llaman herramientas, cambian registros, mueven dinero, envían mensajes en nombre de alguien. La auditoría de todo eso suele ser un archivo de registro propiedad de quien ejecutó el agente — mutable, borrable, e inverificable por cualquiera fuera de la propia infraestructura del operador.
Después de los hechos, no hay forma fiable de responder a las preguntas que importan: qué agente hizo esto, qué recibió como entrada, qué decidió y sobre qué base, ¿se alteró el registro después?, y ¿por qué se le dijo «no» a un cliente?
Los reguladores se han dado cuenta. El Reglamento de IA de la UE convierte el registro automático de eventos en un requisito de diseño para sistemas de IA de alto riesgo (Artículo 12), obliga a los responsables del despliegue a conservar esos registros (Artículo 26), y sus obligaciones de alto riesgo se aplican desde el 2 de agosto de 2026. En EE. UU., el Center for AI Standards and Innovation del NIST lanzó la AI Agent Standards Initiative en febrero de 2026, con la seguridad y la identidad de los agentes como pilares centrales.
Un registro que puedes reescribir es un relato. Un recibo que puedes verificar es un registro.
Qué es
Por cada acción que importa, AXR emite un recibo: la acción realizada, hashes de sus entradas y salidas, una marca de tiempo, la identidad del agente, y una firma Ed25519 sobre el registro canonicalizado. Prueba una cosa con precisión — que un flujo dado, sobre una entrada dada, tomó una decisión dada, y que el registro no ha cambiado desde entonces.
Eso compra dos cosas distintas. La resistencia a manipulaciones es el suelo criptográfico: la firma prueba que el registro no ha cambiado. La legibilidad del comportamiento es lo que se gana el pan a diario — el recibo hace el comportamiento real del flujo lo bastante legible como para que una contradicción interna salga a la luz incluso cuando nada fue manipulado y cada firma es válida.
Deliberadamente no es un constructor de flujos, ni un framework de agentes, ni una plataforma de observabilidad. Es la fina capa de rendición de cuentas que se sitúa por debajo de esas herramientas. Dos tipos de recibo cargan el peso: un recibo de paso registra un único nodo relevante para la decisión, y un recibo de flujo encadena los pasos de una ejecución en un registro firmado y encadenado. Los pasos se encadenan dentro de una ejecución; las ejecuciones se encadenan a lo largo del historial del agente — así, borrar cualquier recibo rompe la cadena, y alterar cualquier recibo rompe la firma.
Recibo de paso ilustrativo — la forma de una acción firmada
{
"axr_version": "0.2.1",
"agent_id": "axr:agent:eco-clean:v5.1",
"step": { "name": "Create Booking", "kind": "side_effecting" },
"io": {
"input_hash": "sha256:9f2c…b41a",
"output_hash": "sha256:1d7e…0c88",
"decision": "BOOKING_CONFIRMED"
},
"logic_version": "5.1",
"logic_hash": "sha256:a3b9…77e2",
"previous_receipt_hash": "sha256:5c10…d9f3",
"timestamp": "2026-06-13T09:14:22Z",
"signature": "ed25519:K8f…/Qb2Aw=="
} Para quién es
AXR se gana el pan allí donde una decisión automatizada puede cuestionarse después y alguien tiene que respaldar la respuesta.
Reservan, fijan precios, mensajean, mueven dinero o cambian registros en nombre de alguien. Hoy el único relato de lo ocurrido es un archivo de registro que es tuyo y que podrías editar.
Lo que obtienes: Un recibo firmado por cada acción de peso — prueba, no un relato editable.
El Artículo 12 convierte el registro automático de eventos en requisito de diseño para sistemas de alto riesgo; el Artículo 26 impone la conservación a los responsables del despliegue, desde el 2 de agosto de 2026.
Lo que obtienes: Registros diseñados para encajar en esos deberes, con un informe listo para auditoría.
Después de los hechos tienes que establecer qué agente hizo qué, sobre qué entrada, y si el registro fue alterado — sin tener que creer la palabra del operador.
Lo que obtienes: Verificación sin conexión a partir de nada más que una clave pública. Sin acceso del operador.
AXR no es un framework de agentes ni una plataforma de observabilidad. Es la capa fina y aburrida sobre la que esas herramientas pueden asentarse — cripto estándar, cero dependencias, MIT.
Lo que obtienes: Un formato de cable congelado y dos verificadores independientes contra los que construir.
El borrado del Artículo 17 del RGPD parece pelearse con un registro de solo anexar: ¿cómo borras datos personales de un registro cuyo sentido es que no puede cambiar?
Lo que obtienes: Compromisos Merkle salados por campo — borra el texto claro, las firmas siguen en pie.
Un monitor independiente convierte la protección latente en detección activa: equivocación, truncamiento, reescrituras del historial y cambios de clave no autorizados.
Lo que obtienes: Detection Findings con forma OCSF y entrega por webhook a tu SIEM.
Cómo funciona
El generador de recibos es un único nodo Code al final de un flujo, antes de la respuesta. Lee las salidas de los nodos relevantes para la decisión y produce todos los recibos en una sola pasada. El anclaje y la monitorización corren fuera del flujo, así que la ruta caliente en producción no gana latencia ni una nueva dependencia.
Verifica un registro tú mismo — el comando completo:
# offline, zero dependencies, exit 0 = valid node axr-verify.js receipts.jsonl public-key.pem sth.jsonl anchors.jsonl # the same log, checked by a fully independent Python implementation python3 axr_verify.py receipts.jsonl public-key.pem sth.jsonl anchors.jsonl
¿Sin terminal? Arrastra un registro al verificador en el navegador — ejecuta las mismas comprobaciones de firma, raíz Merkle y witness localmente, sin subir nada.
El diseño
El trabajo de aseguramiento debería ser auditable por personas que no lo escribieron. Por eso AXR usa solo bloques estándar y bien entendidos — y declara sus objetivos con claridad:
Madurez
AXR se entrega como un único repo que abarca varios niveles de madurez. El sentido de esta tabla es la honestidad: lee el nivel de una función antes de depender de ella. El formato de cable 0.2 está congelado — los registros antiguos verifican byte a byte con el verificador actual, y todo el trabajo posterior es aditivo.
| Capa | Versión | Madurez |
|---|---|---|
| Núcleo — firma, encadenado, hash de entrada por paso, JSON canónico, paridad cross-impl Probado en producción, formato de cable congelado; nodo n8n endurecido. | 0.2.1 | Estable |
| Anclaje — agrupado Merkle, Signed Tree Heads, monitor, sellado de tiempo externo Cron de anclaje por hora en producción; clave STH separada. | 0.3 | Desplegado |
| Recibos redactables, atestación de efectos secundarios, trust root, separación de roles de clave Probado; congelado en el contrato 1.0. | 0.4 | Estable |
| Sucesión de claves — rotación anclada a root, distinguible de un compromiso Paridad cross-impl + revisión adversaria; el piloto aún no la usa. | 0.5 | Estable |
| Exportación SIEM — mapeo OCSF Detection Finding + webhook genérico Salida con forma OCSF; entrega best-effort por diseño. | 0.6 | Estable |
| Endurecimiento del ciclo de vida del root — root por quórum (M-de-N), rotación, revocación, CLI de ceremonia Paridad cross-impl; la política de quórum es parte del modelo de amenazas. | 0.6 | Estable |
| Control log — distribución de gobernanza anclada + divulgación parcial Cierra la brecha de retención fuera de banda; 1.5 añade prueba de inclusión off-wire para un único registro (prueba uno, no reveles los demás). | 0.7 – 1.5 | Estable |
| Ciclo de vida del witness — cosigning, revocación de emergencia, suspensión temporal con caducidad automática Defensa preventiva de equivocación; el ciclo completo lento-revoca → revoca → suspende, cross-impl. | 0.8 – 1.4 | Estable |
| SDK de biblioteca — require('axr'): una superficie de API pública congelada + verify() programático La superficie la fija un test; axr.verify() ejecuta el verificador canónico, así que nunca puede divergir. | 1.2 – 1.3 | Estable |
Prueba en producción
AXR corre en producción sobre un flujo de reservas real para ECO Clean HU — seis de los veinte nodos del flujo llevan recibo, y el registro — ya por encima de 227 recibos firmados — se ancla cada hora en un único árbol Merkle desde junio de 2026. Levantar esa capa de rendición de cuentas hizo algo que su operador no esperaba: sacó a la luz cuatro fallos reales anteriores a AXR, y dos defectos en las propias herramientas de AXR.
Ninguno implicó manipulación ni una firma inválida. Son legibilidad del comportamiento, no resistencia a manipulaciones: el recibo hizo la ejecución lo bastante legible como para que una contradicción entre la rama prevista y la ejecutada saliera sola a la luz. El Bug B fue justo eso — un rechazo que aun así disparó la rama de éxito, detectado en el momento en que se leyó el resultado del recibo.
Cada ejecución disparaba las tres ramas de respuesta a la vez: un rechazo ZONE_INCOMPATIBLE aun así enviaba un correo de éxito. El final_status del recibo hizo la contradicción inmediata. Resuelto con un nodo Switch que enruta según el resultado del recibo.
Los rechazos devolvían «unknown_error» reflejando el propio mensaje del cliente — la razón real se perdía. El recibo registraba el estado correcto en cada ejecución, contradiciendo lo que recibían los clientes.
Un conflicto de reverificación producía un HTTP 200 con cuerpo vacío, mientras el recibo era una cadena SLOT_TAKEN de 5 pasos completa y firmada. La brecha entre un recibo correcto y una respuesta vacía es exactamente lo que AXR está hecho para sacar a la luz.
Tras un parche que subió la lógica a v5.1, cada recibo seguía atestiguando v5.0 — firmas válidas sobre una afirmación falsa de qué código decidió. Ahora las huellas hash de código sustituyen a las etiquetas escritas a mano, y la CI falla ante la deriva. Las etiquetas de versión son testimonio; los hashes de código son prueba.
Una ejecución de prueba en sandbox del despliegue de anclaje atrapó dos defectos del propio AXR antes de que tocaran el registro en vivo: el anclaje entre versiones habría invalidado cada firma heredada, y el verificador de Python ignoraba en silencio el flag de clave separada. Ambos resueltos antes de emitir el primer ancla en producción. Una ejecución de prueba que se rompe en un sandbox es una función.
Prueba adversaria
Una afirmación de integridad vale solo lo que valen los intentos de romperla. AXR prueba su afirmación central de forma sistemática, no retórica:
Estándares y cumplimiento
AXR está diseñado para encajar en los deberes de registro que están llegando — no para afirmar cumplimiento certificado con ninguno. El Artículo 12 del Reglamento de IA de la UE exige que los sistemas de alto riesgo registren eventos automáticamente para la trazabilidad, y el Artículo 26 impone la conservación a los responsables del despliegue. El Artículo 17 del RGPD tira en sentido contrario, hacia el borrado. La AI Agent Standards Initiative del NIST está moldeando el lado de EE. UU. en torno a la identidad y la auditabilidad. Los recibos firmados y verificables de forma independiente son un primitivo sobre el que cada una de esas direcciones puede construir.
Dos piezas lo hacen concreto. Los recibos redactables resuelven la tensión RGPD-contra-solo-anexar: los campos sensibles se comprometen a través de un árbol Merkle salado por campo, así el texto claro puede borrarse después mientras la firma, la cadena y la prueba ya anclada siguen en pie. Y el Compliance Report Generator convierte un registro en bruto en un informe HTML listo para auditoría — integridad, la línea de tiempo de gobernanza de claves, el estado de anclaje, y un mapeo de controles para el Artículo 12 del Reglamento de IA de la UE / RGPD.
La precisión importa aquí: «diseñado para encajar» es la afirmación. El informe es una vista sobre el veredicto del verificador, no un sustituto, y no afirma nada que no haya comprobado.
Dogfooding
AXR fue construido por un banco de trabajo de tres IA — Fable, Meridian y NEXUS — sobre un diario compartido de solo anexar. Ese diario es en sí un registro AXR verificable: cada entrada es un recibo firmado con Ed25519, todo el conjunto se ancla con Merkle en un único tree head firmado, y ese tree head fue cosignado por los dos agentes revisores — cada uno en su propio proceso, con una clave que generó y custodió él mismo, de modo que el orquestador nunca vio una clave privada. La instantánea comprometida se reverifica bajo el stack 1.0 completo, en tu navegador.
Encuadre honesto: esto prueba que el diario no se ha alterado desde la firma, no que cada entrada fuera cierta al escribirse. Las cosignaturas son genuinamente independientes del proceso; la única brecha que queda hacia el zero-trust pleno es que la custodia sigue en la misma máquina — en producción los witnesses corren en zonas de seguridad separadas.
Estado y límites
AXR es de código abierto, con licencia MIT, y se desarrolla en público. Desde 1.0 el formato de cable y el contrato CLI/verificador están congelados para 1.x; 1.1–1.4 solo añadieron registros retrocompatibles y un SDK de biblioteca congelado. El núcleo y la capa de anclaje corren en producción; las capas superiores — sucesión de claves, roots por quórum, el control log y el ciclo de vida completo del witness (cosigning, revocación de emergencia, suspensión temporal) — están probadas, verificadas cross-impl y son aditivas, pero el piloto en vivo aún no las usa. El proyecto es honesto sobre sus propias carencias:
Prueba
Cada despliegue de chrisconen.dev publica un manifiesto de cada archivo del sitio, hasheado con SHA-256 y firmado con Ed25519. Tu navegador puede verificar la firma y rehashear cualquier archivo contra el manifiesto. Es la idea central de AXR aplicada a un pipeline de build en vez de a un agente — el mismo recibo, distinto actor.