La seguridad en plataformas de agentes ha vuelto a ponerse en el foco. En un análisis presentado en Black Hat USA 2026, se detallan fallos de autorización en componentes de infraestructura vinculados a AWS, Google y Vercel. El problema común no es que el modelo sea “engañado”, sino que, en algunos recorridos, el sistema acepta instrucciones con forma de llamada a herramienta sin comprobar que el modelo realmente haya autorizado esa ejecución.
En varios escenarios, el modelo ni siquiera llega a ejecutarse. Eso significa que salvaguardas como prompts del sistema, filtros de contenido y reglas de control a nivel de modelo no tienen oportunidad de intervenir. A continuación, te explicamos qué falló, qué se corrigió en cada plataforma y qué lecciones prácticas puedes aplicar al integrar agentes.
El patrón: cuando una llamada de herramienta “salta” al modelo
En un flujo típico de agentes, la integración envía al modelo la solicitud del usuario, el prompt del sistema, el historial de conversación y la lista de herramientas disponibles. Luego, el modelo decide si debe llamar a una herramienta y devuelve una instrucción estructurada con el nombre y los argumentos. Finalmente, el SDK ejecuta esa instrucción en la capa de runtime.
Los investigadores señalan que en las rutas vulnerables no se verificaba la procedencia entre la instrucción devuelta por el modelo y el momento en el que el runtime despacha la llamada. Es decir: el runtime trataba como autorizada una estructura con apariencia de “tool call” sin confirmar que hubiese sido generada tras una vuelta (turn) legítima del modelo.
Por ese motivo, un atacante no necesariamente tiene que persuadir al modelo para romper reglas. Puede, en ciertos casos, llegar directamente a la parte que despacha o autoriza la herramienta sin existir una autorización real emitida por el modelo.
La “exposición” depende del acceso y de qué herramientas tiene el agente
Es importante matizar el impacto. La capacidad que un atacante puede obtener está acotada por lo que el propio agente ya puede hacer. Si el agente no está conectado a herramientas sensibles, el valor para un atacante disminuye: no hay ganancia si no existe un objetivo con permisos o capacidades relevantes.
Además, los caminos de ataque no son idénticos entre proveedores. AWS, Google y Vercel difieren en cómo se llega a la ejecución y qué condiciones deben cumplirse para que la llamada no autorizada alcance la herramienta.
Corrección en AWS: validación insuficiente en AgentCore
En AWS, el boletín de seguridad asigna la referencia CVE-2026-18830 (CVSS v4.0: 8.6) a un problema de validación de entrada en el harness de Amazon Bedrock AgentCore. Según se describe, un usuario remoto autenticado podía enviar un bloque de contenido para uso de herramientas dentro del mensaje final de una solicitud InvokeHarness.
En esa situación, el bucle de eventos podía despachar la herramienta nombrada directamente, sin preguntar al modelo. AWS indicó que el problema afectaba la API gestionada InvokeHarness hasta el 31 de julio de 2026 y aplicó una corrección del lado del servidor que rechaza esos bloques “tool-use” aportados por el solicitante antes de que lleguen al event loop.
La mitigación fue automática y, de acuerdo con la descripción pública, no requiere acción del cliente para la modalidad gestionada.
El matiz con Strands y el “atajo” de ejecución
Los investigadores también advierten que el arreglo de la modalidad gestionada no cubre una ruta similar dentro de código abierto de Strands (Python), en el que se basa el harness de AgentCore. En el repositorio, mencionan una rama que, si la última entrada contiene un bloque de ToolUse, provoca que el event loop establezca el motivo de parada como tool_use y tome el mensaje más reciente directamente, omitendo la ejecución del modelo.
Incluso indican que un comentario sobre esa rama sugiere precisamente saltar la invocación del modelo si el mensaje más reciente incluye ToolUse. También señalan la existencia de otra rama más estrecha que restaura un tool-use previamente almacenado antes de un “interrupt”, en lugar de usar cualquier contenido del último mensaje.
En la información citada, AWS no publica un CVE independiente ni un rango de versiones y parcheo específico para despliegues “standalone” de Strands; los autores señalan que, desde AWS, se respondió con un cambio de documentación más que con un fix de código para ese caso.
Correcciones en Google: ADK 2.5.0 y comprobaciones de confirmación
En Google, se reportan dos problemas relacionados en el Agent Development Kit (ADK) para Python. El primero figura como CVE-2026-18236 (CVSS v4.0: 9.3) y afecta versiones de ADK anteriores a 2.5.0.
El contexto: ADK permite marcar herramientas sensibles que requieren confirmación. Esa confirmación se mantiene hasta que una persona aprueba la acción. El fallo aparece cuando eventos en la sesión pueden ser manipulados o inyectados para simular esa aprobación, provocando la ejecución de una herramienta sin permiso legítimo.
La solución descrita en el parche agrega comprobaciones: verificar que la herramienta objetivo pertenece al agente que ejecuta, confirmar que realmente requiere confirmación y comprobar que nombre y argumentos coinciden con lo registrado en la sesión. Así, se reduce la posibilidad de que una confirmación falsificada habilite una tool call no autorizada.
Modo reanudable y llamadas desde eventos de usuario
El segundo conjunto de correcciones, también en ADK 2.5.0, aborda una ruta en resumable-mode. Los detalles indican que flujos reanudables aceptaban eventos originados por el usuario que contenían partes de function_call que podían interpretarse como instrucciones para ejecutar herramientas registradas, sin depender de una vuelta del LLM.
El parche actual rechaza function calls en mensajes autorizados por el usuario, evitando el bypass descrito. Los investigadores señalan que ambos hallazgos fueron reportados por ellos y que Google asignó CVE específicamente para un caso que afecta la configuración por defecto, mientras que el modo reanudable se considera una característica más reciente y no activada por defecto.
Corrección en Vercel: el relay confiaba en un “proceso” en la ruta
En Vercel, los problemas se centran en los paquetes del harness AI SDK para agentes de codificación: @ai-sdk/harness-codex y @ai-sdk/harness-opencode. Las referencias indicadas son CVE-2026-64650 y CVE-2026-64651 (CVSS v4.0: 6.3), con afectación en versiones específicas previas a los parches.
El mecanismo descrito como vulnerable: el relay confiaba en una verificación basada en la línea de comandos que contenía la ruta de un helper script aprobado. En el caso de OpenCode, mencionan host-tool-mcp.mjs; en el caso de Codex, un shim de comando asociado.
El problema es que código malicioso ya ejecutándose dentro del sandbox en Linux podía satisfacer esa condición y llegar a invocar herramientas expuestas por el host (incluidas búsquedas secretas, operaciones de despliegue o llamadas a APIs de nube), sin que exista el evento autorizado por el modelo.
Según se resume, la explotación requería: ejecución dentro de Linux, una sesión activa del harness con al menos una herramienta provista por el host y código no confiable ya corriendo en el sandbox (por ejemplo, una dependencia maliciosa, un script de build o un hook del ciclo de vida).
Qué cambiaron en el parche
Vercel eliminó el “fallback” basado en la ruta del proceso. En su lugar, el relay solo acepta solicitudes cuando coinciden con una autorización exacta y de un solo uso ligada al evento observado en el ciclo del modelo: herramienta, entrada y estado de autorización deben ajustarse.
Además, se menciona un fix previo en una pull request (fusionada el 10 de junio de 2026) que endurece rutas de “replay” de aprobaciones, con controles que evitan aprobaciones forjadas por el cliente. Más tarde, se explican estos controles como parte de las notas de lanzamiento en la versión 7 del AI SDK.
Lección clave: la protección debe estar en la capa de ejecución
Los autores remarcan una conclusión común: si una salvaguarda queda solo en prompts del sistema o en respuestas del modelo, se vuelve insuficiente cuando un atacante puede alcanzar directamente el camino de despacho sin una vuelta del modelo. En esos casos, no hay “probabilidad” a derrotar ni un modelo más fuerte que usar: simplemente no se llega a ejecutar.
Los tres remedios convergen en un mismo principio de diseño. En términos prácticos, la idea es que no vale con que el dato “tenga forma”; hay que comprobar que la ejecución corresponde a un evento del modelo y a un estado de autorización coherente con esa ejecución.
Qué puedes hacer tú: controles recomendados
Si estás construyendo o integrando agentes, estas recomendaciones sintetizan el enfoque que aparece en las correcciones descritas:
- Actualiza dependencias: ADK de Google a la versión 2.5.0 o posterior, y los packages de Vercel a versiones que incluyen los parches indicados en su registro; en el caso de AWS, asegúrate de que la modalidad gestionada aplicó la validación del lado del servidor.
- Trata como no confiable lo que cruza límites externos: historial de conversación, eventos de reanudación, respuestas de confirmación y bloques estructurados de “tool-use” deben considerarse entrada no confiable cuando atraviesan un boundary hacia el runtime.
- Autoriza en el momento exacto de ejecución: cada invocación de herramienta debe quedar vinculada a la combinación exacta de evento del modelo, nombre de la herramienta, argumentos y estado de autorización.
- Reduce la autoridad heredada: limita permisos, roles y credenciales al mínimo necesario, de modo que el agente solo tenga herramientas y capacidades imprescindibles para su tarea.
¿Se trata de prompt injection?
La descripción original lo aclara: esto no encaja como “prompt injection”. El problema no gira alrededor de persuadir a un modelo generativo, ni sobre cómo un sistema de filtros resiste entradas maliciosas. El denominador común es que el sistema permite llegar a la ejecución de herramientas sin una verificación adecuada que confirme una autorización basada en una vuelta del modelo.
Por ello, la respuesta correcta es de arquitectura y control de autorización: asegurar que la ejecución de herramientas solo ocurra cuando exista un evento del modelo que la respalde y cuando la capa de ejecución valide ese respaldo.
Conclusión
Las fallos de autorización descritas en AWS, Google y Vercel muestran un riesgo específico en infraestructuras de agentes: aceptar instrucciones con apariencia de llamadas a herramientas sin confirmar su procedencia. En algunos casos, el modelo ni siquiera se ejecuta, lo que vuelve irrelevantes controles que dependen de esa iteración.
La buena noticia es que las correcciones publicadas apuntan a un camino claro: validar origen y coherencia de confirmaciones, atar la autorización a eventos del modelo y aplicar verificaciones en la capa de ejecución. Si actualizas tus dependencias y endureces tus límites de confianza, reduces el riesgo de que una herramienta se ejecute sin permiso real.
Fuente: https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html
