Los agentes de IA dejaron de ser demos de laboratorio. Hoy ejecutan automatizaciones, acceden a APIs corporativas, leen bases de datos y disparan despliegues. Eso convierte cada agente en una superficie de ataque que el perímetro tradicional no cubre. Aquí está la checklist que uso para llevarlos a producción sin regalarle la llave maestra al modelo.
El problema: el agente hereda todos los permisos
La arquitectura típica de un agente encadena un LLM, un framework de orquestación, una colección de tools (vía MCP u otros transportes) y los sistemas de destino. El riesgo crece porque la autoridad viaja por toda la cadena y el modelo decide cuándo invocar cada tool basado en contexto, no en privilegios reales.
Agente LLM → Orquestador → Tools (MCP) → API, DB, CI/CDSi una tool interna tiene permiso amplio y el contexto del modelo fue envenenado (prompt injection), el agente puede ejecutar una acción legítima con datos maliciosos. El resultado: exfiltración de contexto sensible o activación de herramientas no deseadas.
Checklist de endurecimiento
- Menos privilegio por tool: cada herramienta expone la mínima superficie de acciones posible, con scope por recurso y por usuario.
- Autenticación explícita: usa OAuth 2.1 para servidores MCP remotos y tokens de corta duración; jamás credenciales de larga vida embebidas.
- Validación de tareas propagadas: un servidor MCP debe validar el origen, alcance e intención de cada tarea entrante antes de reenviarla a otro componente.
- Sandboxing: cada servidor corre aislado en su propio contenedor, con egress allowlist y validación de esquemas de URL para frenar SSRF.
- Fail-closed: si un servidor MCP cae, el comportamiento predefinido debe ser seguro y probado antes de producción.
Modelando confianza: zero-trust para agentes
Un agente no es un usuario de confianza implícita. Trátalo como un proceso más de tu malla de servicios: identidad propia, política mínima, registros auditables y límites de intentos. Cuando dos agentes se hablan, cada mensaje debe llevar contexto verificable de quién lo emitió y qué autoridad tiene.
// Ejemplo conceptual de capa de autorización por tool
{
"tool": "deploy_production",
"allowed_identities": ["orchestrator-cd"],
"max_rate_per_hour": 4,
"required_approval": true,
"deny_by_default": true
}Observabilidad del camino feliz y del hostil
No basta con logs de aplicación. Para agentes necesitas un registro de la cadena completa: qué prompt entró, qué tools se invocaron, con qué parámetros y qué impactó. Eso te permite detectar anomalías como un agente que llama a una tool de producción fuera de horario o con un payload inusual.
- Traza la propagación de tareas entre servidores MCP.
- Alerta sobre intentos de acceso denegado, no solo sobre fallos.
- Retiene contexto de auditoría suficiente para reconstruir un incidente.
Conclusión
La seguridad de agentes no es un plugin que se instala; es una práctica por defecto. Autenticación explícita, menor privilegio, sandboxing y validación de tareas convierten un agente de un riesgo en una herramienta controlada. El modelo puede ser brillante; tú decides cuánto puede tocar.