| Capa de evidencia |
Pregunta que necesita respuesta |
Registro que debe estar correlacionado |
| Origen |
¿Quién inició esa ejecución? |
identificador de identidad, sesión o ejecución, tiempo y correlación autenticados |
| Agente |
¿Qué agente y configuración participaron? |
identificador y versión del agente, modelo cuando corresponda, flujo de trabajo y políticas aplicables |
| Herramienta |
¿A qué intentó llamar el agente? |
nombre de la herramienta, ID de llamada, parámetros requeridos, resultado o error |
| Autorización |
¿Se permitió la acción? ¿Bajo qué condiciones? |
permitir/denegar decisión, política y versión, identidad delegada, credencial o token y ámbitos pertinentes |
| Sistema externo |
¿La operación llegó al proveedor y fue aceptada? |
registro de auditoría o actividad de Drive, GitHub, correo electrónico u otro servicio |
| Estado |
¿Qué cambió realmente? |
recurso afectado, estado anterior cuando esté disponible, cambio observado y estado posterior |
La distinción es importante porque una llamada a una herramienta no prueba por sí sola que hubo un cambio externo. Asimismo, poseer un token con un alcance determinado no prueba que una operación específica haya sido autorizada por todas las políticas intermedias.
Qué preservar una vez que se descubre la acción ilícita
Si el incidente aún produce daños, es necesario coordinar la contención y la preservación de las pruebas. El NIST señala que las estrategias de respuesta pueden implicar un equilibrio entre una investigación más profunda y una recuperación rápida; No deberías mantener activa una carrera peligrosa sólo para conseguir una pista más perfecta.
Un orden útil es:
- Detenga más acciones inapropiadas cuando sea necesario y abra un identificador único para el incidente. Registre el momento de la detección y quién inició la respuesta.
- Conserve los registros existentes en su forma original. Exporte registros de ejecución, seguimientos, eventos de autorización y auditorías de sistemas externos antes de que las políticas de retención eliminen datos relevantes.
- Capture identificadores de correlación. El ID de seguimiento, el ID de extensión, el ID de ejecución, el ID de llamada de herramienta, el ID de solicitud y los identificadores de recursos le permiten vincular eventos registrados por diferentes componentes.
- Conserve la configuración válida actualmente. Esto puede incluir la versión del agente, el flujo de trabajo, las herramientas, la política de autorización y la revisión de la política utilizada en la decisión.
- Recopile evidencia sobre los sistemas objetivo. No se limite a lo que el agente dijo que hizo; busque la operación en el registro de auditoría del servicio que recibió la llamada.
- Registre por separado el estado justo después del incidente y el estado actual. Es posible que otra persona o automatización haya modificado el mismo recurso más adelante.
- Documente su propia investigación. Quién recopiló cada registro, cuándo, dónde y qué transformaciones se realizaron también son parte de la evidencia.
SP 800-61 Rev. 3 recomienda que se registren las acciones tomadas durante la investigación, que se preserve la integridad y procedencia de estos registros y que los datos y metadatos del incidente se recopilen y conserven de acuerdo con los procedimientos de preservación y retención de la organización.
Cómo determinar quién solicitó la acción
“¿Quién preguntó?” Puede tener tres respuestas diferentes.
El primero es el iniciador de la tarea: la persona, servicio, evento o automatización que originó la ejecución. El segundo es el agente o proceso que decidió llamar a la herramienta. La tercera es la identidad presentada al servicio externo, que puede ser un usuario delegado, una cuenta de servicio, una aplicación OAuth u otro principal.
Mezclar estas identidades puede llevar a una conclusión equivocada. Si el registro del proveedor muestra una cuenta técnica, no significa necesariamente que esa cuenta haya originado la intención. Puede que simplemente haya sido la identidad utilizada para ejecutar una solicitud iniciada previamente por otra persona o sistema.
Por lo tanto, el identificador de una ejecución debe seguir la cadena en la medida de lo técnicamente posible. Los registros externos también pueden ayudar. La API de Google Workspace Reports, por ejemplo, incluye campos de actores e información sobre aplicaciones OAuth en sus registros de actividad; El registro de auditoría de GitHub puede registrar el actor, la acción, el tiempo y, según el evento, información sobre la forma de autenticación utilizada.
El objetivo no es elegir un único “culpable” en el log, sino responder con precisión: quién la inició, quién la ejecutó y con qué identidad la operación llegó a su destino.
Cómo probar lo que llamó el agente
La capa de observabilidad del agente debe registrar la ejecución de la herramienta independientemente de la conversación que se muestra al usuario.
Las convenciones GenAI actuales de OpenTelemetry, aún clasificadas como Desarrollo, definen un lapso específico para la ejecución de la herramienta. En la convención consultada, gen_ai.operación.nombre y gen_ai.tool.name son elementos centrales; se puede registrar un identificador de llamadas cuando esté disponible, mientras que los argumentos y resultados son campos de participación voluntaria.
Esto proporciona una plantilla útil para una pista técnica:
ejecución del agente → nombre de la herramienta → ID de llamada → parámetros → resultado o error.
Sin embargo, existe una restricción importante. Las propias convenciones de OpenTelemetry advierten que las instrucciones, mensajes, argumentos y resultados de herramientas pueden contener información confidencial. Instrumentar todo de forma indiscriminada puede convertir el sistema de observabilidad en un nuevo depósito de credenciales, datos personales o contenidos confidenciales.
La solución no es abandonar parámetros útiles para la investigación, sino definir de antemano qué se registrará, enmascarará, truncará o eliminará. No es necesario almacenar secretos y tokens en texto abierto para correlacionar una llamada.
También es necesario diferenciar el resultado de la herramienta del efecto probado. Una respuesta exitosa puede indicar que una API aceptó la solicitud, pero la confirmación del estado debe provenir del sistema responsable del recurso siempre que sea relevante para el incidente.
Cómo acreditar lo autorizado
Esta es una de las partes más fáciles de reconstruir de forma incompleta.
Existen al menos tres niveles diferentes de autorización:
La concesión o credencial disponible. Muestra la capacidad que ha recibido una aplicación. En Google Workspace, por ejemplo, los registros OAuth pueden mostrar eventos de autorización, denegación y revocación, así como ámbitos asociados.
La decisión de política para esa operación. En arquitecturas que utilizan un mecanismo de autorización externo, lo ideal es conservar una decisión correlacionable. Open Policy Agent, por ejemplo, ofrece registros de decisiones que pueden contener decision_id, trace_id, revisión del paquete de políticas, entrada proporcionada a la política, resultado de la decisión y tiempo.
La decisión del sistema de destino. Incluso si la aplicación tiene un token y una política intermedia devuelve "permitido", la API final aún puede aceptar, rechazar o manejar la solicitud de manera diferente.
Esta separación evita un error recurrente: afirmar que “la acción fue autorizada” solo porque el token tenía un alcance amplio. El alcance ayuda a explicar el límite de capacidad de esa credencial; la investigación de la operación específica también necesita verificar la decisión aplicada en ese momento y la respuesta del objetivo.
Un registro de autorización realmente útil debería permitirle responder: qué principal solicitó acceso, a qué recurso y operación, utilizando qué política, qué versión de la política, qué decisión se tomó y qué ejecución originó la consulta.
El proveedor externo es la referencia para saber si la acción ocurrió
Después de identificar la llamada del agente, busque la misma operación en el sistema conectado.
En Google Drive, la API de actividad de Drive proporciona un historial de actividad con elementos como acción, actor, objetivo y tiempo. La documentación también advierte que no toda la actividad será necesariamente visible para todos los usuarios autenticados: la visibilidad puede depender de los permisos del objeto. Por lo tanto, la ausencia de una consulta específica no debe interpretarse automáticamente como prueba de que la acción nunca ocurrió.
Para entornos administrados de Google Workspace, Drive Activity Report puede proporcionar creación, edición, uso compartido de eventos y otras actividades y documenta una ventana de consulta de hasta 180 días.
En GitHub Enterprise Cloud, el registro de auditoría de la organización registra las actividades que afectan a la organización y puede incluir actor, acción, repositorio, hora, método de autenticación y otros campos según el evento. La documentación consultada reporta una retención de 180 días para el rastro general de la organización, mientras que los eventos Git tienen condiciones específicas y una retención de sólo siete días para ciertos accesos al registro de auditoría.
Estos plazos muestran por qué no se debe retrasar la recolección. El período de investigación útil puede ser más corto de lo que el equipo espera y las políticas o los productos pueden cambiar. La retención, la concesión de licencias y la disponibilidad de determinados eventos se deben verificar con el proveedor utilizado en el momento del incidente.
El estado final requiere más que encontrar un evento exitoso
Buscar la operación en el registro de auditoría responde "se produjo un cambio". Aún queda por responder “¿cuál fue el resultado relevante?”.
Para hacer esto, separe cuatro puntos en el tiempo:
- el último estado conocido antes de la operación;
- el evento de cambio atribuido a la ejecución investigada;
- el estado observado inmediatamente después, cuando hay un registro;
- el estado actual.
Esta separación evita asignar al agente un cambio posterior realizado por una persona, webhook, flujo de trabajo o segundo agente.
Imagínese un caso en el que un agente de mantenimiento del repositorio intenta cambiar una configuración. La traza confirma la llamada de la herramienta; la decisión de autorización confirma que dicha solicitud fue permitida; el registro de auditoría confirma un cambio en el repositorio; Horas después, un administrador vuelve a modificar la configuración. El estado actual ya no representa, por sí solo, el efecto original del agente.
Cuando el sistema proporciona versiones, historial de cambios, ID de eventos o revisiones de recursos, estas referencias pueden aumentar la confianza en la reconstrucción. Cuando no se pueda recuperar el estado anterior, el informe debería decirlo explícitamente en lugar de reconstruirlo mediante suposiciones.
Reúna la cronología según la evidencia, no según la narrativa del agente
El informe de incidentes debe ordenar los eventos por marcas de tiempo normalizadas y utilizar identificadores para vincularlos.
Una secuencia hipotética podría mostrar que la tarea se inició en una sesión autenticada, que una ejecución específica del agente generó una llamada a la herramienta, que una política devolvió permiso, que el proveedor recibió la operación y que una lectura posterior confirmó el nuevo estado.
Lo que importa es que cada pasaje sea demostrado por su fuente apropiada. Algunas combinaciones cambian mucho la conclusión:
- Hay una llamada a la herramienta, pero no hay una operación correspondiente en el proveedor y el recurso no ha cambiado: Puede haber habido una operación de falla, bloqueo o sin efecto. La llamada por sí sola no prueba el cambio.
- Hay un cambio en el proveedor, pero no hay rastro de agente correspondiente: hay una brecha de telemetría o el cambio puede tener otro origen. No atribuyas la causalidad sólo a la proximidad del tiempo.
- Hay una decisión "permitida", pero la llamada falló: existía autorización, pero esto no prueba que la ejecución sea exitosa.
- Hay un cambio atribuido al agente y otro cambio posterior realizado por otro actor: preservar ambos; el estado actual no debe atribuirse enteramente al primer evento.
La guía actual del NIST para la respuesta a incidentes pone énfasis en determinar la secuencia de eventos y los activos involucrados, en lugar de depender de una única fuente de evidencia.
Reconstruir confianza debería aparecer en el informe
No todos los incidentes terminarán con la misma calidad de evidencia.
Una finalización de alta confianza puede combinar identidad autenticada, seguimiento correlacionado, invocación de herramientas, decisión de autorización, evento de proveedor y confirmación de estado.
Una conclusión de confianza media puede tener una brecha; por ejemplo, el proveedor confirma la operación y el seguimiento confirma la herramienta, pero la decisión de política en ese momento no se conserva.
Una conclusión de baja confianza depende principalmente del tiempo aproximado, la conversación o las inferencias sin ID comunes entre capas.
Registrar esta diferencia es más útil que llenar el vacío con certeza artificial. NIST recomienda preservar la integridad y procedencia de los datos del incidente y también reconoce que la evidencia recopilada debe manejarse de acuerdo con los procedimientos de retención y preservación de la organización.
Guardar todo también es un riesgo
La observabilidad forense no significa registrar permanentemente cada mensaje, documento, argumento de herramienta y respuesta de API.
Los datos más ricos para la depuración son precisamente aquellos que pueden contener información personal, contenido confidencial, secretos o datos comerciales. Las convenciones GenAI de OpenTelemetry señalan explícitamente el riesgo de información confidencial en mensajes, instrucciones, argumentos y resultados.
El diseño del registro debe equilibrar la investigación y la exposición: los identificadores y los metadatos pueden permanecer disponibles por más tiempo, mientras que el contenido confidencial puede requerir enmascaramiento, acceso restringido o menor retención. Los propios registros de la investigación también necesitan protección de confidencialidad e integridad, como recomienda SP 800-61 Rev. 3.
Cerrar el incidente debería producir controles para la siguiente ejecución
Una investigación útil no termina con "el agente cometió un error". Necesita identificar en qué capa falló el control.
Si la causa fue una mala interpretación, puede ser necesario revisar la validación de la intención. Si la llamada a la herramienta recibió parámetros inapropiados, la solución puede estar en el contrato de la herramienta. Si la política autorizó más de lo que debería, entra en juego la revisión de la autorización. Si nadie puede decir qué sucedió porque los identificadores no cruzan las capas, el problema también es de observabilidad.
Aquí es donde la agenda forense se encuentra con la agenda preventiva. Una vez que sepa qué permisos contribuyeron al incidente, el siguiente paso es revisar cómo limitar los permisos antes del incidente vinculando este artículo a Agente con Drive, Email y GitHub: cómo aplicar privilegios mínimos sin interrumpir la automatización.
En la dirección opuesta, el artículo preventivo puede señalar este contenido con el ancla cómo investigar una acción incorrecta por parte del agente. La URL del artículo existente no fue proporcionada en la agenda, por lo que el enlace debe insertarse en el CMS sin inventar una dirección.
El incidente se puede considerar técnicamente reconstruido cuando el equipo puede responder, con evidencia y un grado explícito de confianza: quién inició la ejecución, cómo llamó el agente, qué fue autorizado, qué ejecutó realmente el proveedor y qué estado resultó de la operación.
Temas de este artículoagentes de IAautorizaçãoforense digitallogs de auditoriaobservabilidaderesposta a incidentes
