En agosto de 2025, investigadores de Persistent Security documentaron una vulnerabilidad en GitHub Copilot que permitía comprometer por completo la máquina de un desarrollador. El mecanismo era deceptivamente sencillo: instrucciones maliciosas incrustadas en un archivo README —texto que el agente procesaba como parte normal de su tarea— lograban que Copilot modificara su propio archivo de configuración, habilitara el modo de autoaprobación y ejecutara comandos arbitrarios sin intervención del usuario. Sin alerta. Sin fricción visible. La vulnerabilidad, catalogada como CVE-2025-53773 con una puntuación CVSS de 7.8, fue parcheada en agosto. Pero el patrón que expone no desaparece con el parche.
Cada semana se documenta una variante nueva. La respuesta convencional sigue siendo la misma: filtrar inputs, sanitizar prompts, entrenar modelos más resistentes. No funciona. No puede funcionar del todo. El NCSC británico lo formuló con precisión en diciembre de 2025: dado que los LLM no distinguen entre instrucciones y datos —solo predicen el siguiente token más probable— «es muy posible que los ataques de prompt injection nunca lleguen a mitigarse del todo como pueden mitigarse los de SQL injection». Los modelos son, en ese sentido, inherentemente confundibles.
Pero hay algo más fundamental que la industria sigue eludiendo: el prompt injection no es principalmente un fallo del modelo. Es un fallo del modelo de control de acceso.
Cuando el agente hereda confianza que no se ha ganado
En la seguridad tradicional, nadie concede acceso root permanente a un script sin nombre ni lo autentica con las mismas credenciales que un administrador de sistemas. Con los agentes IA, eso ocurre a diario y casi sin conciencia de que ocurre.
La mayoría de implementaciones actuales funcionan con cuentas de servicio compartidas, tokens de larga duración o credenciales con alcance amplio que la infraestructura ya confía. El agente no tiene identidad propia: hereda la de otro. Y al heredarla, hereda también todos sus permisos. Cuando un prompt injection consigue manipular la decisión del agente, esa decisión se ejecuta con credenciales válidas. Es una instrucción maliciosa empaquetada en una solicitud legítima. El SIEM no alerta. El WAF no bloquea. Todo parece dentro de lo normal, porque técnicamente lo está.
Darle al agente su propia identidad cambia el modelo completo. En lugar de heredar acceso general, el agente se autentica como una entidad específica con controles explícitamente definidos para su rol y su contexto. Como explica el Cloud Security Alliance en su análisis sobre gestión de identidad en sistemas agénticos, esto permite vincular cada token de autenticación a tareas concretas, con metadatos sobre el sistema que solicita, el propósito y las operaciones permitidas —lo que simplifica el análisis forense y crea trazabilidad directa entre permisos y propósito de negocio.
El problema de los tokens de larga duración tiene una cara adicional que suele ignorarse: a diferencia de las cuentas humanas, los agentes rara vez disparan anomalías de comportamiento, porque sus patrones de actividad son inherentemente variables. Un agente que de repente accede a un repositorio que no debería tocar puede pasar inadvertido si lo hace a velocidad de máquina y dentro de una cadena de herramientas que ya era compleja. La detección comportamental diseñada para humanos no tiene suficiente señal para actuar.
La pregunta correcta no es qué, sino cuándo
El cambio de paradigma que la industria necesita no es defensivo en el sentido convencional —no se trata de bloquear el input malicioso, que es técnicamente inviable en sistemas de lenguaje natural. Se trata de invalidar su impacto en el punto donde realmente importa: cuando el agente solicita acceso.
1Password lo articula bien en su análisis sobre controles de ejecución: el prompt injection no elude los controles de acceso, trabaja dentro de ellos. El agente tiene permiso. El sistema funciona como fue diseñado. El resultado es igualmente incorrecto. Cuando un agente invoca una herramienta, se autentica ante un servicio o intenta realizar una operación, ese momento necesita ser evaluado. La decisión de acceso no puede tomarse una vez al inicio de la sesión y asumirse válida para todo lo que venga después.
Silverfort plantea la distinción con claridad: el privilegio mínimo estático asume comportamiento predecible, y los agentes rompen esa asunción. Razonan. Encadenan herramientas. Derivan de su propósito original. El privilegio mínimo tiene que validarse en tiempo de ejecución, no solo fijarse en el aprovisionamiento. Si un agente intenta acceder a un recurso fuera de su alcance declarado, se bloquea. Aquí es donde la identidad agéntica —credenciales efímeras, permisos de mínimo privilegio escalonados por contexto, autorización dinámica evaluada contra políticas explícitas— cobra sentido práctico. Incluso si el prompt manipulado logra que el agente «intente» algo, el sistema de control de acceso puede rechazarlo si está fuera del alcance autorizado. El ataque falla no porque el modelo lo detecte, sino porque la infraestructura no lo ejecuta.
Lo que el regulador ve y lo que aún no ve
En enero de 2026, el NIST publicó a través de su Centro para Estándares e Innovación en IA (CAISI) una solicitud de información sobre seguridad en sistemas agénticos, buscando perspectivas de la industria, la academia y la comunidad de seguridad sobre el despliegue seguro de estos sistemas. El documento reconoce que los agentes son susceptibles a ataques como el prompt injection indirecto y que sus vulnerabilidades pueden tener implicaciones para infraestructuras críticas.
Lo importante, sin embargo, es lo que el documento todavía no da: no propone taxonomías de riesgo para entornos donde el perímetro es semántico, no articula estándares de identidad agéntica, no define arquitecturas de confianza cero adaptadas a sistemas que toman decisiones en lenguaje natural. La respuesta regulatoria está, en el mejor de los casos, en fase de escucha activa. Mientras tanto, los agentes ya están desplegándose a escala empresarial con las mismas bases de confianza que se diseñaron para usuarios humanos.
Esta brecha no es solo un problema técnico. Es un problema de ritmo: la velocidad de adopción supera la capacidad de los marcos de gobernanza para adaptarse. Y las organizaciones que despliegan agentes sin repensar el control de acceso no están cometiendo un error de implementación puntual; están construyendo superficie de ataque sobre un modelo de identidad que nunca fue pensado para sistemas autónomos.
Lo que habría que reconstruir
El prompt injection seguirá siendo técnicamente posible mientras los modelos de lenguaje funcionen como funcionan. El NCSC tiene razón en eso. Pero la pregunta relevante no es si el ataque puede ejecutarse, sino si puede producir efectos en sistemas reales. Y eso depende casi por completo de cómo se gestione la identidad y la autorización del agente.
Identidad única por agente, no credenciales compartidas. Autorización evaluada en tiempo de ejecución, no asumida desde el aprovisionamiento. Credenciales efímeras que expiran con la tarea. Trazabilidad de cada acción hasta el dato que influyó en ella y la política que debería haberla contenido. No es una lista de buenas prácticas de seguridad genéricas: es la condición necesaria para que la defensa tenga alguna posibilidad de funcionar en entornos donde la superficie de ataque es el lenguaje natural.
El prompt injection manipulado que no puede producir acción sobre infraestructura real es, en términos prácticos, ruido. Llegar ahí requiere repensar el control de acceso desde cero para sistemas no humanos, no entrenar mejores modelos ni añadir capas de sanitización al input.