Recibos firmados de las acciones de un agente

Un registro de aplicación es útil para investigar dentro de la empresa: se lee, se cruza con el consumo y se atribuye a una persona. Para un tercero es otra cosa. El archivo lo escribe el propio sistema que se audita, se guarda en servidores que administra el operador y puede editarse después de los hechos sin que quede una marca que lo delate. El auditor tiene que creer que lo que recibe es lo que pasó.

Eso basta para uso interno. No basta cuando hay dinero de terceros, datos de salud o una autoridad que pide prueba. La necesidad que aparece es concreta: poder comprobar una acción pasada con algo que no dependa de la buena fe de quien la ejecutó.

Un recibo es un objeto pequeño que describe una acción del agente, con la herramienta que llamó, los argumentos, la política que se suponía vigente y el momento, y que el sistema que ejecutó la acción firma con una clave privada. La firma es el truco: quien tenga la clave pública correspondiente puede comprobarla en su propio equipo, sin conexión a ningún servicio del operador. Si alguien cambia un solo carácter del contenido después de firmar, la comprobación falla.

Por eso la clave que se reparte es la pública. Entregarla no da poder para fabricar recibos; solo da poder para verificarlos.

La firma cubre los bytes exactos del contenido, no su significado. Dos programas pueden escribir el mismo recibo con los campos en distinto orden o con otros espacios, y para la firma son dos textos distintos. Si cada implementación decide sola cómo escribir, un recibo auténtico puede fallar la verificación sin que nadie haya tocado nada, y el auditor no distinguiría un fallo de formato de una manipulación.

Se evita fijando una forma canónica: una regla única para ordenar los campos y escribir los valores, que se aplica siempre antes de firmar y antes de verificar. El mismo contenido produce entonces siempre los mismos bytes.

Un recibo prueba tres cosas y ninguna más. Atribución, porque la firma dice qué sistema ejecutó la acción. Integridad, porque el contenido no cambió desde que se firmó. Y orden, cuando cada recibo incluye la huella del anterior: quitar uno de la serie o intercalar otro rompe la cadena y se nota.

No prueba que la acción fuera correcta. No prueba que la política que nombra se aplicara de verdad, porque el recibo dice cuál se suponía vigente, no que se cumpliera. Y no prueba que una persona la autorizara. Un recibo impecable puede estar registrando, con total fidelidad, una acción equivocada. Esa evidencia hay que buscarla aparte.

Todo el valor del recibo está en la clave privada. Si el agente puede leerla, o puede pedir que se firme cualquier texto que él redacte, la firma deja de probar nada: una inyección de instrucciones lograría recibos falsos que verifican igual que los verdaderos. La clave tiene que vivir fuera del alcance del agente y del modelo, en un componente que firme lo que realmente ejecutó la herramienta, no lo que el agente diga que ejecutó.

Es la misma regla de siempre en esta ruta, aplicada a la prueba: lo que protege no puede depender de que el modelo se porte bien.