La Compliance API de Anthropic ya devuelve las transcripciones de las sesiones de Claude Code y Cowork, incluidas las que se ejecutan en la máquina del usuario. Es la pieza que faltaba para que una empresa pueda auditar qué hace un agente en el equipo de un desarrollador. Un análisis publicado esta semana por The Hacker News desgrana el funcionamiento de esos endpoints y, sobre todo, señala lo que no aparece en el registro, que es justo la parte que importa si alguien va a revisar tu trabajo con esta herramienta.
Un transcript por sesión, con las llamadas a herramientas dentro
La API agrupa las sesiones en dos familias de endpoints: las locales, que son las que corren en el equipo del usuario a través de Claude Code o Cowork, y las remotas, que se ejecutan en la nube en entornos gestionados por Anthropic. Para cada sesión devuelve un único transcript consolidado, alojado en servidor, donde los prompts, las respuestas y la actividad de herramientas vienen juntos en el mismo registro.
El contenido llega estructurado en tres tipos de bloque: text para lo que se escribe y se responde, tool_use para las llamadas a herramientas y tool_result para lo que esas llamadas devuelven. En la práctica eso cubre bastante más de lo que la mayoría espera: comandos bash, lecturas y escrituras de ficheros, búsquedas web y llamadas a servidores MCP, además del contenido de skills y artefactos, que se captura como texto dentro de la propia transcripción.
Cada sesión viene acompañada de metadatos que la hacen atribuible: identificador de usuario verificado y su correo, identificador de la organización, identificadores de sesión y de cada mensaje, y marcas de tiempo. Dicho de otro modo, no es un volcado anónimo de texto: es un registro que dice quién pidió qué, cuándo y con qué resultado.
Quien ejecuta los comandos es el harness, no el modelo
Aquí está el matiz que aporta el análisis y que conviene entender bien, porque cambia lo que se puede afirmar con estos logs delante. La Compliance API registra lo que llega al modelo y lo que el modelo devuelve. Pero en Claude Code el que ejecuta de verdad los comandos, el que se autentica contra servicios de terceros y el que abre la conexión con los servidores MCP no es el modelo: es el harness, el programa que corre en tu máquina.
La consecuencia es directa. Todo lo que ese programa hace sin pasar por el modelo queda fuera del registro: los hooks configurados en local, la configuración del propio cliente, y en general cualquier lógica que se dispare alrededor de una sesión sin generar un bloque que viaje a la API. Si un hook reescribe una orden, la bloquea o ejecuta algo antes o después de una herramienta, el transcript no lo cuenta.
Si el registro solo ve lo que llega al modelo, no puede probar lo que tu agente hizo en local y nunca reportó.
Hay un segundo hueco, más grande todavía y fácil de pasar por alto en despliegues mixtos: si ejecutas Claude Code contra un modelo que no es de Anthropic —a través de un endpoint propio o de un proveedor de terceros— no hay cobertura de Compliance API en absoluto. Esas sesiones simplemente no existen para el registro, aunque el CLI sea el mismo, el equipo sea el mismo y el repositorio también.
Seis años de retención y una llave que no es tu API key
Dos detalles operativos que conviene tener claros antes de prometerle nada a un cliente. El primero: las transcripciones de sesiones locales se guardan por defecto seis años, o el periodo de retención personalizado que haya fijado la organización si es más corto. No es un log rotativo de unos días; es un archivo de largo plazo.
El segundo: el acceso no va con la API key de siempre. Se necesita una Compliance Access Key con el permiso read:compliance_user_data, y los endpoints están disponibles únicamente para organizaciones Enterprise. Si trabajas por tu cuenta con un plan Pro o Max, esto no es una función que puedas activar: es una capacidad que el cliente para el que trabajas puede tener sobre las sesiones de su organización.
💡 Si te incorporas a un equipo Enterprise
Da por hecho que todo lo que escribas en una sesión de Claude Code queda registrado y es atribuible a tu correo, incluidos los comandos y el contenido de los ficheros que el agente lee. No es motivo para preocuparse, pero sí para no pegar credenciales personales en un prompt «solo para probar»: ese pegado vive seis años en un archivo que tú no administras.
Trazabilidad no es lo mismo que control
Lo que esta pieza deja claro es que la Compliance API es una herramienta de rendición de cuentas, no de contención. Sirve para reconstruir lo que ocurrió en una sesión y para demostrarlo ante un auditor, no para impedir que ocurra. Lo que impide cosas sigue viviendo en el mismo sitio de siempre: las reglas de permisos, el sandbox, los hooks y el alcance de directorios que le das al agente.
Y ahí hay una asimetría que merece la pena nombrar. Las dos capas se comprueban en sitios distintos: la de control es local y la de auditoría es remota, y precisamente por eso la segunda no puede validar a la primera. Un registro completo de lo que el modelo vio convive perfectamente con un equipo mal configurado, del mismo modo que un equipo bien blindado puede no dejar rastro auditable si corre contra otro proveedor.
La implicación práctica para quien trabaja con clientes es sencilla de aplicar. Si un cliente te pide trazabilidad de lo que hace la IA sobre su código, esta API responde la pregunta «qué se le pidió al modelo y qué contestó», con nombre, hora y contenido. Si lo que te piden es garantizar qué puede tocar el agente en la máquina, la respuesta no está aquí: está en cómo configuras permisos, sandbox y directorios antes de lanzar la primera sesión. Conviene distinguirlo por escrito, porque son dos promesas distintas y solo una de ellas la cubre esta herramienta.
