AWS y SANS advierten hoy: los agentes de IA necesitan controles de acceso por defecto

Amazon Web Services (AWS) y el SANS Institute han lanzado hoy una advertencia a las empresas que ya están desplegando agentes de IA con capacidad para leer datos, consultar herramientas y ejecutar acciones: los controles de acceso tienen que venir activados de base. El motivo, dicen ambas organizaciones, es simple y serio a la vez: los prompts del sistema se están usando como si fueran una barrera de seguridad, cuando en realidad ofrecen más tranquilidad de la que merecen. El aviso llega en un punto incómodo para la adopción empresarial de estos agentes, con los equipos de seguridad corriendo detrás de despliegues que avanzan más deprisa que la gobernanza y que ya han dejado incidentes reales.

Lo que AWS y SANS quieren fijar desde el principio es esto: esas instrucciones no pueden tratarse como un control de seguridad. Son, como mucho, una guía de comportamiento, y un modelo puede ignorarla, entenderla mal o dejarla sin efecto si recibe entradas maliciosas.

Para Amazon Web Services y el SANS Institute, confiar en el prompt del sistema para frenar accesos indebidos es, directamente, un fallo de diseño.

Y llevado al terreno práctico, el problema se ve enseguida. Un atacante puede colar instrucciones manipuladas en documentos, correos, páginas web o incluso en respuestas devueltas por herramientas conectadas, y con eso empujar al agente a saltarse reglas internas.

La inyección de prompts sigue al frente de las amenazas para las aplicaciones basadas en modelos de lenguaje. OWASP la mantiene en la parte más alta de su lista de riesgos por una razón muy concreta: los modelos no distinguen siempre de forma fiable entre una instrucción legítima del sistema y contenido controlado por un tercero.

La consecuencia cae por su propio peso. Si un agente tiene acceso amplio a datos o puede ejecutar acciones, ni siquiera un prompt muy bien escrito asegura que vaya a mantenerse dentro de los límites previstos.

Por eso, la recomendación de Amazon Web Services y el SANS Institute va en otra dirección: bloquearlo todo de entrada y permitir solo capacidades concretas, aprobadas de antemano. Es un planteamiento muy cercano al zero trust, con permisos mínimos, limitados a una tarea específica y solo durante el tiempo estrictamente necesario.

AWS y SANS también insisten en otro punto que cambia bastante la conversación: los controles de verdad no deben vivir en el prompt, sino en la capa de datos y recuperación. La autorización, por tanto, tiene que aplicarse en tiempo de ejecución, de modo que el agente que actúa en nombre de un usuario tenga exactamente los mismos permisos que ese usuario, o incluso menos, pero nunca más.

La urgencia no sale de un supuesto abstracto. Un informe de 2026 señala que el número de agentes desplegados en organizaciones se duplicó en apenas cuatro meses y que el 38% de las empresas ya opera con más de 100 agentes.

El problema es que, según ese mismo informe, la monitorización no ha crecido al mismo ritmo. El resultado es bastante claro: muchos agentes siguen funcionando sin observación ni auditoría suficientes.

Ese informe de 2026 también deja una brecha difícil de pasar por alto entre la confianza declarada y lo que está ocurriendo en la práctica. Más del 80% de las organizaciones dice confiar en su capacidad para evitar accesos no autorizados a datos, pero casi 9 de cada 10 reconocieron al menos un incidente de seguridad relacionado con agentes durante el último año.

A eso se añade la actualización reciente de la guía de seguridad para LLM de OWASP, la iniciativa de estándares para agentes impulsada por el National Institute of Standards and Technology (NIST) y ataques ya documentados, entre ellos ofensivas contra la cadena de suministro de plugins e intrusiones en infraestructuras con múltiples agentes.

Nadie sabe cuándo la gobernanza y la visibilidad van a alcanzar el ritmo de despliegue. Pero para las empresas, a estas alturas, el mensaje ya cuesta discutirlo: si un agente puede tocar datos sensibles o ejecutar acciones críticas, la seguridad tiene que venir impuesta por la arquitectura, por los permisos y por controles que puedan verificarse.