Durante años hemos hablado de seguridad en Inteligencia Artificial como si el problema principal estuviera dentro del modelo: jailbreaks, Prompt Injection, filtrado de instrucciones o respuestas que incumplen una política. Pero esa visión empieza a quedarse corta.
Un agente de IA no se limita a generar texto. Puede navegar por páginas web, consultar correos y documentos, utilizar herramientas, acceder a APIs, recordar información, delegar tareas y, en determinados sistemas, ejecutar acciones con consecuencias reales.
Ese cambio convierte la seguridad de agentes de IA en un problema mucho más amplio. Ya no basta con preguntar si el modelo puede ser engañado. También debemos preguntarnos qué puede hacer si consigue ser engañado.
Y esa diferencia aparentemente pequeña cambia por completo el modelo de amenazas.
De chatbot a agente: cambia la superficie de ataque
Un chatbot tradicional recibe una entrada y devuelve una respuesta. Puede equivocarse, revelar información o incumplir una política, pero normalmente su capacidad de provocar efectos fuera de la conversación es limitada.
Un agente moderno puede tener acceso simultáneo a diferentes fuentes de información y capacidades:
- Navegadores y páginas web.
- Correo electrónico y calendarios.
- Documentos corporativos.
- Memoria persistente.
- Bases de datos y sistemas RAG.
- Servidores MCP y otras herramientas.
- Terminales o entornos de ejecución.
- Cuentas autenticadas.
- Otros agentes de IA.
La consecuencia es directa: la frontera de seguridad deja de estar únicamente alrededor del modelo. Cada herramienta, cada dato, cada identidad y cada acción se convierte en una nueva frontera de confianza.
El ataque ya no necesita venir del usuario
Uno de los cambios más importantes aparece cuando el agente empieza a consumir información procedente del exterior.
Una página web, un correo, un documento, un comentario o el resultado de una herramienta pueden contener información legítima y, al mismo tiempo, instrucciones diseñadas para manipular al modelo.
OpenAI describe este tipo de Prompt Injection como instrucciones colocadas en contenido externo con el objetivo de conseguir que el agente haga algo que el usuario no solicitó. Además, ha señalado que los ataques más efectivos se parecen cada vez más a ingeniería social dirigida contra el agente, no simplemente a cadenas como “ignora las instrucciones anteriores”.
Anthropic plantea un riesgo equivalente para los agentes que utilizan navegador: cada página visitada puede convertirse en una fuente potencial de instrucciones no confiables. El contenido puede ser visible, estar oculto o presentarse de forma aparentemente legítima.
La cadena conceptual puede representarse así:
Contenido externo no confiable → interpretación del modelo → decisión del agente → herramienta autorizada → efecto real.
NEURON HUMAN
El problema importante no es únicamente que el contenido malicioso llegue al modelo. El problema es que el modelo pueda convertir ese contenido en una acción utilizando una autoridad que pertenece al usuario o al sistema.
Las nuevas fronteras que un guardrail tradicional no ve
Los guardrails siguen siendo una pieza importante. Pueden detectar patrones, clasificar contenido, aplicar restricciones o bloquear determinadas entradas y salidas. Pero la seguridad agentiva necesita más capas.
1. La frontera entre datos e instrucciones
Un agente necesita leer datos para trabajar. Precisamente por eso no podemos resolver el problema eliminando todo contenido externo que parezca sospechoso.
Un correo puede contener una petición legítima. Una página puede contener información necesaria para tomar una decisión. Un documento puede incluir instrucciones reales del negocio. El agente necesita interpretarlas, pero no debería permitir que esa información externa adquiera automáticamente la misma autoridad que las instrucciones del usuario o del sistema.
Ésta es una de las razones por las que filtrar únicamente “prompts maliciosos” resulta insuficiente. Cuando el ataque se parece a una mentira, una instrucción plausible o una situación de ingeniería social contextual, clasificar una cadena como maliciosa o benigna deja de ser un problema sencillo.
2. La frontera de las herramientas
Cuando conectamos herramientas a un agente, la respuesta del modelo deja de ser el efecto final.
Una tool puede permitir:
- Leer un fichero.
- Enviar un correo.
- Crear o eliminar información.
- Consultar una base de datos.
- Subir información a Internet.
- Ejecutar una operación administrativa.
La especificación oficial de MCP advierte explícitamente de que las herramientas pueden representar ejecución arbitraria y deben tratarse con la cautela correspondiente. También establece principios de consentimiento del usuario, control sobre los datos y autorización de operaciones.
Esto introduce una regla fundamental:
Que un agente pueda llamar a una herramienta no significa que deba estar autorizado a ejecutar cualquier operación de esa herramienta.
NEURON HUMAN
3. La frontera de identidad y autorización
Un agente puede utilizar una credencial perfectamente válida y aun así realizar una acción que el usuario nunca quiso autorizar.
Autenticación y autorización son problemas diferentes. Saber quién es el agente, el usuario o el servicio no responde automáticamente a preguntas como:
- ¿Puede realizar esta acción concreta?
- ¿Sobre este recurso?
- ¿Con estos datos?
- ¿Hacia este destino?
- ¿Dentro de esta tarea?
La especificación de autorización de MCP exige que los tokens utilizados contra servidores protegidos estén vinculados al recurso correcto y prohíbe el token passthrough, entre otros motivos porque puede saltarse controles de seguridad y crear problemas de confused deputy.
4. La frontera de memoria
La memoria introduce otra diferencia importante respecto a un chatbot sin estado.
Una entrada maliciosa puede dejar de ser relevante cuando termina una conversación. Pero si un agente escribe información en una memoria persistente, una base de conocimiento o un sistema RAG, el efecto puede sobrevivir a la sesión original.
Esto obliga a tratar cada escritura de memoria como una operación de seguridad: debe conservar procedencia, nivel de confianza y contexto de origen. Transformar, resumir o vectorizar información no debería hacer que una fuente no confiable se convierta mágicamente en conocimiento confiable.
5. La frontera del navegador y Computer Use
Los agentes con Computer Use añaden una capa especialmente interesante: ya no interactúan necesariamente con APIs diseñadas para máquinas, sino con las mismas interfaces gráficas que utiliza una persona.
Un clic aparentemente simple puede significar:
- Enviar un mensaje.
- Aceptar un permiso.
- Subir un documento.
- Eliminar un recurso.
- Aprobar una operación.
- Cambiar una configuración de seguridad.
OpenAI contempla esta superficie desde sus sistemas Computer-Using Agent. En la tarjeta de sistema de Operator se analizan específicamente Prompt Injection, errores del modelo y acciones difíciles de revertir, aplicando una defensa por capas que combina entrenamiento, controles del sistema, diseño de producto y monitorización.
El principio importante es que debemos aplicar políticas sobre el efecto semántico de la acción y no solamente sobre el mecanismo utilizado para ejecutarla.
Un ejemplo: el agente que investiga y termina exfiltrando datos
Imaginemos un agente al que el usuario pide revisar información pública y preparar un informe. Para completar la tarea dispone de navegador y acceso a documentos internos.
Durante la navegación encuentra contenido externo diseñado para convencerlo de que necesita consultar un documento interno adicional y enviar parte del resultado a un supuesto servicio de verificación.
La pregunta defensiva no debería ser únicamente:
¿Detectamos el Prompt Injection?
También deberíamos preguntar:
- ¿Por qué el navegador pudo influir sobre una operación con datos internos?
- ¿Por qué el agente tenía acceso al documento?
- ¿Por qué estaba autorizado a enviarlo?
- ¿El destino externo estaba permitido?
- ¿Un monitor detectó la combinación de lectura sensible y salida externa?
- ¿Podemos reconstruir posteriormente qué contenido provocó la decisión?
Ésta es la diferencia entre proteger solamente el modelo y proteger el sistema.
Por qué el filtrado de Prompt Injection no basta
Los filtros y clasificadores siguen aportando valor. El error sería tratarlos como la última línea de defensa.
OpenAI ha explicado que los ataques modernos pueden estar construidos como contenido persuasivo, contextual y aparentemente legítimo. Anthropic también considera Prompt Injection uno de los retos de seguridad más importantes para agentes basados en navegador y reconoce que el problema continúa abierto incluso con mejoras importantes de robustez.
Por tanto, una arquitectura segura debe asumir una posibilidad incómoda:
Algún ataque terminará atravesando la capa que intentaba detectarlo.
NEURON HUMAN
La siguiente pregunta es entonces mucho más útil: ¿qué puede hacer el atacante después?
Cómo debería defenderse un sistema agentivo
La seguridad de agentes de IA necesita una estrategia por capas. No todas las arquitecturas requieren exactamente los mismos controles, pero existen principios que deberían aparecer de forma recurrente.
1. Separar datos de autoridad
Una web, un documento o la salida de una herramienta pueden proporcionar datos. No deberían poder concederse autoridad a sí mismos mediante contenido.
La procedencia debe acompañar a la información a medida que atraviesa transformaciones, resúmenes, memoria y herramientas.
2. Aplicar mínimo privilegio
El agente debería disponer únicamente de las capacidades necesarias para la tarea actual. Reducir accesos, herramientas y credenciales limita el impacto de una manipulación incluso cuando el modelo falla.
3. Autorizar la acción, no solo la herramienta
Permitir el uso de una herramienta no debería equivaler a autorizar todas sus operaciones. Las acciones de alto impacto necesitan políticas sobre recurso, destino, datos, identidad y contexto.
4. Aislar la ejecución
Cuando los agentes ejecutan código, navegan o manipulan archivos, el aislamiento reduce el daño potencial. Sandboxing, contenedores, máquinas virtuales y restricciones de red siguen siendo controles extremadamente relevantes.
5. Supervisar las acciones sensibles
La confirmación humana puede ser una capa útil para operaciones importantes, aunque no debería ser la única barrera. Las confirmaciones deben explicar con claridad qué acción exacta se va a realizar, sobre qué recurso y con qué consecuencias.
6. Observar el comportamiento completo
No basta con registrar la respuesta final del modelo.
Una arquitectura de seguridad debería poder observar:
- Qué datos se leyeron.
- Qué herramientas fueron llamadas.
- Qué decisiones de autorización se produjeron.
- Qué destinos externos participaron.
- Qué memoria se escribió.
- Qué efecto real terminó ocurriendo.
Blue Team para agentes de IA
Esta nueva superficie también cambia el trabajo defensivo.
Un Blue Team aplicado a sistemas agentivos necesita correlacionar eventos que en una aplicación tradicional podrían parecer independientes.
Por ejemplo:
Contenido externo no confiable → lectura de recurso sensible → llamada a herramienta → nuevo destino externo.
Cada evento aislado podría ser legítimo. La cadena completa puede indicar un intento de exfiltración.
Esto exige telemetría específica para agentes: identidad, tarea raíz, herramienta, decisión, datos implicados, procedencia, destino y resultado.
Purple Team: no basta con bloquear el ataque
Probar la seguridad de un agente tampoco debería limitarse a lanzar un Prompt Injection y comprobar si el modelo responde “no”.
Una prueba defensiva más completa debería comprobar:
- Prevención: ¿se evitó la acción peligrosa?
- Detección: ¿algún sensor identificó la anomalía?
- Correlación: ¿el sistema entendió la cadena completa?
- Respuesta: ¿se limitó o contuvo correctamente el incidente?
- Forensics: ¿podemos reconstruir qué ocurrió?
- Validez: ¿la propia evaluación estaba midiendo realmente aquello que afirmaba medir?
Un sistema puede bloquear una prueba concreta y seguir siendo vulnerable a la misma clase de ataque mediante otra ruta. Por eso la seguridad agentiva debe evaluar propiedades y límites de confianza, no únicamente cadenas conocidas.
Dónde encaja MindGuard
Esta visión por capas es una de las razones por las que estamos desarrollando MindGuard.
El objetivo no es crear otro filtro situado delante del modelo. Un sistema de seguridad para agentes necesita poder relacionar guardrails, memoria, herramientas, identidad, autorización, flujo de datos, runtime, observabilidad y evaluación defensiva.
El modelo sigue siendo importante, pero ya no es la única frontera.
Una de las propiedades que queremos preservar puede resumirse así:
Los datos no deberían convertirse automáticamente en autoridad, y la autoridad de un agente nunca debería superar la intención real del usuario.
MINDGUARD RESEARCH
La seguridad de agentes apenas está empezando
La industria está pasando rápidamente de modelos que responden a sistemas que actúan.
Ese salto ofrece enormes posibilidades, pero también obliga a recuperar principios clásicos de ciberseguridad que nunca dejaron de ser importantes: mínimo privilegio, aislamiento, procedencia, autorización explícita, monitorización, defensa en profundidad y capacidad de auditoría.
Los guardrails seguirán formando parte de esa arquitectura. Simplemente debemos dejar de pedirles que resuelvan por sí solos un problema que ya es mucho mayor que el contenido de un prompt.
La nueva pregunta no es únicamente si podemos confiar en la respuesta de una Inteligencia Artificial.
La pregunta que definirá la seguridad agentiva será:
¿Hasta dónde puede llegar una IA cuando interpreta mal, o alguien consigue manipular, aquello que acaba de ver?
NEURON HUMAN
Referencias
- OpenAI — Designing AI agents to resist prompt injection
- OpenAI — Understanding prompt injections: a frontier security challenge
- OpenAI — Operator System Card
- Anthropic — Mitigating the risk of prompt injections in browser use
- Anthropic — Trustworthy agents in practice
- Model Context Protocol — Specification
- Model Context Protocol — Security Best Practices
Preguntas frecuentes
¿Qué es la seguridad de agentes de IA?
Es el conjunto de controles destinados a proteger sistemas de Inteligencia Artificial capaces de utilizar herramientas, memoria, datos, navegadores, APIs u otros agentes para ejecutar tareas y provocar efectos fuera de una conversación.
¿Un guardrail puede evitar todos los Prompt Injection?
No. Los guardrails pueden reducir significativamente el riesgo y son una capa importante, pero los ataques contextuales y de ingeniería social hacen necesario combinar detección con autorización, mínimo privilegio, aislamiento y monitorización.
¿Por qué los agentes de IA tienen más riesgo que un chatbot?
Porque pueden disponer de herramientas, credenciales, memoria y acceso a sistemas externos. Un error de interpretación puede convertirse en una acción real, no únicamente en una respuesta incorrecta.
¿Qué papel tiene MCP en la seguridad de agentes?
MCP permite conectar modelos y agentes con recursos y herramientas externas. Esto hace especialmente importantes la autenticación, la autorización, el consentimiento, la validación de tokens y el control de las capacidades expuestas por cada servidor.
¿Qué debería probar un Purple Team en un agente de IA?
No solo si una inyección es bloqueada. También debería verificar detección, correlación, respuesta, evidencia forense, límites de autoridad, aislamiento de datos y comportamiento de herramientas bajo contenido externo no confiable.
[…] problema forma parte de una superficie mucho más amplia dentro de la seguridad de agentes de IA, especialmente cuando el sistema puede interpretar información externa y convertirla […]