Monitoreo de seguridad del agente de IA con eventos estructurados
El monitoreo de seguridad del agente de IA debe comenzar cuando la aplicación toma una decisión ejecutable: antes de que una herramienta lea datos protegidos, cambie de estado, ejecute código o llame a un sistema externo. La telemetría útil no es una copia de la carga útil del mensaje o de la herramienta. Es un registro delimitado de qué clase de acción se solicitó, qué versión de política la evaluó, si se permitió, se denegó o se envió a aprobación, y qué resultado final siguió.
Telemetry es una superficie de análisis para aquellas decisiones estructuradas. No aplica autorización, herramientas de espacio aislado, no aísla a los inquilinos, no administra secretos ni reemplaza el sistema que preserva la evidencia de seguridad. Mantenga la aplicación en la capa de aplicación y política, luego envíe solo las dimensiones aprobadas necesarias para revisar el comportamiento a lo largo del tiempo.
Comience con una herramienta y un inventario de riesgos
Haga un inventario de cada herramienta que el agente pueda descubrir o invocar. Clasifíquelo por el efecto que puede tener en lugar de por un nombre para mostrar descriptivo:
| clase de acción | Ejemplo | Pregunta de revisión típica |
|---|---|---|
read_only |
buscar en un índice público aprobado | ¿Puede el resultado exponer datos restringidos o cruzar los límites de un inquilino? |
local_state_change |
escribir un archivo generado en un espacio de trabajo aislado | ¿El destino tiene alcance y es recuperable? |
external_state_change |
actualizar un ticket, una fila de base de datos o un recurso en la nube | ¿Tiene el actor autoridad para el objetivo y la operación exactos? |
code_execution |
ejecutar un comando o trabajo | ¿Qué aislamiento, lista de permitidos, límite de tiempo y límite de recursos se aplican? |
credential_use |
llamar a un servicio con credenciales delegadas | ¿La credencial tiene como alcance el usuario, el recurso y la acción solicitada? |
La clasificación de riesgos es una decisión de producto y de seguridad. No copie este ejemplo en producción como política. Defina valores controlados con las personas propietarias de la autorización, la respuesta a incidentes, la privacidad y los sistemas afectados.
El OWASP Top 10 para aplicaciones de modelos de lenguaje grandes trata riesgos como la inyección rápida, el manejo inseguro de la salida, la agencia excesiva y la divulgación de información confidencial como problemas distintos. Monitorear una decisión de autorización puede ayudar a investigar esos límites, pero un panel no es una mitigación en sí mismo. El Guía de inyección rápida de OWASP también explica por qué el contenido que no es de confianza puede influir en el comportamiento del modelo incluso cuando la aplicación no pretendía que actuara como una instrucción.
Registre la decisión de política antes de la ejecución.
Utilice un evento agent_tool_authorization_decided para cada decisión de política final. Su esencia es un intento de llamada lógica a una herramienta, no una respuesta de modelo ni una ejecución completa del agente. Los campos sugeridos incluyen:
event_id,timestamp_utc,run_idytool_call_idpara identidad y correlación;workflow,tool_nameyaction_classcomo dimensiones operativas limitadas;risk_level,decision,reason_codeypolicy_versioncomo campos de política controlados;release,environmenty unaccount_idseguro para la privacidad para el análisis de cambios.
El esquema de evento de autorización de herramienta de agente documenta el contrato inicial completo. Mantenga decision limitado a valores como allowed, denied y approval_required. Una razón como scope_denied o human_approval_required es más segura y comparable que una explicación de modelo de forma libre.
No incluya indicaciones sin procesar, finalizaciones, argumentos de herramientas, resultados de herramientas, documentos recuperados, encabezados de autorización, cookies, tokens, cadenas de conexión ni contenido del cliente. El nombre de una herramienta debe ser un identificador estable como database_write, no una llamada de función serializada.
Mantenga separados los resultados de la decisión y la ejecución
La autorización responde sobre si la acción puede proceder. No prueba que la ejecución haya sido exitosa o que el resultado comercial fuera seguro. Emita un evento de terminal independiente como agent_tool_completed con los mismos run_id y tool_call_id.
| Evento | grano | Resultado útil |
|---|---|---|
agent_tool_authorization_decided |
una decisión política final | permitido, denegado o se requiere aprobación |
agent_approval_resolved |
una revisión humana completa | aprobado, rechazado, caducado o cancelado |
agent_tool_completed |
un intento de ejecución terminal | éxito, error, tiempo de espera agotado o cancelado |
agent_run_completed |
una ejecución de agente terminal | éxito, fracaso o transferencia humana de la tarea |
agent_policy_changed |
un cambio de política publicado | versión anterior, nueva versión, propietario e implementación |
Mantener estos granos separados hace visibles los casos importantes: una llamada permitida puede fallar, una aprobación puede caducar sin ejecución y una llamada de herramienta técnicamente exitosa aún puede conducir a un resultado de agente rechazado.
Aplicar autorización en el servidor de recursos.
Para implementaciones de protocolo de contexto modelo, siga las instrucciones de autorización y seguridad del protocolo en el límite de implementación. El Especificación de autorización MCP describe las responsabilidades de autorización, mientras que el Guía de mejores prácticas de seguridad de MCP cubre amenazas y mitigaciones para los sistemas implementados. El Especificación de herramientas MCP trata las anotaciones de herramientas como sugerencias en lugar de un límite de seguridad confiable.
En la práctica:
- Tome la decisión de política en el código propietario del recurso protegido.
- Valide allí el actor, el inquilino, el recurso de destino, la operación y el alcance delegado.
- Exija la aprobación humana para las clases de acción que su política marca como trascendentales.
- Emitir la decisión limitada sólo después de que la evaluación sea definitiva.
- Ejecute la herramienta solo cuando la capa de cumplimiento lo permita.
- Emite un resultado de terminal separado después de la ejecución.
Nunca confíe en el modelo para informar por sí mismo que una acción está autorizada. Del mismo modo, no trate la descripción o anotación de una herramienta como prueba de que una operación es de solo lectura o segura.
Revise denegaciones, aprobaciones y cambios de políticas con SQL
El Receta de autorización de herramienta de agente de IA SQL agrupa las decisiones por herramienta y clase de riesgo. Mantiene recuentos absolutos además de la tasa de denegación para que una muestra pequeña no cree una urgencia falsa.
Un panel útil incluye:
- decisiones totales por herramienta, flujo de trabajo, nivel de riesgo y versión;
- recuentos permitidos, denegados y con aprobación requerida;
- tasa de denegación con un denominador de decisión visible;
- antigüedad de la cola de aprobación y resultado de la resolución;
- permitió acciones que luego fracasaron;
- combinación de decisiones antes y después de un cambio de versión de política.
Interprete estas señales con cuidado. Una negativa esperada puede mostrar que la política está funcionando. Una caída en la tasa de denegación puede reflejar una liberación de agente más segura, una política más débil o un cambio en el tráfico. Una cola de aprobación cada vez mayor puede ser un problema de propiedad más que un ataque.
Construir un cronograma de investigación
Correlacione la decisión, la aprobación, el resultado de la herramienta y el resultado de la ejecución con run_id y tool_call_id. Para una ventana de incidente revisada, reconstruya:
- qué flujo de trabajo y versión solicitaron la acción;
- qué versión de política la evaluó;
- el código de decisión y motivo acotado;
- si un humano lo aprobó o lo rechazó;
- si comenzó la ejecución y cómo terminó;
- si la ejecución del agente se completó, falló o se entregó.
Mantenga evidencia detallada en el sistema diseñado para sus requisitos de integridad, acceso, retención y eliminación. Los análisis generales pueden identificar patrones y proporcionar un cronograma reproducible, pero no deben presentarse como un archivo de cumplimiento sin controles verificados.
Validar las rutas de error antes de alertar
Ejercite casos sintéticos para rutas permitidas, denegadas, con aprobación requerida, con aprobación vencida, con error de ejecución y con cambio de versión de política. Confirma que:
- cada llamada de herramienta importante recibe exactamente una decisión final;
- las llamadas denegadas no se ejecutan;
- las llamadas que requieren aprobación no pueden pasar por alto la revisión;
- los identificadores de correlación unen sólo los granos deseados;
- el contenido prohibido nunca llega a la carga útil del evento;
- la falta de telemetría no debilita la aplicación de la ley;
- las alertas utilizan umbrales revisados, volumen suficiente y un propietario explícito.
Comience con Caso de uso de seguridad del agente de IA para obtener un mensaje de implementación o copie Plantilla de auditoría de seguridad del agente de IA. Para conocer el costo, la latencia, los reintentos y la confiabilidad de la herramienta, use Monitoreo de agentes de IA. Para acciones administrativas y de autenticación fuera de los límites del agente, utilice el guía de análisis de auditoría de seguridad más amplio.