Checklist de Seguridad para AI Agents: Qué Revisar Antes de Delegar Trabajo
Checklist práctico para revisar herramientas, prompts, límites de datos, permisos, logs y aprobaciones antes de que un AI agent actúe.
Actualizado el
Los AI agents están pasando del chat al trabajo real. Pueden leer archivos, navegar páginas, llamar herramientas, abrir pull requests, actualizar registros y tomar decisiones en varios pasos. La pregunta de seguridad cambia: no es solo “¿el modelo respondió mal?”, sino “¿qué podría hacer el sistema si entendiera mal la tarea o confiara en el input equivocado?”
Un checklist de seguridad para AI agents es una revisión práctica antes de delegar trabajo real. Revisa prompts, herramientas, fuentes de datos, permisos, memoria, logs y puntos de aprobación humana.
Qué cambió
La primera ola de riesgo en productos de IA se centraba en texto generado. El modelo podía alucinar, filtrar contexto o seguir instrucciones maliciosas. Los agents amplían la superficie porque combinan razonamiento del modelo con sistemas externos.
Un workflow moderno puede incluir archivos locales, repositorios, tickets, bases de datos, herramientas vía API o MCP, acciones en navegador, memoria, credenciales y planificación de varios pasos.
Por eso no basta con escribir mejores prompts. Un agent confiable necesita límites sobre qué datos son confiables, qué herramientas puede llamar, qué acciones requieren confirmación y cómo auditar lo que ocurrió.
Tres capas de riesgo
| Capa | Qué puede salir mal | Pregunta de revisión |
|---|---|---|
| Instructions | Una página, email, ticket o documento intenta sobrescribir reglas | ¿El agent distingue instrucciones del usuario de contenido no confiable? |
| Tools | Una herramienta tiene demasiados permisos o metadata envenenada | ¿El agent solo ve las herramientas necesarias? |
| Data | Datos no confiables se tratan como metadata, origen de archivo o contexto de ejecución | ¿El sistema separa datos confiables de datos controlados por terceros? |
El problema nuevo es que el agent no solo lee texto malicioso. Puede usarlo para elegir herramientas, hacer clic, escribir código o modificar registros.
Prompt injection, tool poisoning y data injection
| Riesgo | Significado | Ejemplo |
|---|---|---|
| Prompt injection | Contenido no confiable intenta cambiar instrucciones | Una web pide revelar instrucciones ocultas |
| Tool poisoning | Metadata o descripción de herramienta afecta la elección del modelo | Una herramienta falsa afirma que debe procesar todos los datos financieros |
| Agent data injection | Datos maliciosos parecen contexto confiable | Un repositorio o tool response manipula rutas, origen o ejecución |
El contenido peligroso puede parecer un link, etiqueta, nombre de herramienta, origen de archivo, patch o respuesta estructurada.
Checklist antes de delegar trabajo
| Revisión | Buen valor por defecto | Señal de riesgo |
|---|---|---|
| Alcance | Una tarea clara y una condición de éxito | ”Maneja lo que aparezca” |
| Límite de datos | Entradas confiables separadas de contenido externo | Web, emails, tickets y tool outputs mezclados |
| Inventario | Cada herramienta tiene dueño, propósito y permisos | Toolbox grande y confusa |
| Permisos | Solo lectura por defecto; escritura requiere aprobación | Puede editar, borrar, desplegar, pagar o enviar emails |
| Credenciales | Tokens con scope y rotación | Tokens amplios o reutilizados |
| Aprobación | Acciones externas o destructivas pausan para review | Acciones irreversibles en una sola ejecución |
| Logs | Prompts, llamadas, outputs, aprobaciones y acciones guardadas | Solo se ve la respuesta final |
| Tests | Casos normales, confusos y adversariales | Solo demo feliz |
Regla simple: si una acción es difícil de revertir, el agent no debe ejecutarla sin aprobación humana.
Revisión específica de MCP
Antes de usar un MCP server, pregunta:
- ¿Quién mantiene el servidor y se puede confiar en su implementación?
- ¿Qué datos y acciones expone?
- ¿Los nombres y descripciones de tools son claros?
- ¿Los scopes se pueden reducir por tarea o usuario?
- ¿La autorización usa consentimiento por cliente y redirect URI exacta?
- ¿Los tokens se emiten para el MCP server o se pasan ciegamente?
- ¿El cliente bloquea requests a endpoints internos o metadata?
- ¿Las llamadas quedan registradas con suficiente detalle?
La configuración más segura no es la que tiene más herramientas, sino la que muestra solo lo necesario.
Checklist para coding agents
| Antes de permitir | Revisar |
|---|---|
| Edición de archivos | Limitar directorio y revisar patches |
| Comandos | Separar read-only de install, delete, deploy o mutación |
| Dependencias | Revisar paquetes, registries, lockfile y postinstall |
| Secrets | Mantener tokens fuera de prompts, logs, archivos e historial shell |
| Pull requests | Exigir tests, diff review y provenance clara |
| Input externo | Tratar issues, README, comentarios y snippets como no confiables |
Un coding agent puede aumentar productividad, pero el camino de revisión debe seguir visible.
Qué puede hacer un equipo pequeño esta semana
- Elige un workflow repetible, como resumir tickets o redactar un PR.
- Ejecútalo primero con acceso read-only.
- Lista todas las herramientas que el agent puede llamar.
- Quita herramientas innecesarias.
- Añade aprobación para escritura, mensajes externos, compras, deploys y borrados.
- Guarda prompts, tool calls, outputs y acciones finales.
- Prueba un caso adversarial, como un ticket que pida ignorar reglas.
Si el agent no puede explicar qué datos confió, qué herramientas usó y qué hizo, el workflow no está listo para autonomía.
Registro de actualización
Jul 09 2026: Publicada la versión en español con checklist de seguridad, revisión MCP, riesgos de coding agents, FAQ y referencias.