Falta de atribución y forense

Cuando algo sale mal con un agente, la primera pregunta es siempre la misma: ¿qué hizo realmente, y quién cambió la política que se lo permitió? Sin un rastro no puedes responder ninguna. No puedes mostrarle a un auditor que un control estaba en vigor el día en cuestión, no puedes distinguir un ataque real de un falso positivo ruidoso, y no puedes reconstruir la ejecución que filtró la fila. OrcaRouter registra la respuesta a medida que avanzas. Cada prompt examinado, cada llamada a herramienta, cada aprobación, y cada edición de política aterriza en un registro consultable con alcance de espacio de trabajo — correlacionado de vuelta con la ejecución y sesión del agente que lo produjo. Esta página muestra cómo usar ese registro como un rastro de auditoría de agentes de IA: desde una sola ejecución sospechosa hasta un reporte firmado que entregas a un auditor.

​

1. Los cuatro registros detrás de un rastro de auditoría de agentes de IA

La atribución proviene de cuatro flujos independientes, cada uno correlacionado con la misma ejecución y sesión para que puedas pivotar entre ellos: El tejido conectivo es el id de ejecución de agente y sesión. Una coincidencia de guardrail y un evento de firewall de la misma conversación llevan el mismo linaje de ejecución, así que “esta ejecución enmascaró un correo, luego intentó un fetch que denegamos, luego fue aprobada para una escritura” se lee como una historia en vez de tres logs desconectados.

​

2. Matches de Guardrail — qué se examinó (Member)

Cada vez que una regla de guardrail se dispara, el gateway escribe una coincidencia. El feed vive en la página de Guardrails (pestaña Matches) y es legible por cualquier miembro del espacio de trabajo. Cada coincidencia registra el tipo de regla, la acción tomada (block / mask / flag / annotate / spotlight), la etapa (input / output), una cadena de detalle, y el linaje de ejecución de la solicitud que la disparó. Lístala, agrúpala por guardrail o tipo de regla, filtra por acción, profundiza en una coincidencia, o exporta el feed a CSV. Una regla ruidosa también es parte del rastro. Marca una coincidencia como falso positivo con POST /api/guardrail/match/:id/mark-fp (Admin) para que tu señal se mantenga limpia y tus reportes no sobre-cuenten.

​

3. Events & Runs del Firewall — qué hizo el agente (Developer+)

Donde Matches cubre texto, los Events del firewall cubren acciones. Cada evaluación de llamada a herramienta se registra con su veredicto, superficie, nombre de herramienta y — críticamente — la ejecución y sesión del agente a la que pertenece. Las lecturas de Events, el resumen de Runs/sessions, y la traza por ejecución requieren Developer+; los feeds más ligeros de Discovered-tools y anomalías están abiertos a cada Member. La vista Runs & sessions es el caballo de batalla forense: resume los eventos por ejecución de agente en un desglose de veredictos, las herramientas y modelos distintos que la ejecución tocó, y marcas de tiempo de primera/última vez visto — la respuesta de “qué hizo realmente este agente” en una pantalla. Más allá de los veredictos estáticos, el feed de anomalías marca desviaciones de la línea base de hora-de-la-semana aprendida de cada espacio de trabajo (un promedio móvil de 14 días) — picos de tasa y coste, retry_loop, y transiciones novel_path — así que un patrón permitido-pero-anormal aún emerge en el registro.

​

4. Decisiones de aprobación — quién dijo que sí (acción de auditoría)

Cuando una regla resuelve a pending_approval, la llamada retenida se convierte en una revisión fuera de banda (ver el flujo HITL del Firewall). La decisión es parte del rastro: aprobar o rechazar escribe una fila de auditoría de espacio de trabajo — firewall_approval_approve o firewall_approval_reject — nombrando al actor. Las decisiones son first-writer-wins e idempotentes, y si la regla subyacente cambió tras la retención, el enriquecimiento anota que el contexto cambió. Así que una llamada a herramienta retenida-luego-aprobada es totalmente atribuible de extremo a extremo: el evento del firewall muestra la retención, la fila de auditoría muestra quién la liberó, y ambos correlacionan con la misma ejecución.

​

5. Auditoría de cambios de política — quién cambió las reglas

Un rastro del comportamiento de un agente solo es confiable si también puedes probar cuál era la política en el momento — y quién la cambió. Los Guardrails mantienen un historial de versiones completo. Cada creación, actualización y eliminación escribe una fila de historial versionada en la misma transacción que el cambio. Abre History en un guardrail para ver cada versión con autor y marca de tiempo, diferencia dos cualesquiera, y revierte a una más antigua (la reversión se registra como una nueva versión — el historial nunca se muta). Los cambios de política, regla y configuración del Firewall escriben cada uno una fila de auditoría de espacio de trabajo después de que el cambio se confirma — firewall_policy_update, firewall_rule_create, firewall_settings_update, etc. — y los cambios de nivel de autonomía (firewall_autonomy_applied / firewall_autonomy_undone) capturan la instantánea del estado previo que potencia el deshacer de un clic. Los secretos y blobs de reglas nunca se registran.

​

6. Un ejemplo trabajado: rastrea una ejecución sospechosa

Supón que una ejecución se marca por una llamada saliente inesperada. Desde la consola, con una sesión Developer+: Una ejecución, cuatro registros correlacionados, sin arqueología de log-grep. Para las defensas de exfiltración en sí, ver Exfiltración de datos y Llamadas a herramienta peligrosas.

​

7. Reportes de cumplimiento firmados — un rastro que un auditor puede verificar

Para prueba externa, la superficie de Cumplimiento convierte este rastro en un único artefacto. Navegar el catálogo de marcos, paquetes y preparación está abierto a cada Member y es gratis; instalar un paquete, generar un reporte, ir en vivo, y establecer la residencia de datos son acciones de Admin de espacio de trabajo en un plan de pago (server-gated). Un reporte de cumplimiento está firmado con Ed25519 con un hash de contenido SHA256 y es públicamente verificable — el destinatario lo verifica sin una cuenta de OrcaRouter: Los reportes se exportan como CSV / JSON / PDF. Los marcos incluyen soc2, hipaa, gdpr, iso_27001, iso_42001, nist_ai_rmf, pci_dss, la EU AI Act (eu_ai_act), y el OWASP Top 10 para Aplicaciones de LLM (owasp_llm), entre otros — instalar un paquete materializa los guardrails y políticas de firewall coincidentes para que los controles sobre los que reportas sean los controles realmente aplicados.

​

8. Retención y el derecho al olvido

Un registro forense está acotado, no es para siempre. Los logs de solicitud por defecto retienen 30 días y están limitados por el servidor a un máximo duro de 180 días. Cuando un usuario se auto-elimina, aplica una ventana de gracia de 30 días, tras la cual su PII se depura y la cascada purga sus coincidencias de guardrail, logs de solicitud y eventos de firewall — satisfaciendo las obligaciones de derecho al olvido / DSAR mientras mantiene intacto el historial de auditoría agregado.

​

9. Adónde ir a continuación