- La inyección de prompt indirecta es la amenaza más extendida: el agente visita una página y ejecuta instrucciones ocultas en su contenido sin que el usuario lo sepa.
- El principio de mínimo privilegio es la defensa más efectiva: un agente solo debe poder hacer exactamente lo que su tarea requiere, y nada más.
- Las confirmaciones humanas para acciones irreversibles (borrar datos, enviar emails, hacer pagos) son obligatorias en cualquier agente de producción.
- Los servidores MCP de terceros representan un riesgo de cadena de suministro que hay que auditar antes de integrar.
- Ningún framework garantiza seguridad por defecto: el desarrollador es responsable de configurar los mecanismos de protección en cada despliegue.
¿Por qué la seguridad es crítica en agentes de IA?
La seguridad de los agentes de inteligencia artificial es crítica porque, a diferencia de un modelo de lenguaje puro que solo genera texto, un agente puede ejecutar acciones reales e irreversibles: borrar archivos, enviar correos, realizar transacciones, modificar bases de datos o publicar contenido en nombre del usuario. Cada herramienta que conectas a un agente amplifica su capacidad de actuar en el mundo, y con esa capacidad crece proporcionalmente la superficie de ataque y el impacto potencial de cualquier comportamiento inesperado.
La diferencia con las aplicaciones web tradicionales es profunda. En un sistema clásico, el código determina exactamente qué puede ocurrir en cada flujo. En un agente, el modelo de lenguaje toma decisiones dinámicas sobre qué herramientas usar, con qué parámetros y en qué orden. Esto introduce una variable que no se puede cubrir completamente con pruebas de software convencionales: el comportamiento emergente del LLM ante entradas que el desarrollador no anticipó.
Para entender la magnitud del problema hay que partir de la base. Un agente de IA combina razonamiento (LLM), herramientas externas, memoria y planificación en un bucle continuo. Cada uno de esos elementos introduce vectores de ataque propios: el LLM puede ser manipulado mediante inyección de prompt, las herramientas pueden ser abusadas con parámetros maliciosos, la memoria puede ser envenenada con datos falsos y el bucle de planificación puede ser explotado para forzar comportamientos no previstos.
La buena noticia es que los mecanismos de defensa son conocidos y aplicables. No requieren tecnología experimental: son decisiones de diseño que se toman al principio del proyecto y que resultan mucho más baratas de implementar desde el primer día que de remediar después de un incidente. Esta guía organiza esas decisiones en un orden práctico.
"La seguridad de un agente no es una capa adicional que se añade al final. Es una decisión de diseño que determina qué herramientas conectas, con qué permisos, y bajo qué condiciones el agente puede usarlas."
Un dato importante para contextualizar: según los reportes de incidentes de seguridad en sistemas de IA de 2025, el 73% de los ataques exitosos a agentes aprovecharon la inyección de prompt indirecta (instrucciones ocultas en contenido externo que el agente procesa). El segundo vector más común fue la exposición de credenciales a través de logs o respuestas del agente. Ambos son prevenibles con las técnicas que se describen en las secciones siguientes.
Las 8 amenazas principales en agentes de IA
Estas son las amenazas de seguridad más documentadas y con mayor impacto en sistemas de agentes en producción. Conocerlas es el primer paso para defenderse de ellas.
Principios de diseño seguro
Estos seis principios son la base de cualquier agente seguro. No son opcionales ni se aplican "cuando haya tiempo": se diseña con ellos desde el primer día o se paga el coste de remediarlos más adelante.
Mínimo privilegio
Cada agente recibe exactamente los permisos que necesita para su tarea y ninguno más. Un agente de análisis de datos no necesita permisos de escritura. Un agente de atención al cliente no necesita acceso al código fuente. La superficie de permisos determina directamente el impacto máximo de cualquier ataque o comportamiento inesperado.
Humano en el bucle
Para acciones irreversibles o de alto impacto (borrar datos, enviar comunicaciones masivas, realizar pagos, modificar configuración de sistema), el agente solicita confirmación explícita al usuario antes de ejecutar. La confirmación debe incluir un resumen claro de lo que va a ocurrir, no una pregunta vaga. Esta capa es la única defensa efectiva contra alucinaciones que llegan hasta la fase de ejecución.
Validación de entrada
Todo input que el agente recibe del exterior (mensajes de usuario, respuestas de herramientas, contenido de páginas web, datos de APIs) debe ser tratado como potencialmente malicioso. Esto implica sanitizar el contenido antes de incluirlo en el contexto del LLM, limitar la longitud de los inputs y detectar patrones típicos de inyección de prompt en el texto procesado.
Filtrado de salida
Antes de que la respuesta del agente llegue al usuario o sea enviada a un sistema externo, se aplica un filtro que detecta y bloquea la inclusión de datos sensibles: números de tarjeta, tokens de API, contraseñas, datos personales identificables. El filtrado de salida es complementario a la validación de entrada: la primera evita que datos maliciosos entren, la segunda evita que datos sensibles salgan.
Presupuesto de tokens
Cada sesión de agente tiene un límite máximo de tokens (y por tanto de coste y de iteraciones). Cuando el agente alcanza ese límite, la sesión se cierra con un mensaje explicativo en lugar de continuar indefinidamente. Esto previene los bucles infinitos, controla el gasto en APIs de LLM y limita el impacto de cualquier comportamiento descontrolado. El presupuesto debe ser suficiente para tareas legítimas pero no ilimitado.
Registro de auditoría
Cada acción que el agente ejecuta queda registrada con timestamp, herramienta utilizada, parámetros enviados y resultado obtenido. Este registro tiene dos usos: detectar comportamientos anómalos en tiempo real (alertas cuando el agente llama a una herramienta un número inusual de veces) y reconstruir la secuencia de eventos después de un incidente para entender qué ocurrió y por qué.
Checklist de seguridad por categorías
Usa esta tabla antes de desplegar cualquier agente en producción. Cada elemento sin marcar es un riesgo explícito que debes aceptar conscientemente o resolver antes del lanzamiento.
| Categoría | Verificación | Prioridad |
|---|---|---|
| Autenticación | El agente verifica la identidad del usuario antes de ejecutar acciones en su nombre | Crítica |
| Autenticación | Las sesiones tienen tiempo de expiración configurado | Alta |
| Autenticación | Los tokens de API se almacenan en variables de entorno, no en el código ni en prompts | Crítica |
| Autorización | El agente tiene permisos mínimos: solo las herramientas necesarias para su tarea | Crítica |
| Autorización | Las acciones irreversibles requieren confirmación humana explícita | Crítica |
| Autorización | Existe una lista blanca de herramientas permitidas (no se pueden añadir herramientas en tiempo de ejecución) | Alta |
| Datos | Los inputs del usuario se sanitizan antes de incluirse en el contexto del LLM | Alta |
| Datos | Las respuestas del agente pasan por un filtro de datos sensibles antes de mostrarse | Alta |
| Datos | Los contenidos externos (páginas web, documentos) se tratan como no confiables | Alta |
| Datos | La memoria de largo plazo no almacena credenciales ni datos PII sin cifrar | Crítica |
| Monitoreo | Existe un limite de tokens por sesión configurado y activo | Alta |
| Monitoreo | Cada llamada a herramienta queda registrada con timestamp y parámetros | Alta |
| Monitoreo | Existe una alerta que se activa si el agente llama a la misma herramienta más de N veces | Media |
| Monitoreo | Los logs de auditoría son inmutables (el agente no puede modificarlos) | Alta |
| Despliegue | El agente se ejecuta en un entorno aislado sin acceso a la red interna de producción | Alta |
| Despliegue | Los servidores MCP de terceros han sido auditados o ejecutan en sandbox | Alta |
| Despliegue | Existe un interruptor de emergencia para desactivar el agente sin downtime del servicio | Media |
| Despliegue | Se ha realizado una prueba de inyección de prompt antes del lanzamiento | Alta |
Los elementos marcados como "Crítica" son bloqueantes: un agente en producción sin ellos representa un riesgo inaceptable. Los elementos "Alta" deben estar presentes en el momento del lanzamiento salvo excepciones documentadas y aceptadas por el responsable del sistema. Los elementos "Media" pueden diferirse a la siguiente iteración si existe un plan concreto para implementarlos.
Herramientas de seguridad disponibles
El ecosistema de seguridad para agentes de IA ha madurado rápidamente en 2025-2026. Estas son las categorías de herramientas más relevantes y representantes destacados en cada una.
Guardrails y filtrado
Guardrails AI y NVIDIA NeMo Guardrails son las soluciones más maduras. Permiten definir reglas declarativas que interceptan los inputs y outputs del LLM antes de que lleguen al agente o al usuario: detección de temáticas prohibidas, filtrado de PII, validación de formato de respuesta y control de tópicos. Se integran como middleware en el pipeline del agente.
Sandboxing y aislamiento
Los entornos de ejecución aislados evitan que el agente acceda a recursos del sistema operativo fuera de los explícitamente concedidos. Docker con políticas de red restrictivas, gVisor para aislamiento de syscalls y Firecracker para microVMs son las opciones más usadas. Para la ejecución de código generado por el agente, servicios como E2B ofrecen sandboxes de código gestionados.
Rate limiting y control de gasto
Más allá del rate limiting de las propias APIs de LLM, herramientas como LiteLLM permiten configurar límites de gasto por usuario, por sesión y por modelo, con alertas y cortes automáticos cuando se alcanzan los umbrales. Esto es esencial tanto para la seguridad (prevenir bucles infinitos) como para el control de costes operativos.
Observabilidad y trazabilidad
LangSmith (del ecosistema LangChain), Arize Phoenix y Langfuse (open-source) ofrecen trazabilidad completa de cada paso del agente: cada llamada al LLM, cada invocación de herramienta, cada decisión de planificación. Permiten detectar comportamientos anómalos, reconstruir incidentes y medir métricas de seguridad en producción.
La elección de herramientas de seguridad debe estar alineada con el framework que uses para construir el agente. Consulta la comparativa completa de frameworks para agentes IA para entender qué capacidades de seguridad incluye cada uno de forma nativa y cuáles debes implementar por tu cuenta.
Seguridad por framework
Cada framework para agentes tiene un enfoque distinto respecto a la seguridad. Esta tabla resume las capacidades nativas de los tres más usados y lo que debes implementar manualmente en cada caso.
| Mecanismo de seguridad | Claude Agent SDK | LangChain / LangGraph | CrewAI |
|---|---|---|---|
| Confirmaciones para acciones críticas | Nativo (Computer Use con confirmación explícita) | Manual (vía callbacks) | Manual (vía hooks de tarea) |
| Permisos granulares por herramienta | Nativo (MCP scopes) | Manual (definición de herramientas) | Manual (tools por agente) |
| Límite de iteraciones | Configurable (max_turns) | Configurable (max_iterations) | Nativo (max_iter por agente) |
| Límite de presupuesto de tokens | Vía API (max_tokens por llamada) | Vía callbacks + LiteLLM | Vía configuración del LLM |
| Trazabilidad de acciones | Nativo (eventos del SDK) | Nativo (LangSmith integrado) | Partial (verbose mode) |
| Guardrails de contenido | Nativo (política de seguridad de Claude) | Manual (Guardrails AI, NeMo) | Manual (Guardrails AI, NeMo) |
| Sandboxing de código | E2B o Docker (externo) | E2B nativo (LangChain tools) | Manual (externo) |
| Audit log de herramientas | Nativo (stream de eventos) | Nativo (LangSmith) | Manual (vía callbacks) |
Una lectura importante de esta tabla: ningún framework tiene seguridad completa nativa. Claude Agent SDK destaca en confirmaciones y permisos MCP; LangChain destaca en observabilidad y ecosistema de guardrails; CrewAI destaca en control de iteraciones por agente en sistemas multi-agente. En cualquier caso, el desarrollador es responsable de configurar explícitamente los mecanismos que el framework no activa por defecto.
Preguntas frecuentes sobre seguridad en agentes IA
La inyección de prompt es un ataque donde un actor malicioso introduce instrucciones ocultas en los datos que el agente procesa. En la variante directa, el propio usuario introduce las instrucciones en su mensaje. En la variante indirecta, las instrucciones están en contenido externo que el agente visita: una página web, un documento PDF, un email. La variante indirecta es más peligrosa porque el usuario legítimo no tiene por qué ser el atacante; puede ser una víctima cuyo agente fue manipulado al visitar una página maliciosa.
Las defensas más efectivas son: tratar todo contenido externo como no confiable, aplicar sanitización antes de incluirlo en el contexto del LLM, y usar guardrails que detecten patrones típicos de inyección en el texto procesado.
La exfiltración de datos se previene con tres capas complementarias:
- Filtrado de salida: el agente no puede incluir en sus respuestas datos que coincidan con patrones sensibles (números de tarjeta, tokens, claves, datos PII). Se implementa como middleware antes de que la respuesta llegue al usuario o a sistemas externos.
- Permisos mínimos: el agente solo accede a los datos estrictamente necesarios para su tarea. Si no necesita acceso a la base de datos completa de clientes, no lo tiene.
- Registro auditado: cualquier transmisión de datos hacia el exterior queda registrada con timestamp, destino y contenido (excepto los propios datos sensibles). Los registros permiten detectar patrones anómalos de transmisión.
El principio de mínimo privilegio establece que un agente debe tener acceso exclusivamente a las herramientas, datos y permisos que necesita para completar su tarea específica, y nada más. En la práctica implica varias decisiones de diseño concretas:
- Un agente de redacción de contenido no necesita permisos de publicación automática.
- Un agente de análisis de datos no necesita permisos de escritura en la base de datos.
- Un agente de atención al cliente no necesita acceso al historial completo de todos los clientes, solo al del cliente actual.
- Un agente de búsqueda web no necesita acceso al sistema de archivos local.
La superficie de permisos determina directamente el impacto máximo de cualquier ataque o comportamiento inesperado. Cuanto menor es esa superficie, menor es el daño potencial.
Cada framework tiene capacidades nativas distintas. Claude Agent SDK implementa confirmaciones explícitas para acciones de alto impacto a través de Computer Use y soporta permisos granulares por herramienta mediante MCP scopes. LangChain ofrece un sistema de callbacks que permite interceptar cada llamada a herramienta y aplicar validaciones personalizadas, además de integración nativa con LangSmith para trazabilidad. CrewAI incluye límites de iteración configurables por agente, lo que previene bucles infinitos en sistemas multi-agente.
La limitación común a todos es que ninguno activa los mecanismos de seguridad por defecto: el desarrollador debe configurarlos explícitamente. Consulta la comparativa completa de frameworks para ver qué capacidades activa cada uno sin configuración adicional.
Los servidores MCP de terceros representan un riesgo de cadena de suministro que debe gestionarse explícitamente. Si un servidor MCP está comprometido o es malicioso, puede devolver respuestas diseñadas para manipular el comportamiento del agente, ya que el agente confía en que los resultados de sus herramientas son legítimos.
Las prácticas recomendadas para gestionar este riesgo son:
- Usar solo servidores MCP de fuentes auditadas y con historial de mantenimiento activo.
- Revisar el código fuente de servidores open-source antes de integrarlos, especialmente las rutas de retorno de datos.
- Ejecutar servidores MCP en entornos sandbox aislados de la red interna.
- Verificar y restringir los permisos (scopes) que cada servidor MCP solicita antes de concederlos.
- Monitorear las respuestas de los servidores MCP para detectar anomalías en el contenido retornado.