Checklist de seguridad de agentes de IA
Doce chequeos en cuatro jugadas. El mismo checklist que corremos sobre código de clientes, destilado de más de 250 vulnerabilidades reales que encontramos en sistemas de agentes, servers MCP y developer tools. Neutral de vendors, completo en esta página, sin producto requerido.
¿Cómo asegurar los agentes de IA de tu empresa?
Con doce chequeos concretos organizados en cuatro jugadas: ver la superficie, controlar las acciones, demostrar lo que pasó y correr el loop. Una sola persona técnica puede correr el primer pase completo en uno o dos días sobre un stack seed, sin equipo de seguridad.
El founder o CTO. Si tienes un coding agent en CI, un server MCP en producción, un bot de soporte con acceso a tools o un asistente interno leyendo tu Notion, esto te aplica.
Cada chequeo suma PASS (2), PARTIAL (1) o FAIL (0). PARTIAL significa que el control existe pero nunca lo probaste o tiene excepciones conocidas. Si nunca lo verificaste, no es un PASS.
Las cuatro jugadas
Las jugadas están secuenciadas: cada una hace posible la siguiente. Reaudita en cada cambio de capacidades.
Mapea dónde corren los agentes, qué permiten sus credenciales y cuáles permisos son de escritura. Todo lo demás depende de esto.
Saca el enforcement del prompt. Estos controles aguantan sin importar qué lea el modelo.
Logs de acciones, política que puedes probar y un diff entre lo que asignaste y lo que corre de verdad.
Revisión que escala, revocación que funciona y una reauditoría cada vez que cambian las capacidades.
¿Lo necesitas en PDF para tu auditor o tu directorio?
Te lo mandamos por correo.
El PDF está en inglés. La versión en español está en camino.
Inventaria cada entorno de agentes
Lista dónde corren agentes y a qué llega cada uno: repos, tools, credenciales, redes.
El hallazgo más común en nuestros audits no es un exploit. Es un entorno que nadie listó: un agente de IDE cableado a credenciales de producción, un bot de CI que quedó de una demo, un server MCP que alguien instaló y olvidó. Los entornos que no listaste son los que te agarran.
Mapea el blast radius de cada credencial
Para cada entorno, escribe la peor acción que sus tokens permiten.
Un agente comprometido por injection puede hacer exactamente lo que sus credenciales permiten. Escribir el peor caso obliga a decidir. Hasta entonces, la empresa está aceptando un riesgo que nadie leyó.
Separa lectura de escritura
Por defecto los agentes solo leen; cada escritura es un permiso explícito con nombre.
Los agentes mayormente leen. El daño está casi siempre en las escrituras: mergear código, borrar registros, mandar mensajes, mover plata. Separarlas te da una palanca de revocación por capacidad en vez de un interruptor único que mata todo.
Pon un gate a las tool calls privilegiadas
Interpone una allowlist determinística entre el input no confiable y el shell, la red y los secretos.
A un modelo se lo puede convencer. Prompt injection es el arte de convencerlo. El enforcement que aguanta corre fuera del modelo: un chequeo determinístico sobre cada llamada privilegiada antes de que ejecute. Si tu control es el system prompt, tienes una probabilidad, no un control.
Fija versiones y verifica la supply chain
Bloquea las fuentes de paquetes y verifica la procedencia antes de que un agente instale nada.
Los agentes instalan código sin que un humano lea el nombre del paquete. Los modelos alucinan nombres plausibles y los atacantes los registran. Suma los typosquats, los scripts que ejecutan al instalar y los servers MCP, que son código de terceros cuyas descripciones de tools entran directo al contexto de tu modelo.
Trata cada prompt como input no confiable
Deja de filtrar contenido; controla lo que el agente puede hacer sin importar qué leyó.
Filtrar contenido hostil no escala. Las injections llegan por READMEs, issues, páginas web, PDFs, invitaciones de calendario y las descripciones de tools de los servers MCP que instalaste. La postura que aguanta es la inversa: asume que todo lo que el agente lee es hostil y asegúrate de que no importe.
Registra la acción, no solo el chat
Guarda las tool calls y sus efectos en un trail con verificación de integridad.
Los transcripts registran lo que el modelo dijo. Los incidentes son sobre lo que hizo: qué archivos tocó, qué requests mandó, qué registros cambió. Y si el agente puede escribir sobre sus propios logs, después de un compromiso nadie puede responder nada.
Haz la política verificable
Firma lo permitido para que un revisor pueda probar qué reglas regían.
Cuando un incidente, una auditoría o el security review de un cliente pregunta qué tenía permitido hacer un agente en una fecha específica, la respuesta tiene que ser demostrable. La política en una wiki o en la cabeza de alguien no se puede probar, y diverge en silencio de lo que todos creen que dice.
Compara lo esperado contra lo reportado
Haz el diff entre la política que asignaste y la que cada entorno aplicó de verdad.
Lo asignado y lo aplicado se separan solos. Un entorno se restaura de una imagen vieja, un hotfix apaga el gateway solo por ahora, un deploy sale sin el paso de política. El drift se atrapa con un diff programado, no con buenas intenciones.
Enruta excepciones, no todo
Los entornos alineados quedan en silencio; a revisión va solo el drift, los gaps y los mismatches.
Hay dos formas de perder el mismo juego. Aprobar todo, y en una semana los humanos sellan sin leer. Alertar todo, y el canal se mutea junto con la única alerta que importaba. La revisión escala solo si lo alineado queda en silencio y la atención humana va a las desviaciones.
Ensaya el kill switch
Documenta cómo revocar el acceso de un agente en minutos y prueba que funciona.
El peor momento para descubrir que la revocación no funciona es durante el incidente. Los tokens sobreviven en caches, las sesiones sobreviven a las credenciales rotadas. Los agentes actúan en segundos, así que la revocación tiene que tomar minutos y estar probada antes de necesitarla.
Reaudita en cada cambio de capacidades
Tool nuevo, token nuevo, modelo nuevo: corre el checklist de nuevo antes del deploy.
El audit que corriste al inicio describe un sistema que dejó de existir tres sprints después. O el checklist corre en cada cambio de capacidades o es un documento sobre el pasado.
Scorecard
Puntúa cada chequeo PASS (2), PARTIAL (1) o FAIL (0). Vuelve a puntuar después de cada cambio de capacidades y al menos una vez por trimestre.
| # | Chequeo | Jugada | Puntaje /2 |
|---|---|---|---|
| 01 | Inventaria cada entorno de agentes | 1 · Ver la superficie | ___ |
| 02 | Mapea el blast radius de cada credencial | 1 · Ver la superficie | ___ |
| 03 | Separa lectura de escritura | 1 · Ver la superficie | ___ |
| 04 | Pon un gate a las tool calls privilegiadas | 2 · Controlar las acciones | ___ |
| 05 | Fija versiones y verifica la supply chain | 2 · Controlar las acciones | ___ |
| 06 | Trata cada prompt como input no confiable | 2 · Controlar las acciones | ___ |
| 07 | Registra la acción, no solo el chat | 3 · Demostrar lo que pasó | ___ |
| 08 | Haz la política verificable | 3 · Demostrar lo que pasó | ___ |
| 09 | Compara lo esperado contra lo reportado | 3 · Demostrar lo que pasó | ___ |
| 10 | Enruta excepciones, no todo | 4 · Correr el loop | ___ |
| 11 | Ensaya el kill switch | 4 · Correr el loop | ___ |
| 12 | Reaudita en cada cambio de capacidades | 4 · Correr el loop | ___ |
| Total | ___ /24 | ||
Llévate la versión para tu auditor
El checklist completo está en esta página y es gratis. La versión en PDF suma lo que un revisor va a pedir: el detalle de cómo correr cada chequeo, los criterios de PASS, los red flags, los incidentes documentados detrás de cada control y el mapeo completo a OWASP Top 10 for Agentic Applications 2026 y a la guía de seguridad MCP de la NSA de mayo 2026. Deja tu correo de trabajo y te lo enviamos, junto con los hallazgos nuevos que publiquemos. Sin spam, te das de baja cuando quieras.
El PDF está en inglés. La versión en español está en camino.
Correrlo a mano o dejar que corra solo
El checklist es neutral y no necesitas ningún producto para correrlo. Ahora, si quieres automatizar partes, esto es lo que construimos. Aguara, nuestro scanner open source, corre gratis y local: cubre los scans del chequeo 05 y 06 sobre tus servers MCP y skills y te ayuda con el inventario del 01. Oktsec Assessment corre los doce chequeos sobre tu flota completa, whitebox, con un reporte accionable por hallazgo. Y Oktsec Control es la Jugada 2 y la Jugada 3 en runtime: el gate determinístico del 04 y el loop de política firmada, registro de acciones y diff de lo esperado contra lo reportado de los chequeos 07 a 10, corriendo solo.
¿Te aplica el EU AI Act? Las obligaciones para sistemas de alto riesgo entran en vigencia el 2 de agosto de 2026. Los chequeos 07 a 09 producen exactamente la evidencia que un auditor va a pedir: qué política regía, qué hizo el agente y que las dos cosas coincidan.
Cómo preparar la evidencia