Cómo funciona la revisión de acciones de agentes de IA sin guardar prompts

Los registros de revisión de los agentes autónomos deben explicar una acción externa sin convertirse en una segunda copia, mal protegida, de toda la memoria de trabajo del agente. Eso significa registrar quién ejecutó el agente, qué autoridad permitió la ejecución, qué límite cruzó la acción y qué ocurrió. No significa conservar para siempre cada prompt, mensaje de herramienta, bloc de notas y carga útil de API.

Los equipos suelen empezar con transcripciones de conversaciones porque son fáciles de capturar y parecen completas. Luego llega un incidente y la transcripción contiene datos de clientes, código fuente, tokens pegados, instrucciones especulativas y páginas de material que no tienen relación con la acción revisada. Mientras tanto, el revisor sigue sin poder responder la pregunta básica: qué ejecutable envió una solicitud a qué servicio, bajo qué autorización, con qué alcance de credenciales y con qué resultado.

Un registro de revisión debe seguir a la acción, no a la conversación. Esta decisión reduce la exposición y produce pruebas que un operador puede usar de verdad.

Un registro de acción responde a una pregunta distinta de la de una transcripción

Un registro de acción responde si un proceso concreto cruzó un límite y qué hizo el sistema externo en respuesta. Una transcripción responde qué texto pasó por el contexto de un agente. Son artefactos distintos, con necesidades de acceso, periodos de conservación y modos de fallo diferentes.

Supongamos que un agente lee un hilo extenso de incidencias, inspecciona un repositorio, redacta una nota de lanzamiento y llama a una API para crear un despliegue. Una exportación de la conversación puede contener miles de líneas. El registro de revisión significativo puede ser mucho más pequeño:

• Identidad del proceso e identificador de sesión.
• Decisión de autorización que cubrió la acción.
• Destino, método, categoría del recurso y referencia de la credencial.
• Resultado, incluido el estado y un resumen seguro.
• Marcas de tiempo y datos de integridad.

Ese registro permite reconstruir el evento operativo: un proceso firmado se inició a una hora determinada, recibió aprobación para una sesión, envió POST a un host de API y un endpoint de despliegue concretos, utilizó la credencial de despliegue y recibió un estado de éxito con un identificador de despliegue. Si el evento lo justifica, el revisor puede pedir pruebas más detalladas al responsable del servicio de destino.

La transcripción quizá explique por qué el agente pensó que debía desplegar. Rara vez demuestra que lo hizo. El texto del contexto de un agente puede ser hipotético, estar desactualizado, haber sido inventado por un modelo o no haberse ejecutado nunca. La acción externa tiene un rastro de pruebas más limitado y defendible.

Conserva el material conversacional en el entorno de desarrollo solo cuando el equipo tenga un motivo claro para guardarlo, como una evaluación de calidad o un incidente concreto. No lo introduzcas de forma encubierta en un sistema de auditoría bajo la etiqueta de responsabilidad.

Los prompts completos crean un almacén de datos que nadie planeó proteger

Capturar prompts completos convierte un registro de acciones en un archivo de contenido de alto riesgo. El riesgo no es teórico ni se limita a los secretos evidentes.

Los prompts suelen incluir fragmentos de código fuente, tickets de clientes, resultados de bases de datos, URL internas, decisiones de diseño, historial del shell y mensajes de error copiados. Un modelo puede repetir contexto anterior en un argumento de herramienta o en una explicación de error. Una API puede devolver en una respuesta de error una cabecera o un cuerpo de solicitud enviados. Si el registrador trata todas las cadenas como diagnósticos inofensivos, acabará conservando información que el equipo nunca quiso recopilar.

La defensa habitual es: «Redactaremos los secretos». Eso solo funciona si la ruta de registro detecta todos los formatos de secretos antes del almacenamiento y entiende todos los protocolos. Pasará por alto URL firmadas de corta duración, cookies de sesión, formatos de tokens propios, secretos incrustados en cadenas JSON y credenciales que un servicio devuelva dentro de un error. Además, la redacción no puede recuperar la privacidad después de que un grupo amplio haya leído el registro original.

La Logging Cheat Sheet de OWASP establece una distinción útil: los registros deben servir para la supervisión y la investigación, pero los sistemas no deben registrar tokens de acceso, contraseñas, cadenas de conexión, claves de cifrado ni datos cuya recopilación cree una exposición innecesaria de la privacidad. Aplica este consejo a las revisiones de agentes con más disciplina, no con menos. El contexto de un agente es especialmente amplio, por lo que contiene más material accidental que un registro de solicitudes convencional.

Minimiza los datos en el momento de capturarlos. Guarda una huella de la solicitud o metadatos aprobados, no el prompt sin procesar que la generó. Si una investigación necesita contexto más adelante, recupéralo del sistema de origen bajo los controles adecuados para ese sistema. No conviertas un diario de auditoría en el lugar más fácil para explorar todas las conversaciones sensibles.

Hay una excepción limitada: un equipo puede necesitar una captura temporal y estrictamente restringida para diagnosticar una integración defectuosa. Conviértela en un modo de diagnóstico explícito, con responsable, caducidad, restricción de acceso y fecha de eliminación definidos. Si la captura de diagnóstico se vuelve permanente porque nadie la desactiva, no era realmente una captura de diagnóstico.

La identidad del proceso debe sobrevivir a un nombre amigable

El nombre de un proceso no identifica a un agente. agent, node, python y shell dicen muy poco al revisor, y un programa malicioso o descuidado puede elegir cualquiera de esos nombres.

Registra suficientes datos de identidad para distinguir el programa que inició la sesión:

• Ruta del ejecutable y una identidad de código estable, como una autoridad de firma cuando el sistema operativo proporcione una.
• ID del proceso, ID del proceso padre, hora de inicio e identificador de sesión.
• Cuenta de usuario e identificador del host local.
• Versión o identificador de compilación del cliente del agente cuando el cliente lo proporcione.
• Transporte que llegó a la puerta de enlace de acciones, como una conexión MCP local mediante stdio.

El proceso padre importa. Un editor firmado que inicia un agente de programación aprobado presenta una historia de revisión distinta de la de un proceso de shell desconocido que inicia un binario copiado con el mismo nombre de comando. La identidad del proceso padre no demuestra buenas intenciones, pero da a los investigadores un punto de partida y facilita detectar suplantaciones sencillas.

No confundas la identidad del proceso con la identidad de una persona. Un desarrollador puede iniciar un agente, pero el registro de acción debe indicar ambos hechos por separado: qué cuenta local inició el proceso y qué ejecutable mantuvo la sesión. Los equipos compartidos, los shells remotos, las cuentas de servicio y las transferencias entre herramientas hacen necesaria esta separación.

La autoridad de firma de código merece especial importancia cuando está disponible, porque el sistema operativo puede verificarla durante el inicio. Aun así, no es un juicio moral sobre el editor. Una autoridad de firma de confianza puede distribuir una actualización defectuosa y una herramienta interna sin firma puede ser legítima. El registro necesita ese dato para que el revisor pueda compararlo con la decisión de autorización y con la ruta de despliegue esperada.

La autorización necesita alcance, tiempo y una persona aprobadora

Una aprobación sin alcance es un recuerdo impreciso, no una prueba de revisión. El registro debe indicar qué aprobó la persona, cuándo comenzó a aplicarse la aprobación y cuándo dejó de hacerlo.

La autorización de sesión suele ser el valor predeterminado adecuado para una ejecución de agente dirigida por un desarrollador. Una persona aprueba una vez un proceso de agente conocido y el proceso puede realizar acciones hasta que termina. El diario de revisión debe vincular esa decisión a la sesión del proceso, en lugar de fingir que cada llamada posterior recibió un juicio humano independiente.

Para las credenciales de mayor riesgo, registra una decisión separada para cada llamada. El registro debe incluir la identidad de la persona aprobadora, la hora, la referencia de la credencial, la categoría de acción, el destino y el identificador exacto de la llamada que se autorizó. Una nota genérica como «usuario aprobado» deja demasiado margen para discutir después de una acción incorrecta.

Un objeto de autorización práctico podría tener este aspecto:

{
  "authorization_id": "auth_7f3c",
  "kind": "session",
  "decision": "approved",
  "approved_at": "2025-03-08T14:22:31Z",
  "approver": "local-account:maya",
  "process_session": "sess_31a9",
  "process_identity": {
    "executable": "/Applications/Agent.app/Contents/agent",
    "signing_authority": "Example Development Team"
  },
  "scope": {
    "credential_refs": ["deploy-production"],
    "expires_when": "process exits"
  }
}

Los nombres y los identificadores anteriores son ejemplos, pero la estructura importa. La persona aprobadora es una identidad de cuenta local, no una afirmación de que alguien haya observado cada línea de salida. La referencia de la credencial es una etiqueta o un ID interno, nunca la credencial en sí. El alcance indica si la decisión cubría una sesión o una sola llamada.

No intentes resolverlo con un lenguaje de políticas enorme, salvo que tu entorno operativo realmente lo necesite. Los equipos suelen crear reglas que nadie puede leer durante un incidente y luego consideran la existencia de esas reglas un control. Un número reducido de opciones de autorización visibles puede ser más fácil de revisar y más difícil de configurar mal.

Los metadatos de la solicitud deben describir el límite cruzado

Un revisor necesita suficientes metadatos de la solicitud para comprender el alcance de la operación sin recibir una copia sin procesar de la operación. En HTTP, captura el host del servicio, el puerto cuando sea pertinente, el método, la plantilla de ruta normalizada, la referencia de la credencial, el tamaño de la solicitud, el ID de correlación y un resumen de una representación canónica segura.

Una plantilla de ruta normalizada registra /v1/projects/{project_id}/deployments en lugar de una URL literal que contenga un identificador de cliente o un valor opaco parecido a un secreto. La ruta sin procesar puede permanecer en el servicio de destino, que ya es responsable de esos datos y tiene sus propios controles de acceso.

En SSH, el registro equivalente incluye el host de destino, la identidad verificada del host, la cuenta remota, el comando solicitado o su clasificación, la referencia de la credencial y el resultado de salida. Evita registrar la salida completa del comando. Un comando puede mostrar variables de entorno, contenido de repositorios privados o credenciales procedentes de un script mal configurado.

HTTP Semantics, RFC 9110, distingue la semántica de los métodos de solicitud, como métodos seguros, idempotentes y no seguros. Usa esta distinción como señal para la revisión, no como sustituto de la autorización. Un GET puede revelar datos sensibles. Un PUT puede ser idempotente y aun así reemplazar una configuración de producción. Un POST puede crear un efecto externo irreversible. El método ayuda al revisor a razonar sobre la acción, pero el destino y la ruta determinan el riesgo real.

Usa un esquema de metadatos basado en una lista permitida. No empieces con el objeto de solicitud completo para eliminar campos más tarde. Lo seguro es definir los campos que puede contener un registro de acción y rechazar o transformar todo lo demás.

{
  "call_id": "call_c24e",
  "session_id": "sess_31a9",
  "channel": "https",
  "destination": "api.example.internal",
  "method": "POST",
  "route_template": "/v1/projects/{project_id}/deployments",
  "credential_ref": "deploy-production",
  "request_bytes": 842,
  "request_digest": "sha256:6d1d...",
  "started_at": "2025-03-08T14:24:09Z"
}

Una huella detecta que un registro canónico ha cambiado cuando el revisor dispone de la representación original aprobada. No hace que el contenido original sea seguro para publicar. Trata también con cuidado los hashes de secretos con poca entropía, porque un atacante puede adivinarlos y compararlos. No hagas un hash de un token corto y lo llames redacción.

Los resultados necesitan pruebas operativas, no volcados de respuestas

Un registro de resultados debe indicar qué comunicó el destino y si la puerta de enlace completó la operación solicitada. No debe guardar por defecto el cuerpo completo de la respuesta.

Para una acción HTTP, registra la finalización del transporte, el estado HTTP, el tamaño de la respuesta, el tiempo transcurrido, un ID de solicitud del servicio cuando sea seguro y un campo de resultado seleccionado deliberadamente. Por ejemplo, una API de despliegue puede devolver un ID de despliegue seguro para conservar, mientras que su respuesta JSON completa contiene variables de entorno y un mensaje de commit de un repositorio privado.

Para una acción SSH, conserva el código de salida, la duración, el resultado de la identidad del host y un resumen seleccionado por el adaptador del comando. Si un comando necesita demostrar que el trabajo se completó correctamente, haz que emita un resultado legible por máquina y limitado, como {\"release\":\"r42\",\"status\":\"published\"}. No aceptes una transcripción de terminal arbitraria como resultado de auditoría.

Esta distinción importa durante los fallos. Imagina que una llamada de despliegue devuelve HTTP 403 e incluye un objeto de diagnóstico que repite la cabecera de autorización de quien llama. El agente ve el error, reintenta dos veces y cada intento produce una entrada de registro distinta. Ahora un sistema de revisión descuidado contiene tres copias de una credencial expuesta, todas indexadas bajo un incidente que abrirá más gente.

Construye primero la ruta de error. La puerta de enlace de acciones debe clasificar el error, eliminar los campos inseguros y registrar un resumen limitado. Algunas categorías útiles son fallo de red, autorización denegada, solicitud rechazada por el destino, tiempo de espera del destino y fallo de ejecución local. Combina la categoría con datos seguros, como el código de estado o de salida, no con un bloque de texto libre procedente de un servicio remoto.

Los reintentos merecen sus propios campos. Registra attempt, max_attempts y un vínculo causal con la llamada original. De lo contrario, el revisor verá tres solicitudes destructivas y no podrá saber si el agente las repitió deliberadamente o si un reintento del transporte produjo duplicados. En operaciones no seguras, un reintento puede requerir una autorización nueva o un mecanismo de idempotencia en el destino. El registro no puede reparar una acción que el destino aplicó dos veces.

Un esquema de revisión debe hacer visibles los campos prohibidos

Revisar el esquema permite detectar errores de registro antes de que se acumulen registros de producción. Trata el esquema como un límite de seguridad, con campos permitidos explícitos y rechazo explícito de campos libres para prompts y cargas útiles.

El ejemplo siguiente combina identidad, autorización, metadatos de acción, resultado e información de integridad. Deliberadamente no incluye los campos prompt, messages, headers, request_body, response_body ni stderr.

{
  "event_type": "external_action",
  "event_id": "evt_91bd",
  "occurred_at": "2025-03-08T14:24:10Z",
  "actor": {
    "local_account": "maya",
    "process_session": "sess_31a9",
    "pid": 4812,
    "parent_pid": 4601,
    "executable_digest": "sha256:2a84...",
    "signing_authority": "Example Development Team"
  },
  "authorization": {
    "authorization_id": "auth_7f3c",
    "mode": "session",
    "decision": "approved"
  },
  "action": {
    "channel": "https",
    "destination": "api.example.internal",
    "operation": "POST /v1/projects/{project_id}/deployments",
    "credential_ref": "deploy-production",
    "request_digest": "sha256:6d1d..."
  },
  "result": {
    "category": "completed",
    "status_code": 201,
    "destination_request_id": "req_18c7",
    "duration_ms": 614
  },
  "integrity": {
    "previous_event_digest": "sha256:8f50...",
    "event_digest": "sha256:bd7e..."
  }
}

No pongas comentarios como «redactado» junto a campos que alguna vez pudieran haber contenido secretos. Omite el campo. Un request_body presente pero vacío invita al siguiente desarrollador a rellenarlo durante la depuración. La validación del esquema debe rechazar campos desconocidos de nivel superior y bloques anidados, salvo cuando un adaptador revisado controle su formato.

Los revisores también necesitan una vista legible del evento. Genera esa vista a partir del registro canónico, en lugar de mantener una narración manuscrita independiente. Una entrada para personas podría decir: «La sesión del proceso aprobado utilizó deploy-production para crear un despliegue en api.example.internal. El servicio devolvió 201 en 614 ms». El diario conserva los identificadores necesarios para inspeccionar el evento sin exponer material sensible en la vista predeterminada.

La integridad demuestra alteraciones, no integridad de la cobertura

Los registros que permiten detectar manipulaciones solo sirven si el equipo entiende sus límites. Una cadena de hashes puede revelar que alguien cambió, eliminó o reordenó un evento después de que entrara en la cadena, siempre que los revisores conserven el material necesario para verificarla. No puede demostrar que un registrador comprometido registrara la acción desde el principio.

NIST SP 800-92, Guide to Computer Security Log Management, recomienda proteger la integridad de los registros, definir qué eventos merecen registrarse y revisar los registros con una responsabilidad operativa clara. Lo útil está en la combinación. La integridad sin un límite de eventos definido proporciona registros fiables de una historia incompleta. Una lista extensa de eventos sin integridad proporciona una historia que alguien puede editar en silencio.

Usa la puerta de enlace de acciones como punto de observación, porque ve el uso de la credencial y la llamada externa. Si un agente puede saltarse esa puerta de enlace y hacer llamadas directas con credenciales copiadas, el rastro de auditoría cubre solo la ruta cooperativa. Corrige el problema de distribución de credenciales en lugar de afirmar que el diario lo ve todo.

Mantén la verificación independiente de la lectura normal de los registros. Un comando de verificación debe funcionar con registros cifrados almacenados e indicar si la cadena se mantiene. Sallyport ofrece esta comprobación mediante sp audit verify, que verifica su registro de auditoría cifrado y encadenado mediante hashes sin necesitar la clave de la bóveda. Este diseño importa porque un investigador debería poder comprobar la continuidad de los registros sin obtener acceso a las credenciales.

Los resultados de la verificación necesitan un procedimiento operativo. Si falla una comprobación de la cadena, conserva el almacenamiento afectado, deja de tratar el diario como una prueba completa, identifica el primer punto de secuencia roto y compara los registros del destino para ese intervalo. No regeneres simplemente una cadena limpia y sigas adelante. Eso convierte un fallo de integridad detectable en una laguna imposible de responder.

El acceso y la conservación determinan si el diario se convierte en otra filtración

Un registro mínimo también puede causar daños si demasiadas personas pueden buscarlo indefinidamente. El historial de autorizaciones puede revelar la actividad de empleados. Los nombres de destinos pueden revelar infraestructura. Los identificadores de proyectos pueden exponer trabajo comercial. Limita el acceso según la función durante una investigación, no según la curiosidad general.

Separa las vistas operativas de las forenses. La mayoría de los ingenieros necesita una lista reciente de acciones, estados, destinos e identidades de sesión para diagnosticar una ejecución fallida. Un grupo más pequeño puede necesitar resúmenes de eventos, información de firma, detalles de aprobación y acceso a registros cifrados sin procesar durante un incidente. Las personas que operan un agente no necesitan automáticamente acceso permanente al historial de todos los demás desarrolladores.

Define la conservación respondiendo a dos preguntas: durante cuánto tiempo puede investigar realmente el equipo una acción discutida y durante cuánto tiempo conserva el destino su propio registro autorizado. Si el destino guarda el historial de despliegues durante poco tiempo, conserva los metadatos de acción lo suficiente para correlacionarlos. Si un requisito legal o contractual cambia ese periodo, documenta el requisito y quién es responsable de él. «Conservarlo todo» suele significar que no se ha tomado ninguna decisión.

La eliminación también necesita pruebas. Registra la versión de la política de conservación y el hecho de que se produjo una eliminación o agregación programada. No conserves el contenido eliminado solo para demostrar que lo eliminaste. Para analizar tendencias a largo plazo, agrega los recuentos por categoría de operación y resultado después de que caduquen los registros detallados.

Construye el registro en la puerta de enlace y prueba las rutas problemáticas

La implementación más segura captura los datos de revisión donde tiene lugar la acción que utiliza la credencial. Un agente debe solicitar una acción mediante una interfaz limitada, la puerta de enlace debe autenticar el proceso local y aplicar la autorización, y la puerta de enlace debe ejecutar la operación HTTP o SSH. El agente recibe el resultado, mientras el registro de revisión captura los datos de la acción.

Sallyport sigue este esquema para agentes compatibles con MCP: el componente local sp mcp dirige las acciones HTTP y SSH a través de la aplicación, cuya bóveda cifrada mantiene las credenciales de API y SSH fuera del contexto del agente. Su diario de sesiones y su diario de actividad se proyectan desde el mismo registro de auditoría cifrado y ciego a escritura, por lo que la autorización de la sesión y las llamadas individuales permanecen conectadas sin que el agente tenga que guardar un secreto.

Prueba el diseño con fallos que las demostraciones normales del camino feliz suelen evitar:

1. Envía una solicitud que falle después de que el destino repita una cabecera de autorización falsa. Confirma que el registro guarda una categoría de error y el estado, no la cabecera ni el cuerpo de la respuesta.
2. Inicia dos procesos con el mismo nombre visible, pero con identidades de ejecutable diferentes. Confirma que la vista de revisión separa sus sesiones.
3. Aprueba una sesión, termínala y luego inicia un proceso nuevo. Confirma que la aprobación anterior no se aplica a la nueva ejecución.
4. Fuerza un tiempo de espera y reintenta. Confirma que los registros conectan los intentos con una llamada y conservan el hecho de que el resultado es incierto.
5. Modifica un evento de prueba almacenado y ejecuta la verificación de integridad. Confirma que el verificador informa del fallo y que el equipo tiene un procedimiento de respuesta por escrito.

Hazlo antes de añadir paneles, resúmenes o explicaciones generadas por modelos. Un feed de actividad pulido no puede compensar un registro de eventos que filtre un token o no pueda distinguir un ejecutable de otro.

Los registros de revisión se ganan la confianza cuando son lo bastante limitados para protegerlos, lo bastante específicos para investigarlos y están anclados en el lugar donde realmente ocurre una acción externa. Si un registro no puede decirte quién actuó, qué autoridad lo cubría, qué límite cruzó y qué resultado volvió, necesita mejores campos. Si contiene la conversación completa, contiene demasiado.