La seguridad de la IA agéntica se reduce a una pregunta: si alguien engaña a tu agente de IA, ¿qué puede obligarle a hacer? Estos asistentes leen datos, usan herramientas y actúan por su cuenta. Por eso, un agente engañado puede llegar a todo lo que le hayas conectado, desde registros de clientes y bandejas de entrada hasta claves de acceso y otros agentes.
Si tu equipo ha conectado la IA a un CRM, una cuenta de correo o un repositorio de código, esa pregunta ya te afecta. Los principales expertos en seguridad de agentes de IA también dan por hecho que, tarde o temprano, cualquier agente será engañado. OWASP, la organización sin ánimo de lucro que publica las listas de riesgos que sigue la mayor parte del sector, pide a quienes construyen estos sistemas que planifiquen pensando en un modelo engañado. Las agencias gubernamentales de ciberseguridad de cinco países añaden una regla práctica: nunca des a los agentes un acceso amplio.
Trabajamos en este problema desde el lado del tester. Los ingenieros de QAwerk realizan pruebas de agentes de IA antes del lanzamiento, y nuestros Bug Crawls examinan productos de IA que ya están en manos de los usuarios. En ambos casos empezamos por donde empezaría un atacante, con un mapa de cada sistema, herramienta y cuenta en juego. Este artículo comparte ese enfoque en lenguaje sencillo, para que puedas valorar el riesgo de tu propio producto antes del lanzamiento.
Qué significa realmente la seguridad de la IA agéntica
Un agente de IA es un programa basado en un modelo de lenguaje de gran tamaño (LLM), el tipo de IA que hay detrás de ChatGPT. A diferencia de un chatbot, que solo responde preguntas, un agente planifica sus propios pasos y los ejecuta. Por ejemplo, un agente de soporte puede buscar a un cliente, redactar una respuesta y enviar el correo sin que nadie pulse un botón.
La seguridad de la IA agéntica mantiene esas acciones bajo control gestionando cuatro cosas:
- Datos: lo que el agente puede leer
- Herramientas: las acciones que puede realizar
- Claves de acceso: las cuentas en las que puede iniciar sesión
- Otros agentes: a quién puede dar órdenes
Por qué la inyección de prompts es la amenaza principal para los agentes de IA
El punto débil de todo agente de IA es el propio modelo de lenguaje. Un LLM lee tus instrucciones y sus datos de trabajo como un único flujo de texto, así que el modelo no puede distinguir de forma fiable una petición real de una orden escondida en un correo o en un ticket de soporte. La inyección de prompts explota esa brecha: un atacante cuela nuevas instrucciones en el contenido que lee el agente. Nuestros testers han visto lo poco que hace falta para atacar productos reales. Durante Bug Crawls de asistentes de IA en producción, una sola línea escrita apartó a un asistente de su tarea, y una petición reformulada consiguió que otro recitara sus instrucciones confidenciales. Los detalles completos de esos ejemplos de inyección de prompts están en otro artículo.
Una inyección de prompts en un agente de IA hace más daño que en un chatbot, porque el agente actúa según las instrucciones maliciosas. La variante más difícil de detectar es la inyección indirecta de prompts. En este caso, las instrucciones hostiles se esconden en un documento, una página web o un correo que el agente abre durante una tarea, de modo que el atacante nunca necesita contacto directo.
Nadie ha encontrado una forma fiable de impedir que un modelo confunda instrucciones y datos, y la inyección de prompts ocupa el primer puesto del OWASP Top 10 for LLM Applications 2026, una clasificación de los mayores riesgos de las aplicaciones de IA. Los autores de la lista piden a los equipos que diseñen cada sistema “partiendo del supuesto explícito de que el límite de instrucciones del modelo acabará siendo superado”. Dicho de forma sencilla, planifica para el día en que tu agente obedezca a la persona equivocada. OWASP también subió la agencia excesiva, es decir, más poder del que necesita el trabajo de un agente, al tercer puesto y calificó ese ascenso como “el movimiento con más consecuencias de la lista”.
Riesgos de seguridad de la IA agéntica que aparecen en producción
Muchos riesgos de seguridad de la IA agéntica siguen un mismo patrón. Un atacante influye en lo que lee el agente, y después es el propio acceso del agente el que causa el daño. La tabla siguiente relaciona las principales amenazas de la IA agéntica con cómo se manifiesta cada una en un producto real y qué comprueba un tester.
Inyección de prompts
Un mensaje de un cliente le dice al agente que ignore sus reglas, y el agente obedece
Permisos excesivos
Un agente de soporte comparte un inicio de sesión de administrador, así que puede editar registros de facturación y borrar cuentas
Si cada acción que puede realizar el agente es una que su trabajo realmente necesita
Uso inseguro de herramientas
El agente pasa texto escrito por el atacante a una herramienta de búsqueda o de código, y la herramienta ejecuta ese texto
Si cada herramienta rechaza entradas dañinas, aunque vengan del propio agente
Credenciales robadas o compartidas
Varios agentes comparten una clave de acceso que nunca caduca, así que una sola filtración los expone a todos
Si las claves son únicas por agente, de alcance limitado y de corta duración
Fuga de datos
El agente lee registros privados, y esos registros acaban en una respuesta o en una solicitud saliente
Si los datos de un usuario o sistema pueden llegar a otro usuario o a una dirección externa
Confianza ciega entre agentes
Un agente acepta la petición de otro agente sin comprobarla, así que un solo compromiso se propaga
Si cada agente revisa las peticiones de otros agentes con el mismo rigor que las de los usuarios
Falta de puntos de aprobación
El agente borra datos o mueve dinero, y ninguna persona revisa la acción antes
Si las acciones de alto impacto se detienen hasta una aprobación que el agente no puede saltarse
Lo que revelaron las investigaciones de 2026 sobre los ataques a agentes
Dos casos recientes de vulnerabilidades en agentes de IA muestran lo corto que puede ser el camino de las palabras al daño. El primero vino de Microsoft, cuyo equipo de seguridad encontró un fallo, ya corregido, en Semantic Kernel, el kit de herramientas de código abierto de la compañía para crear agentes. Durante las pruebas, un solo prompt bastó para ejecutar un programa en el ordenador que alojaba al agente. El agente había pasado texto del chat directamente a una herramienta de búsqueda, y la herramienta ejecutó ese texto como código. La conclusión de Microsoft es tajante: “tu LLM no es una barrera de seguridad”.
El segundo vino de investigadores de seguridad de Zenity, que descubrieron que un solo prompt a un agente alojado en la nube de Amazon podía llegar a todos los demás agentes de la misma región. Ninguno de los dos hallazgos fue un ataque real, y ambos proveedores hicieron cambios una vez notificados los problemas. Aun así, el escaso número de incidentes reales registrados es engañoso. OWASP explica que los equipos se esfuerzan mucho por frenar estos ataques, por lo que pocos de los que tienen éxito llegan a registrarse, y el recuento oficial “subestima el riesgo”.
Tres configuraciones de agentes en las que crecen los riesgos de seguridad
Los riesgos de seguridad de la IA agéntica se agudizan allí donde un agente se conecta a algo nuevo, sobre todo en tres configuraciones habituales:
- Conexiones con herramientas: cada vez más agentes se conectan a aplicaciones externas mediante el Model Context Protocol (MCP), un estándar abierto que permite a un agente enchufarse a muchas herramientas y fuentes de datos. Cada nueva conexión aporta más datos que leer y más acciones que realizar, lo que convierte la seguridad de MCP en un tema propio.
- Agentes de programación: estas herramientas suelen trabajar con el acceso del propio desarrollador, que puede incluir código fuente, sistemas de compilación y claves de la nube. Para los equipos de ingeniería que los adoptan, la seguridad de los asistentes de programación con IA debe figurar en la lista de riesgos.
- Búsqueda en la base de conocimiento: muchos agentes responden a partir de los archivos de tu empresa mediante la generación aumentada por recuperación (RAG), un sistema que busca documentos relevantes antes de que la IA responda. Cualquiera que consiga colar instrucciones o datos falsos en ese material puede dirigir todas las respuestas que dependan de él, así que la seguridad de RAG necesita sus propias comprobaciones.
En las tres configuraciones, los atacantes suelen buscar el mismo resultado: la fuga de datos del LLM, en la que los datos privados que el agente puede leer acaban en una respuesta, un archivo de registro o una solicitud a un servidor externo.
Qué recomiendan las agencias gubernamentales de seguridad para los agentes de IA
En mayo de 2026, las agencias gubernamentales de ciberseguridad de Australia, Estados Unidos, Canadá, Nueva Zelanda y el Reino Unido publicaron recomendaciones conjuntas sobre los agentes de IA. Estos cinco países comparten inteligencia como la alianza Five Eyes, y entre las agencias autoras figura la Agencia de Seguridad Nacional (NSA) de Estados Unidos. La guía se titula Careful Adoption of Agentic AI Services y está dirigida a cualquier organización que cree o gestione agentes. Eso significa que las recomendaciones se aplican tanto a los equipos de producto como al personal de seguridad.
En esencia, la guía pide a los equipos que empiecen con tareas de bajo riesgo y que nunca den a los agentes un “acceso amplio o sin restricciones, especialmente a datos sensibles o sistemas críticos”. Una frase de la guía resume el porqué: “Los privilegios asignados a los agentes determinan directamente el nivel de riesgo que pueden introducir”. Dicho de forma sencilla, cuanto más se le permite hacer a un agente, más daño puede causar cuando algo sale mal.
La guía ilustra el peligro con un agente de compras que tiene acceso a los sistemas financieros, al correo y a los contratos. Un atacante entra en una pequeña herramienta que usa el agente y toma el control de todo lo que el agente puede alcanzar. A partir de ahí, el atacante modifica contratos y aprueba pagos, mientras los registros solo muestran a un asistente de confianza trabajando. Los expertos en seguridad llaman a esto un “confused deputy” (ayudante confundido): un asistente de confianza engañado para trabajar para alguien que no tiene derecho a darle órdenes.
Nueve salvaguardas para agentes con acceso real
En la práctica, las recomendaciones oficiales sobre seguridad de agentes de IA se resumen en estas salvaguardas:
- Acceso limitado a lo que necesita la tarea de cada agente, y nada más
- Credenciales just-in-time, es decir, claves de acceso creadas para una única acción sensible que caducan poco después
- Aprobación humana antes de las acciones de alto impacto, como borrar registros importantes, reiniciar sistemas o enviar datos fuera de la empresa
- Reglas de aprobación definidas por personas, para que el agente nunca decida por sí mismo cuándo pedir permiso
- Ningún agente puede cambiar sus propios permisos
- Un registro legible de cada herramienta que usa el agente
- Pruebas en un sandbox, una copia aislada de tus sistemas, antes del lanzamiento
- Red teaming de IA y pruebas de penetración periódicas, en las que especialistas hacen de atacante y analizan cómo se comporta el agente
- Comprobaciones periódicas de si el agente puede saltarse sus propios límites de seguridad, pasos de aprobación y filtros
Permisos de los agentes de IA: ¿cuánto acceso es demasiado?
Los permisos de un agente de IA son la lista de cosas que el agente puede leer, cambiar y enviar. Las agencias gubernamentales de ciberseguridad señalan dos errores cotidianos:
- Un asistente de calendario: necesita tu calendario para reservar tus reuniones, pero puede que vea todas las reuniones de la empresa.
- Un asistente de correo: necesita tu bandeja de entrada para redactar tus respuestas, pero puede que pueda escribir en la de cualquiera.
Si cualquiera de los dos agentes es engañado, el atacante hereda ese alcance adicional, desde reuniones privadas del consejo hasta correos enviados en nombre de un directivo.
Ejemplos reales de agentes que se exceden en su función
La investigación AgentCorruption de Zenity puso a prueba Amazon Bedrock AgentCore, la plataforma de Amazon para alojar agentes. Un solo prompt convenció a un agente para que entregara claves de acceso temporales. Según el informe de Dark Reading, los permisos predeterminados de la plataforma permitían después que esas claves llegaran a otros agentes, a conversaciones almacenadas y a contraseñas guardadas. Amazon niega que se tratara de una vulnerabilidad, aunque su propia recomendación es dar a cada agente solo los permisos que necesita. Zenity informa de que el acceso predeterminado se ha reducido desde entonces.
Los sitios web corrientes cometen el mismo error. En un caso muy difundido, un desarrollador puso a un agente de IA a trabajar en la web de reservas de un gimnasio, y el agente canceló la reserva de otro socio para hacer subir a su dueño en la lista de espera. Como explica nuestro artículo sobre el agente de IA que hackeó un gimnasio, el sitio nunca comprobó de quién era la reserva que se cancelaba.
Nuestros Bug Crawls sacan a la luz versiones más discretas del problema. En Fiscal.ai, una aplicación de análisis financiero con IA, un chat de Copilot que el usuario había borrado seguía activo y aceptando mensajes. Ese fallo aparece junto a varios fallos de fiabilidad en nuestro artículo sobre los riesgos ocultos de los agentes de IA.
Antes del lanzamiento, la lista de OWASP de 2026 sugiere una prueba rápida de los permisos de los agentes de IA. Hazte tres preguntas sobre tu agente:
- ¿Puede el agente leer datos privados?
- ¿Recibe contenido de desconocidos, como correos, páginas web o archivos subidos?
- ¿Puede enviar información fuera de la empresa?
Tres respuestas afirmativas significan que el agente reúne todo lo que necesita un atacante. Eliminar cualquiera de esas capacidades rompe la cadena.
Cómo proteger los agentes de IA
Proteger los agentes de IA implica dos tareas: limitar lo que puede hacer un agente engañado y vigilar todo lo que hace. Los permisos reducidos, la aprobación humana y las claves de acceso de corta duración cubren buena parte de la primera tarea. Tres buenas prácticas de seguridad para agentes de IA completan esas salvaguardas:
- Empieza con tareas de bajo riesgo. Delega trabajo en el que un error cueste poco, como redactar respuestas que luego envía una persona. Después amplía la función paso a paso a medida que crezca la confianza.
- Trata cada entrada de una herramienta como hostil. El equipo de seguridad de Microsoft aconseja que “cualquier parámetro de una herramienta en el que pueda influir el modelo debe tratarse como una entrada controlada por el atacante”. Por tanto, cada herramienta debe comprobar todo lo que recibe, como si lo hubiera escrito un desconocido.
- Revisa lo que se dicen los agentes entre sí. Una petición de otra IA merece el mismo escrutinio que la de un usuario. Las formas en que fallan los traspasos se tratan en otro artículo sobre pruebas de sistemas de IA multiagente.
Vigilar un agente empieza por un registro legible de cada acción que realiza. Ese registro permite a tu equipo detectar problemas pronto y reconstruir después lo ocurrido.
Cada control de seguridad de un agente de IA añade algo de fricción. En una herramienta interna de bajo impacto, aceptar más riesgo puede ser una decisión razonable, siempre que tu equipo la tome de forma consciente. En todos los demás casos, las agencias gubernamentales de ciberseguridad fijan un orden de prioridades claro: “resiliencia, reversibilidad y contención del riesgo por encima de las mejoras de eficiencia”. En otras palabras, poder deshacer errores y limitar los daños importa más que la velocidad.
Pruebas de seguridad de agentes de IA: demostrar que los controles resisten
Escribir controles en un documento de diseño es la parte fácil. Las pruebas de seguridad de agentes de IA comprueban si resisten cuando alguien intenta romperlos de forma activa, y sacan a la luz las vulnerabilidades de los agentes de IA antes de que las encuentren los atacantes. Un proyecto típico sigue los mismos pasos que daría un atacante:
- Mapear el alcance: los testers enumeran cada sistema, herramienta, cuenta y otra IA que el agente puede tocar. El resultado es el radio de impacto de tu producto, un mapa de todo lo que un agente engañado podría dañar.
- Intentar tomar el control: se introducen instrucciones ocultas en cada canal que lee el agente, desde mensajes de chat hasta archivos y páginas web.
- Medir el daño: cuando un intento funciona, los testers registran con exactitud qué se podría leer, cambiar o enviar.
- Probar los controles: los pasos de aprobación, los límites de permisos y los filtros deben bloquear las acciones de riesgo, sin dejar ningún atajo abierto.
- Volver a probar tras cada cambio: una nueva versión del modelo, un nuevo prompt o una nueva herramienta pueden reabrir una brecha que se cerró el mes pasado.
Las comprobaciones paso a paso están en una lista de verificación previa al lanzamiento para las pruebas de inyección de prompts. En los agentes que gestionan pagos, datos de salud o sistemas de producción, el trabajo se amplía a pruebas de penetración de IA, un ataque simulado completo sobre la funcionalidad de IA. Ese proyecto se combina con una prueba de penetración de las aplicaciones, los servidores y la configuración en la nube que hay detrás de la funcionalidad. Los problemas de calidad, como respuestas erróneas o inventadas, corresponden a unas pruebas de IA más amplias.
Los ingenieros de QAwerk pueden incorporarse en cualquier fase, desde una revisión del diseño antes de conectar la primera herramienta hasta una nueva prueba tras una actualización del modelo. Cada proyecto parte de los permisos reales de tu agente y termina con una lista priorizada de correcciones para tus desarrolladores. Si tu agente ya tiene acceso a sistemas reales, la seguridad de la IA agéntica empieza por saber exactamente lo que podría hacer en un mal día.
¿Quieres estar seguro de la seguridad de tu agente de IA? Llámanos.
Preguntas frecuentes
¿Qué es la seguridad de la IA agéntica?
La seguridad de la IA agéntica es la protección de los agentes de IA, un software que lee información, usa herramientas y realiza acciones sin que una persona apruebe cada paso. La seguridad tradicional asume que un programa solo hace lo que dice su código. Un agente, en cambio, puede ser convencido para comportarse de otra forma, así que la seguridad de la IA agéntica se centra en limitar y revisar todo lo que el agente puede tocar.
¿Cuáles son los riesgos de seguridad de los agentes de IA?
Los mayores riesgos de seguridad de los agentes de IA se dividen en tres grupos. Primero, los atacantes pueden secuestrar un agente con instrucciones ocultas en correos, archivos o páginas web. Después, un agente secuestrado puede abusar de permisos amplios, claves de acceso compartidas o herramientas conectadas. Por último, sin pasos de aprobación ni registros de actividad, las acciones dañinas, como fugas de datos o registros borrados, pueden pasar desapercibidas.
¿Cómo se protegen los agentes de IA?
Proteger un agente de IA funciona mejor en tres etapas. Antes del lanzamiento, concede solo el acceso que requiere cada tarea y exige la aprobación de una persona para todo lo que sea difícil de deshacer. En el lanzamiento, empieza con trabajo de bajo riesgo y registra cada acción. Después del lanzamiento, vuelve a probar cada vez que cambien el modelo, los prompts o las herramientas conectadas, porque cada actualización puede reabrir brechas antiguas.
¿Qué permisos debe tener un agente de IA?
Trata a un agente de IA como a un contratista nuevo en su primer día, con acceso solo a lo que requiere la tarea actual. El acceso de solo lectura es más seguro que los permisos de edición, cada agente necesita su propio inicio de sesión y las claves deben caducar pronto. Nunca dejes que un mismo agente combine datos privados, contenido de fuera de la empresa y una forma de enviar información al exterior.
¿Qué recomiendan las agencias gubernamentales para la seguridad de los agentes de IA?
Las agencias gubernamentales de ciberseguridad de Estados Unidos, el Reino Unido, Canadá, Australia y Nueva Zelanda recogieron sus recomendaciones en Careful Adoption of Agentic AI Services, una guía publicada en mayo de 2026. La guía pide a las organizaciones que empiecen con usos de bajo riesgo, mantengan un acceso limitado para los agentes, exijan aprobación humana para las acciones de alto impacto y prueben los agentes con regularidad mediante ataques simulados.
¿Se pueden secuestrar los agentes de IA mediante inyección de prompts?
Sí. La inyección de prompts secuestra un agente colocando órdenes dentro de algo que lee, como un ticket de soporte o un documento compartido. Los modelos de lenguaje no pueden separar de forma fiable las órdenes colocadas de las peticiones reales, y OWASP sitúa la inyección de prompts como el principal riesgo de las aplicaciones de IA en 2026. La defensa práctica es limitar lo que un agente secuestrado puede hacer.
Vea cómo ayudamos a Sitch a estabilizar su aplicación de emparejamiento de IA y escalar a nuevas ciudades mientras crecía la base de usuarios activos
