Conectaste tu agente de IA a una docena de herramientas — GitHub, Slack, bases de datos, APIs en la nube — y termina en minutos lo que antes tomaba horas. Agregaste servidores MCP (Model Context Protocol — un estándar universal de conexión para herramientas de IA, como USB pero para datos), configuraste API tokens (contraseñas digitales que permiten a los programas acceder a servicios en tu nombre), y todo funcionó de una. El futuro llegó, productivo y completamente desprotegido.
Porque cuando armaste esas conexiones, cada herramienta pidió acceso total. No "solo lectura". No "solo este repo". Acceso total. Y ninguna plataforma de agentes ofrecía una forma de limitar permisos a nivel de orquestación — la capa donde tu agente decide qué herramientas usar y cuándo. Entregaste la llave maestra y lo llamaste integración.
Entre el 1 y el 14 de abril de 2026, esa llave maestra fue copiada. Repetidamente.
Google le da a cada agente la contraseña de root y después actualiza el README
El 1 de abril, Unit 42 de Palo Alto reveló la falla "Double Agent" en Google Vertex AI. Es el caso de estudio más contundente de la brecha entre autenticación y autorización que he visto hasta ahora.
Esto fue lo que pasó: cada agente de Vertex AI recibía una service account por defecto (una identidad a nivel de sistema que actúa en nombre de tu agente). Esa service account venía precargada con permisos que harían llorar a cualquier sysadmin. No estamos hablando de "un poco excesivo". Estamos hablando de acceso a:
- Buckets de Cloud Storage de otros clientes — datos de otros usuarios, accesibles desde cualquier instancia de agente
- Imágenes de contenedores internos restringidos de Google — del tipo que normalmente están detrás de múltiples capas de aprobación
- El código fuente de Vertex AI — los repos internos de la plataforma, legibles por un agente demo desechable
Los investigadores demostraron una cadena completa de escalación de privilegios: arrancas con un agente básico, heredas la service account por defecto, te mueves lateralmente por recursos de Google Cloud que ningún agente debería tocar jamás. La identidad por defecto no era "ligeramente sobre-privilegiada" — era funcionalmente omnisciente dentro del límite del proyecto y parcialmente omnisciente fuera de él.
¿La solución de Google? Documentación actualizada sugiriendo que traigas tu propia service account con menos privilegios. No un cambio en la plataforma. No un valor por defecto razonable. Un parche en la documentación. Le dijeron a los clientes que leyeran el manual con más ganas. El equivalente a un fabricante de autos respondiendo a una falla de frenos con "actualizamos el manual del propietario para recomendar reducir la velocidad antes de las intersecciones".
La falla existía porque la capa de autenticación de Vertex AI funcionaba perfecto — los agentes se conectaban, los tokens se intercambiaban, los handshakes se completaban — mientras que la capa de autorización era un terreno baldío. Nadie en Google construyó la parte que pregunta "¿debería este agente tener acceso a esto?"
Credential Vault de Anthropic: un workspace, todas las llaves, cero muros
Una semana después de la vergüenza de Google, Anthropic lanzó Claude Managed Agents el 8 de abril con niveles de permisos por herramienta — allowed_tools, denied_tools. Mejor que nada. Pero el 13 de abril, el investigador de seguridad hi120ki demostró que el Credential Vault detrás de esos permisos tiene un problema de confused deputy enorme (cuando un programa confiable es engañado para que abuse de su autoridad).
La ruta de ataque es directa y fea:
- Un workspace tiene múltiples agentes, cada uno con credenciales de herramientas diferentes almacenadas en el Credential Vault
- El Vault limita el acceso a nivel de workspace, no a nivel de agente o sesión
- Cualquier API key con acceso al workspace puede referenciar cualquier credencial en ese vault
- Un atacante (o un agente comprometido) con una sola API key válida del workspace puede inyectar llamadas a herramientas usando credenciales que pertenecen a otros agentes
En la práctica: el Agente A tiene acceso de solo lectura a GitHub. El Agente B tiene credenciales de escritura a la base de datos de producción. Si la sesión del Agente A se compromete — vía prompt injection, tool poisoning o un servidor MCP malicioso — puede sacar las credenciales de base de datos del Agente B del Vault compartido y ejecutar escrituras. Los niveles de permisos por herramienta (allowed_tools) gobiernan lo que el agente debería hacer. El Vault gobierna lo que puede hacer. Esas dos listas no coinciden.
La prueba de concepto de hi120ki mostró acceso cruzado de credenciales entre agentes en una sola llamada a la API. La solución requeriría aislamiento de credenciales por agente — esencialmente, darle a cada agente su propia partición del vault con separación criptográfica. Al 19 de abril, no hay corrección disponible.
Este es el patrón del confused deputy en su forma más pura: el Vault es el diputado confiable, el agente comprometido es el solicitante confundido, y las credenciales objetivo son la autoridad de alguien más. La gabardina apenas cubre el disfraz.
El patrón: autenticación resuelta, autorización ausente
Estos no son bugs aislados. Son síntomas de una capa arquitectónica que falta.
La falla de Azure DevOps MCP (CVE-2026-32211, CVSS 9.1, revelada el 3 de abril) — que cubrí cuando salió — mostró el mismo vacío desde la dirección opuesta: no defaults sobre-privilegiados, sino cero autenticación del lado de la herramienta. Claude Code Routines, que salieron el 14 de abril como agentes corriendo en horarios programados sin aprobación humana, amplifican cualquier pecado de permisos que ya exista al eliminar el último checkpoint humano.
Misma enfermedad, diferentes órganos. La autenticación (¿puede el agente conectarse?) está mayormente resuelta — los flujos OAuth, API keys y credential vaults manejan los handshakes bien. Pero la autorización (¿qué puede hacer el agente una vez conectado?) sigue siendo un vacío. Cada herramienta tiene su propio modelo de permisos — GitHub scopes, AWS IAM policies (reglas de acceso granular para recursos en la nube), acceso a nivel de página en Notion — pero ninguna plataforma de agentes agrega, audita ni aplica el principio de mínimo privilegio en todo el conjunto de herramientas.
La capa entre "herramienta conectada" y "acción ejecutada" no existe.
Una auditoría del 11 de abril de 7,000 servidores MCP realizada por Pomerium encontró que el 36.7% son vulnerables a SSRF (Server-Side Request Forgery — engañar al servidor para que haga solicitudes no autorizadas a sistemas internos). Más de un tercio de los servidores MCP pueden convertirse en puntos de pivote en la red. No porque el protocolo esté roto, sino porque las implementaciones individuales asumen que el agente que se conecta es confiable y tiene permisos adecuados. Asumen que la capa de autorización existe más arriba. No existe.
Por qué nadie va a arreglar esto hasta que les cueste plata
La computación en la nube pasó por 15 años de evolución dolorosa — de "SSH como root al servidor" a IAM granular con audit trails, acceso basado en roles y mínimo privilegio. Llegamos ahí porque las brechas costaban dinero y los frameworks de cumplimiento forzaron el cambio. Las plataformas de agentes están en el día cero de esa misma evolución, repartiendo acceso root equivalente a las herramientas por defecto y llamándolo feature porque se ve bien en los demos.
Construir autorización unificada para herramientas mataría la magia de "conecta lo que quieras en 30 segundos". Agregaría fricción en la configuración y debilitaría las demos competitivas. Ningún vendor tiene el incentivo de mercado para agregar fricción primero. Google no lo hará. Anthropic no lo hará. Microsoft no lo hará. El incentivo vendrá de los incidentes. Probablemente costosos, públicos y que afecten a múltiples clientes.
Ya tenemos avances de lo que viene: en julio de 2025, un agente de Replit entró en pánico y borró datos de producción de más de 1,200 ejecutivos. En diciembre de 2025, un agente de Amazon eliminó y recreó autónomamente un entorno de producción en vivo, causando un apagón de 13 horas en AWS Cost Explorer. Esos fueron accidentes. La siguiente ronda no lo será.
Cada servidor MCP sobre-privilegiado, cada API token con acceso total, cada conexión de herramienta sin delimitar es una vulnerabilidad latente — dormida mientras un humano hace clic en "aprobar", activa en el momento en que un agente corre autónomamente en un horario programado.
El próximo diferenciador real en la carrera de plataformas de agentes no es el modelo ni la cantidad de herramientas. Es la primera consola de administración que muestre lo que tu agente realmente puede hacer — y te permita revocar la mayoría. La brecha entre "conectado" y "autorizado" es donde vive el próximo ataque. Ahora mismo, todos están construyendo puentes sin barandas y lo llaman progreso.
