: Por qué cambia el modelo de amenazas
La mayor parte del trabajo de seguridad de la IA se centra en el modelo: qué dice, qué rechaza y cómo maneja las indicaciones maliciosas. Este encuadre tenía sentido cuando la IA era una interfaz de texto. El usuario envía un mensaje y este responde. La superficie de ataque era estrecha y bien definida.
Los agentes cambian por completo la forma del problema.
Un agente de IA hace mucho más que generar texto. Planifica, utiliza herramientas, almacena memoria entre sesiones y, a menudo, se coordina con otros agentes para completar tareas de varios pasos. Piense en la diferencia entre una aplicación de navegación que sugiere una ruta y un sistema de piloto automático conectado directamente a la dirección y el acelerador del vehículo. Uno proporciona información. El otro ejecuta el control. El modelo de riesgo ya no es comparable.
Las cifras confirman que esto ya no es una preocupación teórica. Según el informe sobre el estado de la seguridad de los agentes de IA de 2026 de Gravitee, basado en una encuesta a más de 900 ejecutivos y profesionales:
El 88 por ciento de las organizaciones informaron incidentes de seguridad de agentes de IA confirmados o sospechados durante el año pasado. Solo el 14,4 por ciento de los sistemas de agentes se pusieron en funcionamiento con total seguridad y aprobación de TI.
Este patrón se extiende por toda la industria. Un informe de Apono de 2026 encontró que el 98 por ciento de los líderes de ciberseguridad reportan fricciones entre acelerar la adopción de IA agente y cumplir con los requisitos de seguridad, lo que resulta en implementaciones lentas o limitadas.
Esa brecha entre la velocidad de implementación y la preparación de la seguridad es donde ocurren los incidentes.
Un LLM independiente tiene una superficie de ataque: el aviso. Un agente expone cuatro:
La superficie de aviso: lectura de entradas externas. La superficie de la herramienta: ejecución de acciones de backend. La superficie de la memoria: recordando sesiones pasadas. La superficie del circuito de planificación: decidir los próximos pasos.
Cada superficie tiene sus propios patrones de ataque. Las defensas construidas para uno no se transfieren a los demás.
La taxonomía del ataque de las cuatro superficies
A mediados de 2025, Pomerium informó sobre un agente de soporte de IA que ejecutó ciegamente una carga útil SQL oculta, filtrando secretos de la base de datos en un ticket público. La seguridad tradicional falla aquí. Agregar herramientas, memoria y planificación autónoma a un LLM crea cuatro superficies de ataque distintas, cada una de las cuales requiere un modelo de amenaza completamente nuevo.
La superficie del mensaje: cuando el agente lee algo incorrecto
La entrada del usuario está perfectamente limpia. La vulnerabilidad radica en todo lo demás que consume el agente.
Cuando un agente recupera una página web, un documento RAG o una respuesta de backend, estas entradas llegan sin un límite de confianza. Los atacantes no comprometen la interfaz de usuario; Colocan cargas útiles donde el agente eventualmente buscará. Esta es una inyección rápida indirecta.
Debido a que los modelos aplanan todo el texto en una única ventana contextual, no pueden distinguir las instrucciones del sistema de un comando oculto dentro de un PDF recuperado. Tratan el texto malicioso como un contexto confiable. Incluso las cadenas de documentación de las herramientas y los nombres de los parámetros pueden secuestrar de manera invisible el comportamiento del agente, lo que lleva a una filtración silenciosa de datos en sentido ascendente mientras el usuario ve una respuesta normal.
Cómo se ve la defensa aquí:
Limpieza de límites: trate todos los datos externos como si no fueran de confianza en cada punto de recuperación. Separación de instrucciones: utilice formatos estructurados para aislar las indicaciones del sistema del contenido obtenido. Filtrado previo a la ejecución: busque patrones de exfiltración antes de que se active cualquier herramienta.
Estos controles aseguran lo que ingiere el agente. Pero una vez que actúa, el ataque se traslada a la superficie de la herramienta.
La superficie de la herramienta: cuando leer se convierte en hacer
Cada herramienta a la que un agente puede recurrir es un límite de permiso, lo que la convierte en un objetivo principal de explotación. El ataque principal es la inyección de parámetros: manipular al agente para que pase valores controlados por el atacante a herramientas que desencadenan consecuencias en el mundo real, como escrituras en bases de datos o solicitudes API firmadas.
El incidente de Pomerium mencionado anteriormente ilustra exactamente cómo esto falla en la práctica. El ataque tuvo éxito porque convergieron tres fallas arquitectónicas: privilegios excesivos otorgados al agente, entradas de usuario no validadas que llegaron a la herramienta SQL y un canal de datos saliente abierto. Desafortunadamente, esto describe la configuración predeterminada de la mayoría de los agentes actuales.
Cómo se ve la defensa aquí:
Mínimo privilegio: alcance los permisos estrictamente para la tarea exacta. Validación de parámetros: verifique todas las entradas con esquemas estrictos antes de la ejecución. Puntos de control humanos: requieren aprobación manual para cualquier acción irreversible.
Asegurar estas herramientas bloquea el presente. Pero una vez que un agente agrega memoria persistente, la vulnerabilidad cambia a lo que recuerda para más adelante.
La superficie de la memoria: cuando reposa la pizarra
Imagine una pizarra de oficina compartida en la que se pueda tomar decisiones diarias. Si un extraño reescribe silenciosamente una entrada durante la noche, toda la producción del equipo cambia en función de datos corruptos. La memoria persistente en un agente autónomo funciona exactamente de la misma manera. Controle lo que recuerda el agente y usted dicte sus acciones futuras en todas las sesiones y usuarios.
Los datos sobre esta vulnerabilidad son muy preocupantes:
El marco MINJA: las pruebas de seguridad en los modelos líderes lograron una tasa de éxito del 95 % al inyectar silenciosamente recuerdos falsos, sin requerir privilegios elevados ni acceso a API. Microsoft Defender Intel: en solo 60 días, los investigadores interceptaron más de 50 ataques en 14 industrias. Los adversarios utilizaron parámetros de URL ocultos para ordenar en secreto a los agentes que favorecieran a empresas específicas en respuestas futuras. Implementación de costo cero: estos ataques no fueron lanzados por grupos de amenazas avanzadas. Fueron ejecutados por equipos de marketing cotidianos utilizando paquetes de software gratuitos, lo que demuestra que este exploit tarda unos minutos en implementarse y no cuesta nada.
Cómo se ve la defensa aquí:
Seguimiento de procedencia: registre de forma segura el origen, el contexto y la marca de tiempo de cada escritura en la memoria. Recuperación ponderada por confianza: las entradas de usuarios autenticados deben superar estrictamente el contenido externo no verificado. Decaimiento temporal (TTL): implemente umbrales de antigüedad donde las entradas de memoria decaen o se eliminan explícitamente. Auditoría periódica: ejecute auditorías automatizadas para detectar grupos anómalos de instrucciones maliciosas.
El envenenamiento de la memoria es peligroso por sí solo, pero prepara el escenario para la superficie de ataque final.
El ciclo de planificación: cuando el destino es equivocado
Un GPS alimentado con datos de mapas falsos aún proporciona indicaciones paso a paso seguras. La lógica de enrutamiento funciona perfectamente, pero el destino es incorrecto. El conductor no tiene idea hasta que llega a un lugar al que nunca tuvo intención de ir.
El ciclo de planificación es el motor de razonamiento de un agente. Si un atacante se desplaza hacia donde el agente cree que se dirige, no necesita inyectar comandos específicos. El agente navegará de forma autónoma hasta el objetivo malicioso.
Este cambio puede originarse en cualquier superficie que acabamos de cubrir: una entrada de memoria envenenada, el retorno de una herramienta manipulada o un documento externo malicioso. Pero el verdadero peligro es la velocidad del contagio. En una simulación realizada en diciembre de 2025 por Galileo AI, un único orquestador comprometido envenenó el 87% de la toma de decisiones posteriores en una arquitectura de múltiples agentes en cuatro horas. Corromía a todos los agentes que confiaban en su producción.
Cómo se ve la defensa aquí:
Registro de razonamiento: registre los pasos de razonamiento intermedios, no solo los resultados finales. Validación de puntos de control: valide el estado objetivo en puntos de control definidos durante la ejecución de la tarea. Límites estrictos: defina condiciones de detención estrictas en la implementación que el contenido recuperado no pueda anular. Aislamiento del agente: aísle las instancias del agente para que un único compromiso no pueda propagarse libremente por todo el sistema.
Seguridad versus autonomía del agente: el espacio de compensación
Cada mitigación en las superficies de aviso, herramienta, memoria y bucle de planificación conlleva un costo inherente, ya que ignorar estas compensaciones produce un teatro de seguridad en lugar de una protección real. El aislamiento de un entorno de herramientas limita lo que un agente puede alcanzar, que es precisamente el punto, pero también funciona como una reducción directa de la capacidad general del agente. De manera similar, la implementación de puertas de control humano en acciones irreversibles evita escrituras no autorizadas, pero introduce una latencia que puede erosionar el argumento comercial para la automatización. Otros controles esenciales, como auditorías periódicas de memoria, validación estricta de parámetros y filtrado de recuperación, ralentizan aún más el procesamiento o solucionan casos extremos imprevistos.
La seguridad y la autonomía existen en un dial, no en un interruptor binario. La configuración óptima para cualquier implementación está determinada por tres factores específicos:
Perfil de capacidad: los controles deben ser proporcionales a lo que el agente está autorizado a hacer, ya que un agente de solo lectura conlleva una fracción del riesgo en comparación con un orquestador de múltiples agentes. Entorno de tareas: un agente que resume documentos internos opera en un entorno de amenazas fundamentalmente diferente al de uno que gestiona infraestructura crítica. Radio de explosión: las decisiones deben basarse en el peor resultado de un exploit en lugar de en su probabilidad percibida.
La necesidad de este enfoque se ve subrayada por el hecho de que la seguridad a nivel de modelo falla bajo presión. La investigación de Stanford demostró que los ataques de ajuste superaron los filtros de seguridad en el 72% de los casos de Claude Haiku y en el 57% de los casos de GPT-4o, y tanto Anthropic como OpenAI reconocieron el ataque como una vulnerabilidad. Debido a que el entrenamiento de la capa de modelo no es un sustituto confiable de la seguridad de la capa de ejecución, son obligatorios controles sólidos a nivel de sistema para cualquier implementación de nivel de producción.
Implementación: pasar de la taxonomía a la arquitectura
La taxonomía de las superficies de ataque sólo importa si influye directamente en cómo se construye un sistema. El panorama de amenazas activas depende completamente de las capacidades de un agente.
Combinación de controles con la arquitectura
Agentes de herramienta única: para los agentes sin memoria persistente y sin acciones salientes, la vulnerabilidad principal es la superficie de solicitud. La seguridad mínima viable incluye desinfección de entradas en los límites de recuperación, permisos de alcance estricto y registro de auditoría completo de las llamadas a herramientas. Orquestadores de agentes múltiples: los sistemas con memoria persistente y la capacidad de generar agentes posteriores exponen las cuatro superficies simultáneamente.
Priorizar por radio de explosión
La seguridad efectiva prioriza el impacto potencial de un exploit sobre su probabilidad percibida:
Primero los permisos: la mayoría de los incidentes, como la filtración de Supabase, se deben a privilegios excesivos; hacer cumplir el mínimo privilegio es el control de mayor apalancamiento y menor costo. Fuentes de instrucciones separadas: las instrucciones del sistema y el contenido recuperado nunca deben compartir un contexto de confianza para cerrar la mayor parte de la superficie del mensaje. Procedencia de la memoria: investigaciones como MemoryGraft muestran cómo los compuestos de memoria envenenados; Se debe realizar un seguimiento de la fuente de cada escritura en la memoria antes de escalar. Razonamiento del monitor: el filtrado de salida no puede detectar el secuestro de objetivos; Los sistemas deben registrar pasos de razonamiento intermedios en lugar de solo resultados finales.
Los marcos fuera de proceso, como Agent Governance Toolkit de Microsoft, aplican políticas de forma independiente, manteniendo el control incluso si el agente está comprometido. En última instancia, usted puede mapear estas superficies de ataque deliberadamente antes de su implementación o descubrirlas durante los análisis forenses posteriores al incidente.
Conclusión
El cambio de LLM a agente es un cambio estructural en lo que el sistema puede hacer y, por tanto, en lo que puede salir mal. Las cuatro superficies cubiertas en este artículo se combinan entre sí, donde una entrada de memoria envenenada permite el secuestro de objetivos, una herramienta con privilegios excesivos convierte una inyección en exfiltración y un orquestador comprometido corrompe a todos los agentes posteriores. Las organizaciones que gestionan estos riesgos de manera efectiva son las que mapearon el problema antes de la implementación, combinaron los controles con los perfiles de capacidad reales y construyeron el monitoreo en la capa de razonamiento en lugar de solo en la capa de salida. Esta taxonomía no elimina la amenaza y proporciona un mapa preciso del terreno antes de construir en él, porque lo que se mapea se puede defender y lo que se omite se descubrirá a través de un incidente.
Gracias por leer. Soy Mostafa Ibrahim, fundador de Codecontent, una agencia de contenido técnico centrada en los desarrolladores. Escribo sobre sistemas agentes, RAG e IA de producción. Si desea mantenerse en contacto o discutir las ideas de este artículo, puede encontrarme en LinkedIn aquí.