El agente que escribe sus propios registros: por qué no se puede confiar en los audit trails autoinformados
Si un agente comprometido genera su propio registro de actividad, puede omitir, alterar o fabricar lo que hizo. Tres trabajos de junio de 2026 — Notarized Agents (arXiv), un borrador del IETF sobre audit trail de agentes y SCITT — convergen en la misma solución: mover la frontera de confianza fuera del agente.
En resumen Cuando un agente de IA registra su propio audit trail, la entidad registrada y la que escribe el registro son la misma — de modo que un agente comprometido o con errores puede eliminar, editar o inventar entradas en silencio, sin que el operador pueda detectarlo. Un artículo publicado el 2 de junio de 2026, Notarized Agents (arXiv 2606.04193), nombra esta falla estructural y propone invertir la frontera de confianza: dejar que el servicio que recibe la llamada del agente firme un recibo de lo que observó. El borrador del IETF sobre audit trail de agentes y el trabajo de SCITT sobre registros de transparencia, de la misma época, apuntan en la misma dirección. Es una carencia defensiva y de gobernanza, no un exploit — pero socava toda investigación posterior que asuma que el registro del agente dice la verdad.
¿De qué se trata?
La observabilidad de los agentes descansa en una suposición discreta: el agente emite una traza de sus propias llamadas a herramientas, y confiamos en esa traza cuando algo sale mal. Notarized Agents (Juan Figuera, arXiv 2606.04193, enviado el 2 de junio de 2026) plantea el problema sin rodeos: «la entidad que produce el registro de actividad es la misma cuya actividad se registra». Si un atacante toma el control del agente — o del operador que lo ejecuta — el registro pasa a decir lo que él quiera. Exfiltración omitida, argumentos reescritos, aprobaciones fabricadas: todo queda invisible para quien reconstruya los hechos después.
El asunto es inmediato porque la regulación va a apoyarse en esos registros. El borrador del IETF draft-sharif-agent-audit-trail-00 (Raza Sharif) recuerda que la Ley de IA europea (Reglamento 2024/1689) exige el registro automático de eventos para sistemas de alto riesgo a partir de agosto de 2026, y alinea su formato con SOC 2, ISO/IEC 42001 y PCI DSS v4.0.1. Una obligación de auditoría vale solo lo que vale la integridad de lo que audita.
Cómo funciona
La debilidad no es un payload; es una topología de confianza. Un agente que se registra a sí mismo está a ambos lados de la frontera:
# Traza autoinformada (predeterminado actual): un solo redactor, sin testigo
agente --> llamada herramienta --> [el agente escribe la entrada] --> almacén
^ |
\---- el mismo proceso controla ambos ----/
# Un agente comprometido simplemente no escribe la línea incriminatoria.Tres diseños de junio de 2026 convergen en mover al redactor fuera del agente:
- Atestación del lado del receptor. En Notarized Agents, el protocolo Sello hace que el servicio que recibe una llamada firme un recibo de lo que vio, lo cifre (HPKE) hacia la clave pública del propietario del agente vinculada al token de autorización mediante JWS, y lo publique en un registro de transparencia Merkle cofirmado por testigos. El propietario reconstruye luego una traza a prueba de manipulaciones sin confiar en el agente ni en su operador. Los autores son explícitos sobre los límites residuales — ataque de supresión, colusión de servicios y problema de incentivos a la adopción.
- Registros encadenados por hash. El borrador del IETF enlaza registros JSON mediante encadenamiento de hash SHA-256 (según RFC 8785) y firmas ECDSA opcionales, de modo que una entrada intermedia eliminada o alterada rompe la cadena.
- Transparencia de solo anexado. SCITT generaliza el patrón: declaraciones firmadas registradas en un log de solo anexado que emite recibos verificables.
El movimiento común es el mismo que hizo Certificate Transparency para la PKI de la web: dejar de pedirle al actor que responda por sí mismo y anclar la evidencia donde no pueda reescribirla en silencio.
Por qué importa
La mayor parte del debate sobre seguridad de agentes trata de prevenir acciones maliciosas — prompt injection, la tríada letal, validación de argumentos de herramientas. La integridad del audit trail trata de lo que pasa después: respuesta a incidentes, forense, cumplimiento y responsabilidad asumen todos que se puede reconstruir lo que el agente hizo realmente. Si ese registro es autoatestado, una sola compromisión de agente envenena toda investigación posterior, y «los logs no muestran nada» pierde todo sentido. Con las obligaciones de registro para sistemas de alto riesgo llegando en agosto de 2026, la carencia pasa de lo académico a lo regulatorio.
Defensas
- Trate el autoinforme del agente como no confiable por defecto. Ancle la evidencia crítica donde el agente no pueda reescribirla — una ruta de escritura que el proceso del agente no controle.
- Registre del lado del receptor, no solo del que llama. Haga que los servidores de herramientas, los servidores MCP y las API posteriores registren lo que ellos observaron (identidad del llamante, argumentos, resultado), de forma independiente de la traza del agente, para poder contrastar ambos.
- Haga detectable la manipulación. Encadene los registros por hash (SHA-256, RFC 8785) y fírmelos; una cadena rota o una firma ausente es una señal de caza. Es barato y está disponible hoy, sin adoptar un protocolo completo.
- Almacenamiento fuera del host, de solo anexado. Envíe los registros a un destino que el agente y su operador no puedan purgar (almacenamiento de objetos de solo anexado, un SIEM o un servicio de transparencia). Controlar la ruta de escritura es controlar la verdad.
- Siga los estándares, no improvise criptografía. Siga SCITT, el borrador del IETF sobre audit trail de agentes y el trabajo en protocolos de recibos (Signet, SCITT, Sello) en lugar de inventar una notarización propia — y recuerde que ninguno cierra del todo la supresión ni la colusión.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Notarized Agents / Sello | arXiv 2606.04193 | 2026-06-02 | Recibos atestados del lado del receptor; registro de transparencia Merkle; límites supresión y colusión nombrados |
| Agent Audit Trail (AAT) | draft-sharif-agent-audit-trail-00 | expira el 2026-09-29 | JSON + encadenamiento de hash SHA-256 (RFC 8785), ECDSA opcional; alineado AI Act / SOC 2 / ISO 42001 |
| Arquitectura SCITT | draft-ietf-scitt-architecture | Grupo de trabajo IETF | Registro de transparencia de solo anexado, declaraciones firmadas, recibos verificables |
| Registro Ley de IA | Reglamento 2024/1689 | 2026-08 (alto riesgo) | Registro automático de eventos obligatorio |
El encuadre correcto no es «añadir más logs». Es que un registro escrito por el actor que describe es una declaración de intenciones, no una prueba. La solución — probada por Certificate Transparency y ahora portada a los agentes — consiste en mover al redactor fuera del agente y anclar los recibos donde no pueda editarlos en silencio.