Autorizar los pasos del flujo de un agente, no solo su identidad

¿De qué se trata?

El 20 de julio de 2026, un grupo de investigadores publicó en arXiv (categoría cs.CR, criptografía y seguridad) un artículo que replantea un problema que la mayoría de las pilas de agentes resuelve mal. A medida que los sistemas empresariales y de administración pública se convierten en «infraestructuras basadas en el lenguaje, que usan herramientas y cada vez más autónomas», sostienen los autores, el modelo de seguridad heredado de la gestión de claves clásica deja de encajar. Un servicio de gestión de claves autentica quién puede invocar una primitiva criptográfica: verifica una identidad y entrega la capacidad. Lo que no hace es decidir qué paso del flujo de trabajo está autorizado a ejecutar un llamante autenticado en tiempo de ejecución. Justo ahí es donde el agente se vuelve peligroso: un agente que ha superado todos los controles de identidad todavía puede ser dirigido, mediante inyección de prompts directa o indirecta, hacia una acción perfectamente válida para su identidad pero contraria a lo que el usuario realmente quería. La contribución del artículo es un diseño que busca cerrar esa brecha: una capa de gobernanza situada entre el modelo y las herramientas privilegiadas que puede alcanzar.

Cómo funciona

La observación central es una distinción fácil de difuminar en el diseño de un agente: la autenticación no es autorización, y la autorización por agente no es la autorización por paso.

La mayoría de los agentes desplegados vinculan el privilegio a la identidad. El agente (o su cuenta de servicio) posee un token, una clave de API o una capacidad de firma; una vez autenticado el agente, toda acción que emite hereda ese privilegio. Es el propio modelo el que decide qué herramienta llamar y con qué argumentos, a partir de un contexto en lenguaje natural que ha leído: mensajes del usuario, documentos recuperados, salidas de herramientas, mensajes entre agentes. Como ese contexto es precisamente el canal que el atacante controla en un ataque de inyección de prompts, la decisión de actuar puede corromperse mientras que la credencial usada para actuar sigue siendo del todo legítima. Los controles de identidad pasan. La intención queda traicionada. Ningún control del tipo «¿quién eres?» puede distinguir ambos casos.

La respuesta que propone el artículo se llama Neural Cryptographic Services (NCS), descrita como un plano de gobernanza de seguridad activo, basado en un diseño neuro-simbólico e interpuesto entre los agentes LLM y las herramientas privilegiadas que invocan. La idea que conviene retener, con independencia de la implementación concreta, es arquitectónica: la autoridad debería vincularse al paso —una acción concreta, en un flujo concreto, coherente con la intención expresada por el usuario— y no a la identidad persistente del agente. Un punto de control que media cada llamada privilegiada puede evaluar si esta acción está autorizada ahora, en lugar de suponer que un agente autenticado es un agente de confianza. Aquí no se reproduce ningún exploit; el valor está en el modelo del problema y en la ubicación de la defensa.

Por qué importa

Es el mismo modo de fallo que reaparece con distintos nombres en la investigación sobre seguridad de agentes. El flujo de datos se trata como autoridad; una instrucción llegada a través de un documento o de una salida de herramienta se ejecuta como si el usuario la hubiera escrito; un agente de código o de navegación con un token amplio hace algo fuera de alcance pero «dentro de la política». La contribución del artículo es nombrar con claridad la causa raíz —la capa de autenticación es agnóstica a la intención del flujo de trabajo— y defender que la corrección corresponde a un plano de autorización dedicado, y no al propio juicio del modelo.

Importa sobre todo donde el radio de impacto es mayor: agentes conectados a la gestión de claves, a los pagos, a los planos de control en la nube, o a los back-ends empresariales y públicos, donde una sola acción contraria a la intención pero válida en identidad puede mover dinero, rotar un secreto o modificar un registro. Para esos sistemas, «el agente se autenticó con éxito» no es una propiedad de seguridad. La inyección de prompts sigue siendo el riesgo mejor clasificado en la guía de OWASP para aplicaciones LLM precisamente porque convierte a un agente de confianza y autenticado en un agente pilotado por el atacante, sin romper jamás ninguna credencial.

Defensas

La lección práctica es dejar de tratar la identidad de un agente como sustituto de su autorización para actuar. Coloque un punto de control determinista entre el modelo y cualquier herramienta privilegiada, y hágalo autorizar acciones con la granularidad del paso del flujo de trabajo, no una sola vez al iniciar sesión. En concreto, esto significa vincular cada llamada privilegiada a una intención explícita anclada en el usuario y al paso del plan al que pertenece, y rechazar las llamadas que satisfacen la identidad pero no la intención, un enfoque presente en trabajos concurrentes sobre autorización determinista previa a la acción y flujos de trabajo agénticos autenticados. Mantenga la aplicación fuera del modelo: una política de la que se puede convencer al LLM para salir no es un control. Reduzca las credenciales a la capacidad más estrecha y la vida útil más corta que exija el paso, de modo que incluso una acción secuestrada-pero-autenticada tenga un alcance limitado. Trate los documentos recuperados, las salidas de herramientas y los mensajes entre agentes como entradas no confiables que pueden proponer acciones pero nunca autorizarlas en silencio. Y registre la decisión de autorización, no solo la llamada a la herramienta, para que un desajuste entre la intención declarada y la acción ejecutada sea auditable a posteriori. Estos controles se componen con el filtrado de entradas y las defensas anti-jailbreak, sin reemplazarlos: la idea es que, cuando la inyección tiene éxito, el plano de autorización es lo que se interpone entre una decisión corrompida y una acción privilegiada.

Estado

Elemento	Detalle
Contribución	Encuadre + plano de gobernanza propuesto para la autorización por paso
Afirmación central	La autenticación («quién») no autoriza el paso del flujo («qué acción, ahora»)
Amenaza	Inyección de prompts directa/indirecta que produce acciones válidas en identidad pero contrarias a la intención
Diseño propuesto	Neural Cryptographic Services (NCS): plano de gobernanza neuro-simbólico entre agentes y herramientas privilegiadas
Ubicación	Punto de control determinista interpuesto en cada llamada a herramienta privilegiada
Fecha clave	Artículo publicado en arXiv el 20 de julio de 2026

Fecha clave: artículo anunciado en arXiv el 20 de julio de 2026. Se trata de una propuesta de investigación, no de un producto terminado; la enseñanza duradera es arquitectónica: autorice el paso, no la identidad.