Checklist de campo · 2026

Checklist de seguridad de agentes de IA

La lista de chequeos que corremos cuando auditamos sistemas de agentes, servers MCP y developer tools: doce chequeos en cuatro fases, cada uno respaldado por incidentes documentados y alineado con la guía MCP de la NSA. Está completa en esta página, gratis y neutral de vendors.

Incidentes documentados detrás de cada chequeo Mapeado a OWASP Agentic 2026 y a la guía MCP de la NSA Primer pase en uno o dos días

¿Cómo asegurar los agentes de IA de tu empresa?

Se aseguran con doce chequeos concretos organizados en cuatro fases: 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.

Las cuatro fases

Las fases están secuenciadas: cada una hace posible la siguiente. Reaudita en cada cambio de capacidades.

Fase 1 · Chequeos 01 a 03

Ver la superficie

Mapea dónde corren los agentes, qué permiten sus credenciales y qué permisos son de escritura. Todo lo demás depende de esto.

Fase 2 · Chequeos 04 a 06

Controlar las acciones

Saca el enforcement del prompt. Estos controles se sostienen sin importar qué lea el modelo.

Fase 3 · Chequeos 07 a 09

Demostrar lo que pasó

Registro de acciones, política que se puede probar y una comparación entre lo que asignaste y lo que realmente corre.

Fase 4 · Chequeos 10 a 12

Correr el loop

Revisión que escala, revocación que funciona y una nueva auditoría cada vez que cambian las capacidades.

Los doce chequeos

Puntúa cada chequeo a medida que lo revisas. PASS si el control existe y lo verificaste. PARTIAL si existe pero nunca lo probaste o tiene excepciones. FAIL si no existe. Si nunca lo verificaste, no es un PASS.

0 de 12 puntuados 0 / 24
Fase 1 · Ver la superficie
01

Anota dónde corre cada agente y a qué puede acceder: repos, herramientas, credenciales, redes.

Por qué importa

El hallazgo más común en nuestras auditorías no es un exploit. Es un entorno que nadie tenía anotado: un agente de IDE con credenciales de producción, un bot de CI que quedó de una demo, un server MCP que alguien instaló y olvidó. El riesgo se concentra en los entornos que quedaron fuera del inventario.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

02

Para cada entorno, anota cuál es la peor acción que permiten sus tokens.

Por qué importa

Un agente comprometido por injection puede hacer exactamente lo que sus credenciales permiten. Poner el peor caso por escrito convierte un riesgo implícito en una decisión explícita. Hasta ese momento, la empresa está aceptando un riesgo que nadie evaluó.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

03

Por defecto, un agente solo lee; cada permiso de escritura se otorga aparte, con nombre y alcance propios.

Por qué importa

Los agentes leen la mayor parte del tiempo, pero el daño está casi siempre en las escrituras: mergear código, borrar registros, enviar mensajes, mover fondos. Separar los permisos permite revocar capacidad por capacidad, en lugar de depender de un interruptor único que detiene todo.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

Fase 2 · Controlar las acciones
04

Coloca una allowlist determinista entre el input no confiable y el shell, la red y los secretos.

Por qué importa

A un modelo se lo puede convencer; el prompt injection existe porque sigue instrucciones en lenguaje natural. El enforcement que se sostiene corre fuera del modelo: un chequeo determinista sobre cada llamada privilegiada antes de que se ejecute. Un system prompt es una probabilidad, no un control.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

05

Restringe las fuentes de paquetes y verifica la procedencia antes de que un agente instale algo.

Por qué importa

Los agentes instalan dependencias sin que ningún humano lea el nombre del paquete. Los modelos alucinan nombres plausibles y los atacantes los registran. A eso se suman los typosquats, los scripts que se ejecutan durante la instalación y los servers MCP: código de terceros cuyas descripciones de herramientas entran directo al contexto del modelo.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

06

No dependas de filtrar contenido: controla qué puede hacer el agente, sin importar qué haya leído.

Por qué importa

Filtrar contenido hostil no escala. Las injections llegan por READMEs, issues, páginas web, PDFs, invitaciones de calendario y las descripciones de herramientas de los servers MCP instalados. La postura que se sostiene es la inversa: asumir que todo lo que el agente lee es hostil y diseñar el sistema para que eso no importe.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

Fase 3 · Demostrar lo que pasó
07

Guarda cada tool call y sus efectos en una traza con verificación de integridad.

Por qué importa

Los transcripts registran lo que el modelo dijo. Los incidentes se investigan sobre lo que hizo: qué archivos tocó, qué requests envió, qué registros cambió. Si el agente puede modificar sus propios logs, esa evidencia deja de valer justo cuando más se la necesita.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

08

Firma lo que está permitido, de modo que un revisor pueda probar qué reglas estaban vigentes.

Por qué importa

Cuando un incidente, una auditoría o el security review de un cliente pregunta qué tenía permitido hacer un agente en una fecha concreta, la respuesta tiene que poder demostrarse. Una política que vive en una wiki o en la cabeza de alguien no se puede probar y se aleja en silencio de lo que todos creen que dice.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

09

Cruza la política que asignaste con la que cada entorno aplicó realmente.

Por qué importa

Lo asignado y lo aplicado divergen solos. Un entorno se restaura desde una imagen vieja, un hotfix desactiva el gateway, un deploy sale sin el paso de política. El drift se detecta con una comparación programada, no con buenas intenciones.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

Fase 4 · Correr el loop
10

Un entorno alineado no genera ruido; a revisión llega únicamente lo que diverge de la política.

Por qué importa

Si todo requiere aprobación, en una semana se aprueba sin leer. Si todo genera alertas, el canal termina silenciado junto con la única alerta que importaba. La revisión escala solo cuando lo alineado permanece en silencio y la atención humana se reserva para las desviaciones.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

11

Documenta cómo revocar el acceso de un agente en minutos y prueba que funciona.

Por qué importa

El peor momento para descubrir que la revocación no funciona es durante un incidente. Los tokens sobreviven en caches y las sesiones sobreviven a las credenciales rotadas. Un agente actúa en segundos: revocarlo tiene que tomar minutos y estar probado antes de que haga falta.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

12

Una herramienta nueva, un token nuevo o un cambio de modelo: corre el checklist otra vez antes del deploy.

Por qué importa

La auditoría inicial describe un sistema que dejó de existir tres sprints después. O el checklist corre en cada cambio de capacidades o se convierte en un documento sobre el pasado.

El paso a paso para correrlo, los criterios de PASS y los red flags están en el PDF.

Llévate la versión para tu auditor

La versión en PDF suma lo que un revisor va a pedir:

  • Cómo correr cada chequeo, paso a paso
  • Los criterios exactos de PASS y los red flags
  • Los incidentes documentados detrás de cada control
  • El mapeo al OWASP Agentic Top 10 2026 y a la guía MCP de la NSA
Listo, el PDF va en camino a tu correo. Si no llega en unos minutos, revisa spam.

Te lo enviamos por correo, 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. Si quieres automatizar partes, esto es lo que construimos.

Open source · Gratis

Aguara

Nuestro scanner open source corre gratis y en local: cubre los scans de los chequeos 05 y 06 sobre tus servers MCP y skills. También ayuda con el inventario del chequeo 01.

Correr Aguara
Servicio · Whitebox

Oktsec Assessment

Corre los doce chequeos sobre toda tu infraestructura de agentes, whitebox, con un reporte accionable por hallazgo.

Pedir un assessment
Plataforma · Runtime

Oktsec Control

La Fase 2 y la Fase 3 en runtime: el gate determinista del chequeo 04 más el loop de política firmada, registro de acciones y comparación de lo esperado con lo reportado de los chequeos 07 a 10, funcionando de forma continua.

Ver Control en acción

¿Tu empresa está alcanzada por 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 estaba vigente, qué hizo el agente y la prueba de que ambas cosas coinciden. Cómo preparar la evidencia

Preguntas frecuentes

¿Cuánto tiempo lleva correr el checklist de seguridad de agentes de IA?
Para una sola persona técnica, un primer pase completo lleva uno o dos días sobre el stack de una startup en etapa seed. No requiere equipo de seguridad ni herramientas pagas. La Fase 1 sola lleva unas horas y casi siempre revela al menos un entorno o una credencial que nadie conocía.
¿Necesito un producto para usarlo?
No. El checklist es neutral de vendors y está completo en esta página. Si quieres automatizar los scans, Aguara es open source y gratis. El resto se corre con acceso a tu propia infraestructura.
¿A qué frameworks está mapeado?
Al OWASP Top 10 for Agentic Applications 2026, al OWASP Top 10 for LLM Applications 2025 y a la guía de seguridad para MCP publicada por la NSA en mayo de 2026. El mapeo chequeo por chequeo viene en el PDF.
¿Cada cuánto hay que correrlo?
Completo, al menos una vez por trimestre. De forma incremental, en cada cambio de capacidades: una herramienta nueva, una credencial nueva o con otro alcance, un server MCP nuevo o modificado, un cambio de modelo o de proveedor. Un server MCP nuevo toca los chequeos 01, 02, 04, 05 y 06, no los doce.