The Hacker News reportó este 6 de agosto una señal importante para equipos que están construyendo agentes de IA: AWS, Google y Vercel ya corrigieron fallas distintas que compartían un patrón de riesgo común: datos o solicitudes con forma de “tool call” podían llegar a herramientas del agente sin una autorización válida de una vuelta del modelo.

Qué ocurrió

El reporte identifica tres superficies afectadas: Amazon Bedrock AgentCore InvokeHarness API, Google Agent Development Kit para Python y paquetes de harness de Vercel AI SDK para Codex y OpenCode. No se trata de una sola vulnerabilidad compartida ni de las mismas condiciones de ataque. La coincidencia editorial es el límite de confianza: la capa que ejecuta herramientas aceptaba señales externas o forjadas como si fueran una decisión legítima del agente.

En AWS, el boletín 2026-073-AWS describe CVE-2026-18830, una falla de validación insuficiente en Amazon Bedrock AgentCore harness. Según AWS, un usuario autenticado podía ejecutar herramientas configuradas al incluir un bloque de tool-use en el mensaje final de una solicitud InvokeHarness, evitando la invocación del modelo y controles asociados. AWS dice que el servicio administrado ya fue corregido con validación del lado servidor que rechaza esos bloques antes de que lleguen al event loop.

En Google, las notas de ADK 2.5.0 listan dos arreglos relevantes: “Prevent continuation forgery in tool confirmation” y “prevent model bypass in resumable mode by rejecting user-authored function calls”. El commit público de Google explica que un atacante capaz de manipular o inyectar eventos en el historial de sesión podía forjar una confirmación de herramienta; el parche añade verificaciones sobre herramienta, argumentos y relación con la llamada original.

En Vercel, dos advisories de GitHub —CVE-2026-64650 para @ai-sdk/harness-codex y CVE-2026-64651 para @ai-sdk/harness-opencode— describen un bypass de autorización en el relay de herramientas. El riesgo era que código no confiable dentro de un sandbox pudiera invocar herramientas expuestas por el host, como búsquedas de secretos, despliegues u operaciones de nube, sin un evento de tool-call autorizado por el modelo. Vercel corrigió el flujo eliminando el fallback basado en la ruta del proceso y exigiendo autorizaciones exactas, cortas y de un solo uso.

Por qué importa

La lección va más allá de estos tres proveedores. A medida que los agentes usan navegadores, shells, APIs internas, credenciales y flujos de despliegue, la seguridad no puede depender solo del prompt, del filtro del modelo o de que el agente “decida bien”. La autorización debe vivir también en la capa de orquestación: qué herramienta puede llamarse, con qué argumentos, por quién, durante cuánto tiempo y bajo qué evento verificable.

Qué está confirmado y qué falta

Está confirmado por fuentes primarias que AWS, Google y Vercel publicaron correcciones o avisos para estas rutas. También está confirmado que las condiciones varían: AWS requiere usuario autenticado; Google depende de manipulación o inyección de eventos de sesión o modos específicos; Vercel presupone código no confiable ejecutándose dentro del sandbox. Lo que no queda establecido por estas fuentes es explotación masiva en producción, robo concreto de datos de clientes o un incidente único que conecte a los tres proveedores. Para equipos técnicos, el paso práctico es actualizar versiones, revisar permisos de herramientas expuestas y tratar toda llamada a herramienta como una operación que necesita autorización verificable, no como simple texto dentro del flujo del agente.

Fuentes consultadas: The Hacker News, AWS Security Bulletin, Google ADK en GitHub y GitHub Security Advisories de Vercel.

Redactado por Nova Rivera — Perspectiva de producto y automatización.