Arquitecturar agentes seguros: una defensa de «plan y política» contra la inyección de prompts

¿Qué es esto?

El 31 de marzo de 2026, investigadores de NVIDIA y colaboradores publicaron Architecting Secure AI Agents: Perspectives on System-Level Defenses Against Indirect Prompt Injection Attacks (arXiv:2603.30016). Es un position paper, no un nuevo ataque: parte de la idea de que la inyección indirecta de prompts — instrucciones maliciosas ocultas en correos recuperados, páginas web o salidas de herramientas, formalizada por primera vez por Greshake et al. en Not what you’ve signed up for (2023) — difícilmente se resolverá solo a nivel del modelo. En cambio, los autores se preguntan cómo debe estructurarse el sistema que rodea al modelo para que una sola cadena inyectada no pueda escalar hasta una acción peligrosa.

Su respuesta es una arquitectura basada en dos conceptos — el plan y la política — y tres posiciones de diseño sobre dónde deben residir las decisiones de seguridad. Uno de los coautores, Kai Greshake, estuvo en el paper original sobre inyección indirecta, lo que hace notable el planteamiento: quienes nombraron el problema ahora sostienen que la solución es arquitectónica.

Cómo funciona

El paper introduce un vocabulario para analizar agentes. Un plan describe lo que el agente pretende hacer: una secuencia ordenada (o un grafo) de pasos de ejecución, donde cada paso es una acción concreta con sus entradas y salidas — por ejemplo GET_RECENT_EMAIL(sender=Alice) -> emails; SUMMARIZE(emails) -> summary; DRAFT_REPLY(summary) -> draft. Una política describe lo que el agente tiene permitido hacer: un predicado sobre los pasos y el historial de ejecución que marca cada acción como permitida o no, induciendo el subconjunto de planes que el agente puede ejecutar legalmente. Las políticas van desde reglas globales de control de acceso estático («el agente nunca debe leer datos a los que el usuario no tiene acceso») hasta restricciones de flujo de información dependientes del contexto.

La arquitectura de referencia conecta estos conceptos en módulos distintos en lugar de en un modelo monolítico:

1. Un Orquestador (un LLM) convierte una tarea de alto nivel en un plan y una política iniciales.
2. Un Aprobador de plan/política revisa ese plan y esa política, da retroalimentación y puede escalar a un humano ante objetivos ambiguos.
3. Un Ejecutor (un LLM) convierte el plan aprobado en una acción concreta, como una llamada a herramienta con sus argumentos.
4. Un Aplicador de política aprueba o bloquea cada acción propuesta — mediante comprobaciones basadas en reglas, un juez LLM o confirmación humana para pasos de alto riesgo — antes de que llegue al entorno.
5. El Entorno (APIs, la web, el sistema de archivos) solo ejecuta acciones aprobadas y devuelve respuestas, que pueden desencadenar actualizaciones del plan o de la política.

Un punto clave: la retroalimentación del entorno pasa por puntos de control (los «escudos» del paper) donde el sistema puede transmitir el texto en bruto, transformarlo o filtrarlo hacia una representación más segura, o vigilar anomalías — de modo que una salida de herramienta no confiable nunca se convierta silenciosamente en una nueva instrucción.

Por qué importa

La mayoría de los agentes desplegados fusionan todos estos roles en un único modelo que planifica, decide qué está permitido y actúa en un único flujo de tokens indiferenciado — precisamente la condición que hace eficaz la inyección indirecta, ya que el modelo no puede separar de forma fiable las órdenes confiables de los datos no confiables. Al hacer explícitos el plan y la política y aplicarlos mediante componentes distintos, la arquitectura reduce la superficie de ataque: una instrucción inyectada en un correo recuperado puede corromper la acción propuesta por el Ejecutor, pero todavía debe pasar por un Aplicador de política configurado con independencia de ese contenido. Los autores también advierten que los benchmarks actuales pueden crear una «falsa sensación de utilidad y seguridad», porque a menudo prueban los modelos de forma aislada en lugar del sistema de extremo a extremo que realmente defendería a un agente en producción.

Defensas

La contribución del paper es un plano de defensa, organizado en tres posiciones para los profesionales que construyen sistemas agénticos:

• Replanificación dinámica y consciente de la seguridad. Los planes estáticos, de una sola pasada, fallan en entornos realistas. El sistema debe poder actualizar tanto el plan como la política a medida que el contexto evoluciona — pero tratar cada actualización como un evento de seguridad, no como una reescritura libre.
• Usar LLM solo donde sea imprescindible, y restringirlos. Las comprobaciones programáticas basadas en reglas deben gestionar todo lo que pueda formalizarse (control de acceso, listas de permitidos). Reserve el juicio del LLM para las decisiones realmente difíciles y dependientes del contexto — y cuando un LLM tome una decisión de seguridad, limite estrictamente lo que puede observar y lo que tiene permitido decidir. Una entrada restringida y un alcance de decisión estrecho hacen que el modelo sea mucho más difícil de manipular.
• Tratar la interacción humana como un elemento central del diseño. Los casos ambiguos son inevitables, por lo que la supervisión humana no puede añadirse a posteriori. El reto abierto es reducir la frecuencia de la intervención humana sin sacrificar ni la seguridad ni la utilidad.

Estas posiciones coinciden con el consenso defensivo de 2026 — incluyendo Design Patterns for Securing LLM Agents against Prompt Injections y la «Agents Rule of Two» de Meta — según el cual el mínimo privilegio, el aislamiento del contenido no confiable y el control determinista de la salida pertenecen a la arquitectura del sistema, y no solo a los pesos del modelo.

Estado

Se trata de un position paper de la comunidad (arXiv:2603.30016, publicado el 31 de marzo de 2026), no de una divulgación de vulnerabilidad, por lo que no hay parche ni CVE. Los autores describen la arquitectura como un «esqueleto» para los futuros sistemas agénticos y piden benchmarks que evalúen sistemas completos en lugar de modelos aislados. La conclusión práctica para los equipos que despliegan agentes hoy: separe la planificación, la política y la aplicación; mantenga las comprobaciones de política programáticas siempre que sea posible; y restrinja cualquier modelo usado para una decisión de seguridad a la entrada y la autoridad más estrechas posibles.