Checklist de seguridad para AI Agent: permisos y sandboxes
Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
La seguridad de un agente consiste en controlar sus acciones. Un chatbot puede devolver una respuesta incorrecta. Un agente puede usar credenciales reales, llamar a una herramienta y modificar datos de producción.
La regla por defecto es sencilla: no concedas a un agente capacidades que no necesite. Empieza con herramientas limitadas, comprobaciones de políticas antes de cada tool call, sandboxes aislados, credenciales restringidas, pasos de aprobación humana y trazas de auditoría. Añade también guardrails y filtros de salida, pero no los consideres la principal frontera de seguridad.
Modelo de amenazas y fecha de revisión: 2026-08-10. Estas prioridades presuponen que un agente con acceso a herramientas puede procesar entradas controladas por un atacante y leer datos o provocar efectos externos. Los asistentes con menos capacidades necesitan menos controles; las acciones de mayor impacto requieren un aislamiento y una aprobación más estrictos.
Clasificación de patrones
| Patrón | Prioridad | Protección frente a | Nota de implementación |
|---|---|---|---|
| Herramientas con mínimo privilegio | P0 | Agencia excesiva | Sigue las recomendaciones de OWASP para MCP: no expongas herramientas que el agente no deba usar nunca. |
| Comprobaciones de políticas antes de la herramienta | P0 | Acciones peligrosas | Comprueba la acción concreta justo antes de ejecutarla. |
| Sandboxes | P0 | Daños en archivos, shell, navegador y red | Aísla el código y el contenido no fiable; deniega por defecto el tráfico de salida de red. |
| Aprobaciones humanas | P0 | Acciones irreversibles o reguladas | Exige una aprobación para escrituras, despliegues, pagos, envíos externos y cambios privilegiados. |
| Credenciales con alcance limitado | P0 | Exceso de privilegios de las credenciales y fallos de deputy confundido | Usa alcances limitados por servidor y por herramienta. |
| Aislamiento de servidores MCP | P1 | Tool poisoning, tool shadowing y ataques entre servidores | No mezcles servidores no fiables con herramientas potentes en un mismo contexto sin revisión. |
| Trazas de auditoría | P1 | Historial de incidentes desconocido | Conserva la petición del usuario, el tool call, los argumentos, el resultado, la decisión de la política y el aprobador. |
| Guardrails | P1 | Texto de entrada y salida no seguro | Son útiles, pero no bastan para controlar la autoridad de las herramientas. |
| Evaluaciones de red team | P1 | Vectores de ataque conocidos | Prueba prompt injection, tool poisoning, exfiltración de datos y bypasses de permisos. |
Qué implementar primero
Elimina primero las capacidades. Si el agente no necesita escribir en GitHub, no le des un token de escritura. Si solo necesita consultar la disponibilidad del calendario, no le concedas acceso completo al buzón. Un permiso limitado es más seguro que un prompt severo.
Después, comprueba la política antes de cada tool call. Inspecciona el nombre de la herramienta, los argumentos, el recurso objetivo, el usuario, el entorno y el efecto secundario. Una petición aparentemente inofensiva aún puede generar un comando de shell peligroso.
Añade sandboxes para la ejecución de código, la automatización del navegador, el acceso a archivos y el procesamiento de documentos no fiables. Un sandbox no hace que la acción sea correcta, pero reduce los daños de un resultado de herramienta comprometido o de un modelo confundido.
Controla también el flujo de datos, no solo la ejecución. Restringe los destinos de red salientes, elimina los secretos de los resultados de las herramientas, separa el contenido no fiable de las credenciales y registra los intentos de salida. Un sandbox del sistema de archivos que siga permitiendo un acceso arbitrario a la red deja abierta una vía directa de exfiltración.
Usa la aprobación humana para las acciones irreversibles. No apruebes cada paso. Aprueba los límites: despliegues en producción, eliminación de datos, envíos de correo electrónico, movimientos de dinero, cambios de permisos y decisiones reguladas.
Riesgos específicos de MCP
MCP es útil porque estandariza el acceso a herramientas. También es arriesgado porque las descripciones de las herramientas, los esquemas, las identidades de los servidores, los alcances de OAuth y los resultados de las herramientas pasan a formar parte del contexto de decisión del modelo.
Para MCP, mantendría estas reglas en la revisión de código:
- revisa las descripciones y los esquemas de las herramientas antes de aprobarlas
- prioriza credenciales limitadas por servidor
- aísla los servidores MCP no fiables de las herramientas sensibles
- vigila los cambios en las definiciones de las herramientas después de la instalación
- trata el resultado de una herramienta como una entrada no fiable
- registra cada servidor, herramienta, argumento y resultado
Los guardrails no bastan
Los guardrails pueden validar la entrada y la salida. No resuelven el mínimo privilegio, el alcance de las credenciales, el sandboxing, el tool poisoning ni la política de aprobación. Mantenlos, pero sitúalos después del diseño de capacidades y antes de la salida visible para el usuario.
Lecturas recomendadas
- Seguridad de AI Agent es la guía completa de arquitectura.
- Uso de herramientas por AI Agent explica MCP, las herramientas, la CLI, las skills y la ejecución de código.
- Runtime de AI Agent de larga duración trata los límites del runtime para agentes de larga duración.