[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Los mejores patrones de seguridad para agentes AI en 2026
La seguridad de los agentes se refiere al control de sus acciones. Mientras que un chatbot puede devolver una respuesta incorrecta, un agente es capaz de utilizar credenciales reales, llamar a herramientas y modificar datos en entornos de producción.
La regla por defecto es sencilla: no se deben otorgar a un agente capacidades que no necesite. Se debe comenzar con herramientas específicas, comprobaciones de políticas antes de cada tool call, entornos sandboxes aislados, credenciales restringidas, mecanismos de aprobación humana y registros de auditoría. También se pueden añadir medidas de control y filtros de salida, pero no deben considerarse como la principal barrera de seguridad.
Clasificación de patrones
| Patrón | Prioridad | Protege contra | Nota de implementación |
|---|---|---|---|
| Herramientas de mínimo privilegio | P0 | Agencia excesiva | No expongas las herramientas que el agente nunca debe utilizar. |
| Verificaciones previas a la política de herramientas | P0 | Acciones peligrosas | Verifique la acción concreta justo antes de su ejecución. |
| Sandboxes | P0 | Daños en archivos, shells, navegadores y redes | Aíslar el código y los contenidos no confiables. |
| Aprobaciones humanas | P0 | Acciones irreversibles o reguladas | Escrituras de puerta de enlace, despliegues, pagos, envíos externos y cambios con privilegios. |
| Credenciales con ámbito limitado | P0 | Sobrepaso de credenciales y fallos por delegado confundido | Utilice alcances restringidos, uno por servidor y otro por herramienta. |
| Isolación del servidor MCP | P1 | Envenenamiento de herramientas, sombreado de herramientas, ataques entre servidores | No mezcle servidores no confiables con herramientas potentes en el mismo entorno sin realizar una revisión previa. |
| Registros de auditoría | P1 | Historial de incidentes desconocido | Persistir la solicitud del usuario, tool call, los argumentos, el resultado, la decisión de política y el responsable de aprobación. |
| Límites de seguridad | P1 | Texto de entrada y salida no seguro | Útil, pero insuficiente para otorgar autoridad al herramienta. |
| Evaluaciones de equipo rojo | P1 | Rutas de ataque conocidas | Probar prompt injection, envenenamiento de herramientas, extracción de datos y elusión de permisos. |
Qué implementar primero
Primero, elimine las capacidades no necesarias. Si el agente no requiere escribir en GitHub, no le otorgue un token de escritura. Si solo necesita conocer la disponibilidad del calendario, no le conceda acceso completo al buzón de correo. Una permisividad limitada es más segura que un prompt estricto.
A continuación, se debe verificar la política antes de ejecutar cada tool call. Es necesario examinar el nombre de la herramienta, los argumentos, el recurso destino, el usuario, el entorno y los efectos secundarios. Una solicitud que parezca inofensiva puede seguir generando comandos de shell peligrosos.
Incorporar sandboxes para la ejecución de código, la automatización de navegadores, el acceso a archivos y el procesamiento de documentos no fiables. Un sandbox no hace que la acción sea correcta, pero sí reduce los daños causados por un tool result comprometido o por un modelo confundido.
Se debe solicitar la aprobación humana para las acciones irreversibles. No se debe aprobar cada paso por separado. En su lugar, se deben aprobar los límites específicos: despliegues en producción, eliminación de datos, envíos de correos electrónicos, movimientos de dinero, cambios de permisos y decisiones sujetas a regulaciones.
Riesgos específicos de MCP
MCP resulta útil ya que permite estandarizar el acceso a las herramientas. Sin embargo, conlleva riesgos, puesto que las descripciones de las herramientas, sus esquemas, las identidades del servidor, los alcances OAuth y las salidas generadas por ellas pasan a formar parte del contexto de toma de decisiones del modelo.
Para MCP, mantendría estas reglas en la revisión de código:
- Revisar las descripciones y esquemas de las herramientas antes de aprobarlas.
- Preferir credenciales específicas por servidor.
- Aislar los servidores no confiables MCP del acceso a herramientas sensibles.
- Vigilar cualquier cambio en la definición de las herramientas tras su instalación.
- Tratar la salida de las herramientas como entrada no confiable.
- Registrar cada servidor, herramienta, argumento y resultado.
Las restricciones predefinidas no son suficientes
Lectura adicional
- AI Seguridad de agentes en 2026 Se trata de la guía completa sobre la arquitectura. AI Agente Tool Use en 2026 Explica MCP, las herramientas, la interfaz de línea de comandos, las competencias necesarias y el proceso de ejecución de código.
- AI Agente Runtime en 2026 Abarca los límites de runtime para agentes que operan de forma continua.