El trío letal
El mejor marco mental para esto es de junio de 2025 y nombra tres ingredientes:
- acceso a tus datos privados,
- exposición a contenido no fiable,
- capacidad de comunicarse hacia fuera, de una forma que pueda sacar datos.
Dos cualesquiera son seguras. Las tres juntas, no.
De ahí sale también la traducción práctica del least privilege: no hace falta cerrarlo todo, basta con cortar una de las patas. Si el agent puede leer datos privados y ver contenido no fiable pero no puede llamar hacia fuera, no hay canal para la exfiltración. Si puede llamar hacia fuera y ve datos privados pero solo lee de fuentes fiables, no hay quien le dé instrucciones.
Diez casos documentados
No son riesgos teóricos. Todos son casos publicados y fechados.
| Fecha | Qué pasó |
|---|---|
| 2025-05 | Una instrucción escondida en código de proyecto público sacó los detalles de los cambios privados a través de una URL de imagen codificada |
| 2025-05 | Una instrucción escondida en una incidencia pública logró que el agent listara repositorios privados y publicara el dato en un envío público creado por él mismo |
| 2025-06 | Asistente de oficina, fuga de datos sin un solo clic con una sintaxis de marcado alternativa y un redirector permitido |
| 2025-08 | Inyección escondida en un ticket de soporte y camuflada con codificación → fuga de tokens de autenticación y de datos de código |
| 2025-09 | Sistema de ventas: una instrucción incrustada en los datos de cliente sacó la información por un dominio caducado pero permitido |
| 2025-10 | Texto escondido en una captura de pantalla, invisible al ojo humano → browser agents filtrando direcciones de correo |
| 2025-11 | Instrucción escondida en una página web → el agent subió claves de nube y fragmentos de código a un servicio de registro |
| 2026-01 | Asistente de correo: inyección en un mensaje no fiable → datos financieros, jurídicos y de salud a un formulario del atacante |
Y dos de 2026 que merecen mención aparte.
El primero es la historia de allowlist más instructiva que conozco. El tráfico saliente del agent estaba limitado con una lista de dominios, y bien. Solo que en la lista estaba la propia API del proveedor. Con una clave colocada en el prompt, el atacante hizo que los archivos se subieran al endpoint de subida del propio proveedor y luego se los descargó. El límite funcionaba; la vía de salida estaba en la lista de destinos considerados fiables.
El segundo: un agent de oficina envió correos sin aprobación, con imágenes externas, y la carga de la imagen era en sí misma el canal de fuga.
Qué tienen en común
Tres afirmaciones que conviene memorizar literalmente. Los investigadores de uno de los casos lo formularon así:
- «no es un fallo del código de ese servidor concreto, sino una cuestión arquitectónica de fondo que hay que tratar a nivel del sistema de agents»;
- «no es propio de un agent o de un cliente concreto: afecta a todo agent que use este servidor, con independencia del modelo y de la implementación»;
- «incluso los modelos más avanzados y alineados son vulnerables a estos ataques.»
O sea: esto no es un fallo de software que ya arreglarán, ni una cuestión de modelo que resolverá la siguiente versión. Es una propiedad de la arquitectura de agents, y el sitio donde se puede tratar son los permisos.
Hay también un patrón recurrente: casi siempre el dato salió por un canal «inofensivo», una URL de imagen, una redirección, un envío, un formulario. No una exportación de datos, sino algo que parecía legítimo.
¿Con cuántos permisos corren en realidad?
Aquí llegan las mediciones, y no son halagüeñas.
| Medición | Resultado |
|---|---|
| Estudio de 7.973 servidores remotos en activo (mayo de 2026) | el 40,55 % expone sus herramientas sin autenticación |
| El mismo estudio, 119 servidores testables que sí usan autenticación | encontraron fallos en todos, 325 en total |
| Análisis de 1.899 servidores de código abierto | 7,2 % de vulnerabilidad general, 5,5 % de envenenamiento de herramientas |
| 19.200 pares descripción-código de 2.214 servidores | 9,93 % inconsistentes: la descripción de la herramienta no describe lo que hace el código |
| Estudio en tiempo de ejecución de 64.611 servidores únicos | menos de la mitad de las alertas de los escáneres de seguridad son hallazgos reales |
El 9,93 % merece atención aparte. El agent decide qué llamar a partir de la descripción de la herramienta. Si una de cada diez descripciones no describe lo que hace el código, entonces una de cada diez decisiones del agent se apoya en información falsa, sin que nadie se haya equivocado a propósito.
Y el cuadro más amplio, sacado de la telemetría de nube: entre el 19 % y el 23 % de las máquinas virtuales corre con permisos excesivos, y buena parte de ellas puede hacerse con permisos de administrador completos. El 59 % de los usuarios de IAM tiene una clave de acceso de más de un año. (Esa encuesta no separa a los agents — pero este es el entorno en el que entran.)
El instrumental para estrechar permisos
La buena noticia: para esto hay documentación primaria, no hay que inventar nada.
Minimizar el alcance. La especificación del protocolo le dedica un apartado propio y enumera el precio de un permiso demasiado amplio: mayor radio de explosión si roban un token, revocación más difícil (revocar un token que lo sabe todo detiene todos los procesos), auditoría ruidosa (un permiso agregado tapa cuál era la intención del usuario), encadenamiento de permisos (el atacante puede llamar de inmediato a una herramienta de alto riesgo sin más elevación) y la renuncia al consentimiento: el usuario rechaza el diálogo si le piden demasiado.
El modelo propuesto es progresivo: permiso inicial mínimo (solo descubrimiento y lectura) y elevación puntual en el momento en que hace falta por primera vez.
Los errores típicos que menciona: publicar todos los permisos posibles; permisos con comodín o de tipo «lo sabe todo»; empaquetar juntos derechos que no van juntos para no tener que preguntar después.
Reenvío de tokens: prohibición absoluta. La especificación lo dice en forma imperativa: el servidor no puede aceptar un token que no se le haya emitido expresamente a él.
Límite de red. La especificación prescribe, a nivel recomendado, bloquear los rangos de IP privadas, y menciona entre ellos el endpoint de metadatos de la nube. Esa es la dirección desde la que un proceso comprometido puede pedir las credenciales del entorno de ejecución. Además: forzar HTTPS, validar los destinos de redirección, proxy de salida.
Sandboxing. En servidores locales: permisos mínimos por defecto, acceso restringido al sistema de archivos y a la red y, donde se pueda, un transporte al que solo llegue el cliente.
Y la lista sectorial de riesgos más reciente, que menciona como entrada propia el abuso de identidad y de permisos: «con las credenciales robadas pueden operar mucho más allá de su alcance previsto».
La receta
1. CORTA UNA DE LAS TRES PATAS
Datos privados / contenido no fiable / canal de
salida. Decide cuál quitas - no intentes controlar
las tres a la vez.
2. LEE LA ALLOWLIST TAMBIÉN AL REVÉS
La pregunta no es qué permites. Es a cuál de los
destinos permitidos se pueden SACAR datos.
Un endpoint de subida en la lista = puerta abierta.
3. EMPIEZA POR LECTURA, PIDE APARTE LA ESCRITURA
Permiso inicial mínimo, y elevación cuando haga
falta de verdad por primera vez.
4. NADA DE COMODINES EN LOS PERMISOS
El "acceso total" y el carácter comodín son justo
lo que la especificación cita como error típico.
5. BLOQUEA LA RED INTERNA
Sobre todo el endpoint de metadatos de la nube. Es
la dirección que más se olvida.
6. LA DESCRIPCIÓN DE UNA HERRAMIENTA NO ES DOC
Una de cada diez no describe lo que hace el código.
Mira el código de lo que conectas, no la ficha.
7. CREDENCIALES DE VIDA CORTA
Según la medición, en el 59 % de las cuentas humanas
la clave tiene más de un año. La del agent, que no.
El segundo punto es el más importante y el más fácil de estropear. Todo el mundo escribe la allowlist preguntándose «adónde tiene que ir el agent». La pregunta correcta es: «¿a cuál de los destinos de la lista se pueden subir datos?»
Malentendidos habituales
- «Es una vulnerabilidad, ya la arreglarán.» Según los investigadores no es un fallo del código de un producto, sino una cuestión arquitectónica que se trata a nivel del sistema de agents.
- «Un modelo mejor lo resuelve.» El hallazgo publicado dice que incluso los modelos más avanzados y alineados son vulnerables.
- «Tengo una allowlist.» Un servicio que está en la allowlist también puede ser canal de salida: exactamente lo que pasó en un caso de 2026.
- «El agent solo lee.» Mientras además lea contenido no fiable y tenga cualquier canal de salida, el trío está completo.
- «Por la descripción sé lo que hace la herramienta.» Según una medición sobre 19.200 pares, una de cada diez descripciones no coincide con el código.
- «Tenemos un escáner de seguridad.» Según un estudio sobre 64 mil servidores, menos de la mitad de las alertas son hallazgos reales.
Lo que conviene llevarse
En los agents, el least privilege no es cuestión de prudencia, sino el único punto manejable del riesgo, porque contra el prompt injectionno hay defensa técnica fiable y el avance de los modelos tampoco lo resuelve.
En una frase: lo que hay que decidir no es cuánto te fías del agent, sino hasta dónde llega si lo engañan.
Y una comprobación que cuesta cinco minutos: mira los destinos permitidos del tráfico saliente y pregúntate de cada uno si se pueden subir datos ahí. Si la respuesta es sí, esa es la tercera pata del trío, por muy fiable que sea el destino.
Dónde conviene poner la aprobación humana en la cadena lo mide con datos el post humano en el bucle , punto por punto; del estándar con el que se conectan las herramientas y de su cara de seguridad habla el post MCP en detalle. El caso más extremo es el agent personal que corre en tu propia máquina, donde las fronteras las levantas tú: de eso trata el artículo agentes autoalojados , de principio a fin.