Uno de los puntos con mayor especificación técnica en la carta abierta sobre defensa cibernética colectiva es este:
“Construir herramientas de observabilidad y seguridad, garantizar las identidades agénticas son rastreables y responsables, y compartir las mejores prácticas en monitoreo continuo.”
Es un problema relativamente nuevo para la mayoría de los equipos de seguridad: no se trata de auditar lo que hizo un usuario humano o una cuenta de servicio tradicional, sino lo que hizo un Agente de IA lo hizo actuando de forma autónoma o semiautónoma, encadenando potencialmente múltiples llamadas a herramientas, sistemas y APIs. Esta guía trata sobre cómo construir esa trazabilidad desde cero.
Por qué las identidades agénticas rompen los modelos de auditoría tradicionales
Un registro de auditoría clásico responde “¿qué usuario realizó esta acción?”. Con los agentes de IA, la pregunta correcta tiene múltiples capas: ¿qué agente, invocado por qué usuario o proceso, con qué mensaje o instrucción dada, ejecutando qué herramienta, con qué permisos heredados, como parte de qué cadena de decisiones? Si tu sistema de registro no captura esas capas, tienes una identidad no rastreable, exactamente lo que la carta te pide que arregles.
Paso 1 — Diseñar el modelo de identidad del agente
Antes de instrumentar nada, define cómo se identifica un agente en tu sistema:
- Una identidad única y persistente por agente (no reutilices la misma credencial de cuenta de servicio para múltiples agentes con diferentes propósitos).
- Enlace explícito desde el agente → propietario/equipo humano responsable. Cada agente tiene un propietario, sin excepciones, al igual que una cuenta de servicio debería tener uno hoy en día.
- Ámbito de permisos vinculado a la tarea, no todo el sistema. Un agente de triaje de alertas no necesita acceso de escritura a producción.
Paso 2: Instrumentar toda la cadena de decisiones
Para cada acción que ejecuta un agente, registre como mínimo:
| Campo | Por qué importa |
|---|---|
| ID único de sesión/invocación | Te permite reconstruir la cadena completa de una tarea |
| Usuario o proceso que invocó al agente | Rendición de cuentas de origen |
| Indicación recibida | Contexto de por qué actuó de esa manera |
| Herramientas invocadas y parámetros | Acciones concretas que tomó |
| Resultado de cada llamada a la herramienta | Qué información tenía el agente para decidir su próximo paso |
| Permisos efectivos en el momento de la acción | Auditar si actuó dentro de su ámbito autorizado |
| Marca de tiempo de cada paso | Correlación temporal con otros eventos de seguridad |
json
{
"session_id": "agent-run-8f2a1c",
"invocado_por": "usuario:jsmith / servicio:incident-triage-pipeline",
"identidad_de_agente": "agente:soc-triage-01",
"equipo_propietario": "operaciones de seguridad",
"pasos": [
{
"herramienta": "consultar_siem",
"parámetros": {"consulta": "alert_id:4471"},
"marca de tiempo": "2026-08-30T14:02:11Z",
"permisos_utilizados": "leer:siem"
},
{
"herramienta": "isolar_host",
"parámetros": {"anfitrión": "srv-042"},
"marca de tiempo": "2026-08-30T14:02:19Z",
"permisos_utilizados": "escribir:aislamiento-de-red",
"requiere_aprobación": cierto,
"aprobado_por": "humano:analyst_gperez"
}
]
}Paso 3 — Responsabilidad real: aprobación humana para acciones irreversibles
La trazabilidad sin controles de responsabilidad es solo un registro bonito después de los hechos. Para acciones de alto impacto o irreversibles (aislar un host de producción, revocar credenciales, modificar reglas de cortafuegos), el diseño debe hacer cumplir:
- Una puerta de aprobación explícita antes de la ejecución, no solo un registro posterior a los hechos.
- Imposibilidad técnica para que el agente se autoapruebe (separación entre solicitante y aprobador, de la misma manera que funcionan los controles financieros).
- Tiempo de espera y alternativa segurasi la aprobación no llega en un plazo razonable, el agente debe fallar de manera segura (no ejecutarse por defecto), excepto en escenarios de baja criticidad explícitamente preautorizados.
Paso 4 — Monitoreo continuo del comportamiento agéntico
Más allá del registro de auditoría, instrumenta la detección de anomalías específica para agentes:
- Desviación de los patrones normales de uso de herramientasun agente de triaje que invoca repentinamente herramientas fuera de su conjunto habitual es una señal de alarma (posible inyección de instrucciones o uso indebido).
- Volumen de acciones anómaloun agente que ejecuta 500 acciones en un minuto cuando su línea base es de 5 por minuto.
- Intentos de escalar privilegios o acceder a recursos fuera del ámbito, lo cual debe ser bloqueado a nivel de política, pero también debe activar alertas si se intenta.
Paso 5 — Compartir el modelo, no solo usarlo internamente
La carta exige explícitamente “compartir las mejores prácticas en el monitoreo continuo”. Si su organización participa en un ISAC o en un grupo de intercambio de inteligencia sobre amenazas específico del sector, considere compartir patrones (anonimizados) de comportamiento agéntico anómalo que haya detectado; esto se conecta directamente con el enfoque de defensa colectiva abordado en la publicación sobre el intercambio de inteligencia sobre amenazas.
Lista de verificación de implementación
- ☐ Asignar una identidad única y persistente a cada agente, con un propietario humano explícito
- ☐ Registrar mediante instrumentos la cadena completa (invocación → herramientas → resultados → permisos efectivos)
- ☐ Implementar una puerta de aprobación humana obligatoria para acciones irreversibles
- ☐ Configurar respaldo seguro en caso de tiempo de espera de aprobación
- ☐ Implementar la detección de anomalías para el comportamiento agéntico (patrón, volumen, intentos de escalamiento)
- ☐ Evaluar qué patrones anonimizados podrían compartirse con su ISAC o grupo sectorial
Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa cibernética colectiva (Agosto de 2026). Volver a la guía completa.
