Resumen

  • La revisión 01 de draft-kuehlewind-audit-architecture, fechada el 7 de septiembre de 2026, incorpora almacenamiento en banda: cada agente puede operar un Audit Store y enviar registros por la misma conexión usada para interactuar.
  • El borrador presenta este diseño como alternativa, no como sustituto, de un almacén externo; ambos pueden combinarse. También reconoce que la operación por la misma parte exige confiar más en el operador del agente.
  • Almacenar no agota la función de auditoría. El texto distingue grabadores, Auditing Service, atestación, registro transparente, auditores y verificadores.
  • Sigue siendo un Internet-Draft individual. El Datatracker advierte que no cuenta con respaldo de la IETF ni tiene posición formal en su proceso de estándares.
  • Daniel Kade propone un recibo de topología de custodia que identifique al operador de cada función. Es análisis editorial, no una obligación del borrador.

Un atajo de despliegue que declara su coste de confianza

La novedad más significativa de la revisión 01 ocupa un solo párrafo. La nueva sección 3.2 plantea que, en vez de exportar registros a un Audit Store externo y separado, cada agente pueda ejecutar el suyo. Los registros pueden viajar al Store del agente contraparte mediante la conexión ya utilizada por la interacción, sin abrir un canal fuera de banda.

Hay razones operativas para hacerlo. Un agente efímero quizá ya tenga un enlace autenticado con su interlocutor. Reutilizarlo reduce integraciones y puede acompañar mejor una cadena distribuida. Los autores no lo presentan como diseño exclusivo: lo llaman alternativa al Store externo, permiten combinar ambos y escriben la contrapartida con claridad. Cuando el Store y el agente son operados por la misma parte, la arquitectura deposita más confianza en esa parte que en un almacén externo independiente.

El apartado no estaba en la revisión 00, fechada en mayo. La noticia es por tanto una modificación concreta y comprobable, no una nueva interpretación de palabras antiguas.

«Auditar» contiene acciones distintas

El riesgo no consiste en que todo almacenamiento en banda sea inválido. Aparece cuando un despliegue resume una cadena de funciones con la frase tranquilizadora «el agente está auditado». La propia revisión 01 ofrece un vocabulario más preciso.

Los actores principales generan registros desde perspectivas diferentes. La interfaz del usuario puede conservar intención y aprobaciones. El agente puede emitir señales de acciones, delegaciones y transiciones de autorización. Un servicio o herramienta puede registrar la petición que observó donde se produjo el efecto. El Audit Recorder captura o transforma esas señales. El Audit Store conserva y expone registros. El Auditing Service los canoniza, firma con su propia identidad y remite para registro transparente. Después, un auditor juzga la evidencia bajo una política y un verificador puede valorar afirmaciones concretas.

Cada función responde a una pregunta. El almacenamiento dice dónde localizar un registro. La firma vincula una declaración con una clave. La atestación puede respaldar afirmaciones sobre el entorno productor. Un recibo de transparencia ayuda a demostrar que una declaración existía en un registro en cierto momento y permite detectar algunas vistas incoherentes. La independencia del auditor se refiere a quién aplica el criterio. Ninguna propiedad aislada demuestra que todos los participantes registraron todo de forma veraz.

La distinción es esencial porque el borrador permite agregar roles. Un rol es una función, no necesariamente una unidad técnica o una empresa. El proceso que aloja al agente puede implementar también el grabador. Eso facilita la instalación, aunque el texto identifica amenazas de colusión y señala como mitigaciones un grabador independiente o la no repudiación mediante registro transparente. En otro apartado, la revisión 01 afirma que las propiedades de rendición de cuentas requieren un Auditing Service independiente.

No hay contradicción si se conservan los límites. Un Store de la misma parte puede transportar y retener registros mientras un servicio independiente los canoniza o compromete externamente. Un tercero puede alojar el Store sin ser quien juzga la auditoría. Y un producto externo puede seguir bajo el mismo grupo empresarial, administrador o custodio de claves. «Externo» describe ubicación; «independiente» describe control e incentivos.

La dirección del almacén no demuestra la custodia

Compárense dos configuraciones. En la primera, el agente escribe en un Store dentro de su proceso, pero un servicio separado registra de inmediato compromisos firmados en un sistema de transparencia que el operador no puede reescribir. En la segunda, el agente exporta los eventos a una cuenta de registros en la nube administrada por el mismo equipo que controla al agente y que puede alterar ambos antes de cualquier compromiso externo.

El segundo almacén está fuera en sentido geográfico. El primero puede imponer antes una restricción histórica. El ejemplo no acredita que ninguno sea completo o conforme; muestra por qué un diagrama de red y el número de proveedores no sustituyen un historial de custodia.

La RFC 9334 separa funciones de manera similar en la atestación remota: el Attester produce Evidence, el Verifier la evalúa y el Relying Party aplica su política. La RFC 9943 distingue declaraciones firmadas, servicios de transparencia, recibos y decisiones de las partes usuarias. El nombre de un componente no crea un nivel de garantía; lo crean los roles, las políticas, las claves y el recorrido de la evidencia.

El documento de auditoría aún es trabajo en curso. Su registro no muestra flujo RFC, director de área responsable ni adopción por un grupo de trabajo. El Datatracker advierte expresamente que este Internet-Draft no está respaldado por la IETF. La opción de almacenamiento debe describirse como propuesta en evolución, nunca como regla ya adoptada para los agentes.

Fuentes