Por qué la vulnerabilidad de la IA agéntica es arquitectónica, no solo táctica

Según el informe de seguridad LLM 2026 de OWASP, los ataques de inyección de prompts crecieron un 340% interanual. Hoy son el riesgo número 1 para los sistemas de IA.

Pero hay algo que la mayoría de organizaciones no entiende: la inyección de prompts no es un problema del que se salga filtrando. Es un problema del que se sale rediseñando la arquitectura.

Y los sistemas agénticos sin estado — la arquitectura que domina hoy la IA empresarial — no tienen esas propiedades arquitectónicas.

Inyección de prompts solía significar: "engañar a un chatbot para que ignore sus salvaguardas". Eso sigue siendo inyección, pero es la versión menos peligrosa.

En 2026 significa otra cosa: "explotar la incapacidad arquitectónica de un sistema para distinguir entre instrucciones confiables y entrada externa no confiable".

La diferencia importa. Un chatbot que dice algo inapropiado es un problema manejable. Un agente autónomo que ejecuta código, accede a bases de datos y envía correos siguiendo instrucciones inyectadas es un riesgo existencial.

Hay una razón por la que la inyección de prompts se convirtió en el riesgo número 1. No es que los atacantes se hayan vuelto más listos de la noche a la mañana: es que desplegamos una configuración arquitectónica inherentemente vulnerable.

Elemento 1: procesamiento sin estado. Un sistema agéntico procesa una petición que puede contener:

• —Instrucciones legítimas del operador del sistema
• —Entrada del usuario
• —Datos externos recuperados
• —Respuestas de APIs integradas
• —Contenido de documentos y mensajes de correo

Todo son tokens. No existe un mecanismo nativo para decir "este flujo viene de una fuente confiable" frente a "este viene de datos externos no confiables". El sistema lo trata todo igual porque, desde la perspectiva del modelo, todo es texto.

Elemento 2: acceso a herramientas. Los primeros chatbots tenían un radio de impacto limitado: generaban texto. Los sistemas agénticos actúan:

• —Ejecución de código (Claude Code, Gemini CLI, Aider)
• —Consultas a bases de datos (SQL autogenerado)
• —Acceso al sistema de ficheros (escritura y borrado)
• —Llamadas a APIs (datos externos, webhooks)
• —Integración de correo (envío en nombre del usuario)

Una inyección que manipula la generación de texto es molesta. Una inyección que manipula una decisión de ejecución de código es catastrófica.

Elemento 3: integración de entrada no confiable. Los sistemas agénticos son útiles precisamente porque procesan datos externos: correos, documentos compartidos, la web abierta. Pero el dato externo es no confiable por naturaleza. Un correo puede venir reenviado por un atacante. Un documento compartido puede estar envenenado. Una página web puede contener contenido malicioso. Cuando el sistema procesa esa entrada sin poder verificar su origen, la inyección se vuelve posible.

Esto no es teórico. El informe de OWASP de 2026 cataloga incidentes reales.

El ataque a la cadena de suministro de LiteLLM (marzo de 2026). Apareció una puerta trasera en LiteLLM en PyPI — la pasarela de modelos de lenguaje de decenas de frameworks de agentes (CrewAI, DSPy, Microsoft GraphRAG). Duró tres horas. Casi 47.000 descargas en esa ventana. Quien usara esos frameworks en ese intervalo incorporó código comprometido que modificaba cómo se procesaban los prompts. Es inyección de prompts a nivel de cadena de suministro.

Avisos de seguridad en agentes de código. El análisis de CrowdStrike de 2026 encontró que los cinco agentes de código de mayor crecimiento (Claude Code, Gemini CLI, Codex, Cline, Aider) acumulan también el mayor número de avisos de seguridad. Claude Code: 22 avisos. AutoGPT: 15. Dify: 13. La mayoría implican manipulación de decisiones de ejecución mediante inyección.

El patrón EchoLeak. Un atacante incrusta una instrucción en un documento compartido o un correo. Un empleado hace una pregunta rutinaria a su agente. El agente lee el documento como contexto, interpreta la instrucción oculta como legítima y exfiltra datos a través de la URL de una imagen. Los investigadores reprodujeron después el mismo ataque sobre el stack de otro proveedor. La vulnerabilidad es arquitectónica, no propia de un framework.

La respuesta de la industria ha sido táctica:

• —Estratificación de instrucciones. Separar el prompt de sistema de la entrada del usuario con tokens especiales ayuda, pero el lenguaje es demasiado flexible y los atacantes encuentran rodeos.
• —Filtrado de prompts. Buscar patrones sospechosos detecta lo evidente, pero la inyección inteligente usa lenguaje normal y el filtro no ve anomalía.
• —Aprobación humana. Exigir validación en acciones de alto riesgo es buena práctica, pero añade fricción y no evita la exfiltración.
• —Acceso segmentado. Limitar lo que un agente alcanza es seguridad sólida, pero no arregla un agente que no puede distinguir origen confiable de no confiable.
• —Monitorización y registro. Útil en forense, pero cuando detectas la inyección el daño ya está hecho.

Ninguna resuelve el problema de fondo: un sistema sin estado no puede distinguir la fuente.

Hay problemas que no se parchean: exigen repensar la arquitectura. Compara dos enfoques.

Arquitectura agéntica sin estado (estándar actual): recibir petición, recuperar contexto de múltiples fuentes, fusionarlo todo en un prompt, generar respuesta o acción, ejecutar. El problema: no hay forma de verificar qué vino de dónde. La inyección es invisible.

Arquitectura relacional persistente (otro enfoque): mantener una comprensión establecida del usuario, comparar la nueva entrada con los patrones establecidos, marcar contradicciones o anomalías, exigir verificación ante inconsistencias y solo entonces procesar con contexto verificado. La ventaja: el sistema detecta cuándo la entrada contradice lo que ya sabe.

No hace imposible la inyección. Cambia el modelo de amenaza de "el atacante inyecta una vez y gana" a "el atacante inyecta y el sistema detecta la contradicción".

La arquitectura sin estado no es mala en sí misma. Es eficiente, escala y es la elección correcta para muchos casos.

Pero sin estado + acceso de alto impacto + entrada no confiable = vulnerabilidad estructural. Cuando se combinan los tres, la inyección de prompts no es un bug: es una consecuencia inevitable de la arquitectura.

No puedes filtrar tu salida de un problema arquitectónico.

Si despliegas sistemas agénticos en 2026, empieza por tu modelo de amenaza. ¿Tienes agentes con acceso a datos sensibles, que procesan entrada externa y que pueden ejecutar acciones? Si la respuesta es sí a las tres, tienes una clase de vulnerabilidad que los filtros no van a resolver.

Después, implanta controles arquitectónicos:

• —Establece líneas base. ¿Qué es comportamiento normal para este agente y qué es anómalo?
• —Verifica antes de ejecutar. No valides solo la entrada: comprueba que la acción solicitada es coherente con el contexto conocido.
• —Mantén estado. Si un agente cambia de patrón de comportamiento de golpe, eso es una señal.
• —Segmenta el acceso. Trata a los agentes como cuentas de servicio; rara vez necesitan todo a la vez.

Para casos críticos, considera arquitecturas alternativas. Si tu agente toma decisiones críticas o maneja datos sensibles, sin estado + RAG puede no ser suficiente. La arquitectura relacional persistente ofrece propiedades defensivas distintas: no inmunidad, sino resistencia estructural a los patrones que estamos viendo en 2026.

Y prueba específicamente la inyección. ¿Puede un atacante inyectar instrucciones mediante los documentos que procesas? ¿Mediante prompts ocultos en correos o páginas web? ¿Puede provocar una exfiltración que tu monitorización no vería? La mayoría de las pruebas de seguridad lo pasan por alto porque preguntan "¿podemos romper el modelo?" en lugar de "¿podemos manipular la decisión del agente vía entrada externa?".

La industria eligió la arquitectura agéntica sin estado porque es eficiente y escala fácil. Esa eficiencia tiene un coste: ninguna forma nativa de verificar el origen ni de detectar contradicciones.

Luego atornillamos defensas tácticas — filtrado, capas, controles de acceso — esperando que resolvieran un problema arquitectónico. No lo han hecho. El aumento del 340% lo demuestra.

Un enfoque mejor a largo plazo pasa por repensar la arquitectura: ¿cómo construimos agentes que procesen entrada externa de forma segura? ¿Cómo les damos contexto sin darles entrada ambigua? ¿Cómo les dejamos actuar de forma autónoma sin perder la capacidad de detectar manipulación? Son preguntas más difíciles. También son las correctas.

Los sistemas relacionales persistentes funcionan distinto. En lugar de recibir consulta → recuperar datos externos → generar respuesta, funcionan como recibir entrada → comparar con la comprensión establecida → marcar contradicciones → exigir verificación → procesar.

No se trata de ser "más seguro". Se trata de tener propiedades arquitectónicas que hacen detectable la inyección. Un sistema relacional puede decir: "Esta petición es inconsistente con lo que entiendo de tus patrones habituales. ¿Verificamos?". Uno sin estado no puede: no tiene patrones a los que referirse ni contexto establecido con el que comparar.

En sistemas como Lena — una compañera persistente para acompañamiento continuado — esa propiedad emerge de forma natural del diseño. El sistema mantiene comprensión relacional en el tiempo, y esa comprensión se convierte en un detector de inconsistencias. En sistemas agénticos diseñados para la velocidad, añadir la misma propiedad es posible, pero es un cambio arquitectónico, no un parche.

La inyección de prompts no va a desaparecer. Que siga siendo el riesgo número 1 dependerá de si las organizaciones repiensan la arquitectura o siguen parcheando la misma vulnerabilidad estructural.

Mejores filtros no lo resuelven. Mejores prompts no lo resuelven. Mejores controles de acceso ayudan, pero no lo resuelven. Solo el cambio arquitectónico lo resuelve.

Y ese cambio no tiene por qué parecerse a los sistemas relacionales persistentes. Pero sí tiene que implicar cuestionar la suposición de que sin estado más entrada no confiable está bien si añades suficientes defensas tácticas encima. No lo está.

Sergi López — AI Security Engineer, Almaia Tech

En Almaia construimos IA Relacional: sistemas persistentes diseñados para relaciones a largo plazo. Una consecuencia de ese diseño es que la detección de contradicciones se vuelve posible; no como una función de seguridad añadida, sino como una propiedad emergente de la arquitectura.