)
Última actualización: 6 de noviembre, 2026
¿Cómo proteges los agentes creados con Google ADK en producción? Parchea primero el framework y activa después los controles que ofrece. El NVD registró seis vulnerabilidades de Google ADK en 2026, la última el 28 de octubre, y ADK Python ya va por la versión 2.13.0. Actualiza a la 2.7.0 o posterior y añade filtros de herramientas, aprobaciones e identidades acotadas.
TL;DR: puntos clave
- El NVD publicó 6 vulnerabilidades de ADK entre el 13 de abril y el 28 de octubre de 2026, con puntuaciones CVSS 4.0 de 5,3 a 10,0 (NVD, 2026).
- La peor, CVE-2026-79696, obtuvo 10,0 y permitía a un atacante sin autenticación ejecutar código a través de adk web en las versiones 2.0.0 a 2.6.0 (NVD, 2026).
- ADK Python 2.7.0, publicada el 13 de agosto de 2026, corrige 5 de los 6 CVE, y el de Java necesita la 1.13.0 (PyPI, 2026).
- ADK agrupa sus defensas en 5 capas: identidad, guardarraíles, código aislado, evaluación y trazabilidad, y controles de red (documentación de Google ADK, 2026).
- La confirmación de herramientas añade aprobación humana, pero 1 CVE permitía falsificar esas aprobaciones antes de ADK Python 2.5.0 (NVD, 2026).
- OWASP sitúa el Excessive Agency en tercer lugar de su lista LLM 2026, desde el sexto, porque el acceso a herramientas convierte una mala salida en una acción (nuestra guía del OWASP LLM Top 10 2026).
De un vistazo: las capas de seguridad en una tabla
Respuesta rápida
¿Es google adk lo bastante seguro para producción?
ADK puede funcionar en producción, pero la seguridad depende de tu nivel de parches y de tu configuración. El framework te da piezas: autenticación del agente o del usuario, callbacks, plugins, confirmación de herramientas, ejecución de código aislada y filtros de herramientas MCP. Tú sigues teniendo que parchear, mantener los servidores de desarrollo fuera de redes compartidas, acotar permisos y añadir controles en tiempo de ejecución alrededor de herramientas y datos.
| Capa | Qué aporta ADK | Qué te toca a ti |
|---|---|---|
| Parches | Versiones corregidas para cada CVE publicado | Actualizar las instancias locales y de producción |
| Identidad | Agent-auth con una cuenta de servicio o user auth con OAuth | IAM de mínimo privilegio y scopes OAuth estrechos |
| Guardarraíles | Callbacks, plugins, política dentro de la herramienta y filtros de Gemini | Políticas para cada llamada sensible a herramientas y modelos |
| Aprobación humana | Confirmación de herramientas, booleana o con payload estructurado | Qué herramientas requieren aprobación y quién aprueba |
| Ejecución de código | Ejecutores aislados y la opción de crear el tuyo | Sandboxes herméticos sin acceso a red |
| MCP | McpToolset con filtros, timeouts y parámetros de autenticación | En qué servidores confías y qué herramientas expones |
| Red | Despliegue dentro de perímetros de VPC Service Controls | Reglas de salida y límites a la exfiltración |
Cómo comparamos
El 6 de noviembre de 2026 leímos los registros del NVD de seis CVE de ADK, el historial de versiones de google-adk en PyPI y la documentación de ADK sobre seguridad, confirmación de herramientas, herramientas MCP y ADK 2.0. También leímos las Security Best Practices de MCP con fecha 2026-07-28, la especificación de A2A y las listas OWASP de 2026. No probamos ADK nosotros mismos.
Qué es Google ADK y dónde está el riesgo
Google ADK es un framework de código abierto para crear, depurar y desplegar agentes de IA. Según la documentación de Google ADK (2026), admite Python, TypeScript, Go, Java y Kotlin, y funciona con Gemini y con muchos otros modelos. El riesgo está allí donde un agente lee texto no fiable o llama a una herramienta.
ADK 2.0 alcanzó la disponibilidad general en Python el 19 de mayo de 2026, en Go el 30 de junio y en TypeScript el 21 de agosto. Añade flujos de trabajo basados en grafos, donde agentes, herramientas y funciones se ejecutan como nodos de un grafo. Eso ayuda a la seguridad, porque puedes fijar partes del camino en código. También añade más nodos, herramientas y estado que proteger.
La documentación es franca sobre el modelo de amenazas. Enumera las instrucciones vagas, las alucinaciones del modelo, los jailbreaks y las inyecciones de prompt de usuarios adversarios como fuentes de riesgo. También menciona la inyección indirecta de prompt a través del uso de herramientas. Nuestra guía de inyección indirecta de prompt explica por qué esa última vía es la más difícil de cerrar.
ADK agrupa los riesgos resultantes en desalineación y corrupción de objetivos, generación de contenido dañino y acciones inseguras. Las acciones inseguras incluyen comandos que dañan sistemas, compras no autorizadas, fugas de datos personales y exfiltración de datos.
)
Los CVE de ADK en 2026: qué parchear primero
Seis vulnerabilidades de ADK llegaron al NVD en 2026, entre el 13 de abril y el 28 de octubre, y cinco son altas o críticas. Tres fallos de Python no requieren autenticación. Actualiza ADK Python a la 2.7.0 o posterior y ADK Java a la 1.13.0, y vuelve a desplegar cada instancia afectada.
| CVE (NVD, 2026) | Componente y versiones afectadas | Impacto | CVSS 4.0 | Corregido en |
|---|---|---|---|---|
| CVE-2026-115522 | Python FileArtifactService, 1.19.0 antes de 1.39.1 y 2.0.0a1 antes de 2.7.0 | Apps que comparten directorio raíz leen, sobrescriben o borran los artefactos de las demás | 5,3 | 1.39.1, 2.7.0 |
| CVE-2026-107858 | Java ADK Web, google-adk-dev antes de 1.13.0 | Una página web maliciosa controla un agente local y lee sus datos | 7,2 | 1.13.0 |
| CVE-2026-79696 | Python adk web, 2.0.0 a 2.6.0 con pytest instalado | Ejecución de código sin autenticación mediante una repetición de sesión de prueba manipulada | 10,0 | 2.7.0 |
| CVE-2026-79707 | Python, endpoint builder, 1.9.0 a 1.21.0 | Lectura arbitraria de archivos sin autenticación | 8,7 | 1.22.0 |
| CVE-2026-18236 | Python, confirmaciones de herramientas, versiones anteriores a 2.5.0 | Confirmaciones falsificadas ejecutan herramientas no autorizadas | 9,3 | 2.5.0 |
| CVE-2026-4810 | Servidor ADK, 1.7.0 antes de 1.28.1 y 2.0.0a1 antes de 2.0.0a2 | Ejecución remota de código sin autenticación | 9,3 | 1.28.1, 2.0.0a2 |
Los dos registros más recientes son de finales de octubre. Según el NVD (2026), CVE-2026-115522 existe porque FileArtifactService aceptaba el nombre de la app, pero lo omitía en la ruta de disco. Dos aplicaciones que compartían directorio raíz e ID de usuario podían tocar los artefactos de la otra. La versión 2.6.0 corrigió las escrituras, pero mantuvo un respaldo heredado para lecturas y borrados.
CVE-2026-107858, publicado el 23 de octubre, afecta al servidor de desarrollo de Java. El NVD (2026) indica que el WebSocket /run_live aceptaba cualquier origen por defecto y que la API REST devolvía una cabecera CORS comodín. Una página visitada por el desarrollador podía, por tanto, manejar el agente local. Los datos SSVC de CISA en el NVD califican la explotación como prueba de concepto en ambos registros de octubre.
CVE-2026-79696 es el más grave. Necesitaba pytest instalado junto a adk web, algo habitual en equipos de desarrollo, y bastaba una repetición de sesión de prueba manipulada para ejecutar código sin credenciales. CVE-2026-4810 y CVE-2026-79707 son fallos más antiguos, sin autenticación, en el servidor y en el endpoint builder. El NVD añade que el primero exigía también volver a desplegar producción, no solo actualizar en local.
CVE-2026-18236 ataca una función de seguridad. El NVD (2026) detectó que ADK no comprobaba si la herramienta confirmada pertenecía al agente que ejecutaba ni si necesitaba confirmación. Tampoco contrastaba los argumentos de la confirmación con la llamada original. Un atacante que pudiera inyectar eventos en la sesión podía falsificar una aprobación.
De aquí salen tres lecciones. Las superficies de desarrollo, como adk web, el builder y ADK Web para Java, eran accesibles sin autenticación. Enlazar a localhost no basta, porque CVE-2026-107858 funciona a través del propio navegador del desarrollador. Y una sola actualización a ADK Python 2.7.0 o posterior cierra cinco de los seis registros.
Guardarraíles: callbacks, plugins y política en la herramienta
ADK ofrece tres lugares para imponer reglas a modelos y herramientas: en la herramienta, en un callback o en un plugin. Según la documentación de ADK (2026), los callbacks sirven para comprobaciones de un agente y los plugins para políticas compartidas. Los guardarraíles en la herramienta son los más deterministas, porque el modelo no puede cambiarlos.
Guardarraíles en la herramienta. Una herramienta recibe dos entradas: argumentos fijados por el modelo y un contexto de herramienta fijado por el desarrollador. El ejemplo de ADK es una herramienta de consultas que lee una política de ese contexto. La política solo permite sentencias SELECT sobre una lista fija de tablas. Escriba lo que escriba el modelo, la herramienta rechaza todo lo demás.
Callbacks previos a la herramienta. Cuando no puedes cambiar la herramienta, un before_tool_callback puede validar la llamada. Ve el estado del agente, la herramienta solicitada y sus argumentos. El ejemplo de ADK bloquea una llamada cuando el ID de usuario de los argumentos no coincide con el usuario de la sesión. La documentación avisa de que falla cuando los datos necesarios no están en los parámetros.
Plugins. ADK recomienda los plugins para políticas que se aplican a todos los agentes. Registras un plugin una vez a nivel del runner y cubre a todos los agentes que usan ese runner. La documentación describe tres ejemplos.
| Guardarraíl | Dónde se ejecuta | Mejor para | Limitación (documentación de ADK, 2026) |
|---|---|---|---|
| Política en la herramienta | Dentro del código de la herramienta | Límites duros, como consultas de solo lectura | Debes controlar el código de la herramienta |
| before_tool_callback | Antes de cada llamada a herramienta de un agente | Comprobar argumentos contra el estado de la sesión | Solo ve lo que hay en los parámetros |
| Plugin Gemini as a Judge | Entrada del usuario, entrada y salida de herramientas, salida del modelo | Detección de inyección de prompt y jailbreaks | Añade una llamada a un modelo en cada comprobación |
| Plugin Model Armor | Puntos elegidos de la ejecución del agente | Comprobaciones de seguridad de contenido mediante una API | Depende de un servicio de Google Cloud |
| Plugin de redacción de PII | Antes de las llamadas a herramientas | Eliminar datos personales antes de que la herramienta los vea | Limitado al paso previo a la herramienta |
| Filtros de seguridad de Gemini | Salida del modelo | Categorías de contenido dañino | Los filtros configurables vienen desactivados |
Esa última fila merece atención. La documentación de ADK dice que los filtros de contenido configurables de Gemini cubren cuatro categorías de daño y vienen desactivados por defecto. Los filtros no configurables siguen bloqueando cierto contenido, como material de abuso sexual infantil y datos personales. Si tu agente da servicio al público, fija esos umbrales a propósito.
Un modelo juez también requiere cuidado. Un segundo modelo que filtra las entradas puede ser objetivo de una inyección de prompt. Trátalo como una capa más y mantén comprobaciones deterministas para las acciones que mueven dinero, datos o código. Nuestra comparación de AI gateways y guardarraíles explica dónde encaja cada control.
Confirmación de herramientas y aprobación humana
La confirmación de herramientas permite que una herramienta de ADK se pause y espere a una persona o a un sistema supervisor antes de ejecutarse. Según la documentación de ADK (2026), puedes pedir un simple sí o no, o datos estructurados. Es la forma integrada de añadir aprobación humana a acciones de riesgo, como los pagos.
Confirmación booleana. En Python, Go y Java envuelves la herramienta con FunctionTool y activas require_confirmation. En Kotlin activas un indicador en la anotación de la herramienta. TypeScript necesita la lógica dentro de la función execute de la herramienta. También puedes pasar una función, de modo que solo los importes superiores a un umbral requieran aprobación.
Confirmación avanzada. La herramienta llama a request_confirmation con una pista y un payload. La pista explica la solicitud y el payload define la respuesta esperada. El ejemplo de ADK permite que un responsable apruebe menos días libres de los que pidió el empleado. La ejecución se pausa hasta que llega la respuesta.
Confirmación remota. Sin interfaz de usuario, una confirmación puede llegar a través del servidor API de ADK. Quien llama envía una respuesta de función llamada adk_request_confirmation con un ID coincidente. Eso convierte el canal de aprobación en parte de tu superficie de ataque.
| Necesidad de aprobación | Opción de ADK | Control de seguridad que añadir |
|---|---|---|
| Sí o no simple para una herramienta | require_confirmation en true | Registra quién aprobó y cuándo |
| Aprobación por encima de un umbral | Una función de confirmación en la herramienta | Fija el umbral en código, no en el prompt |
| Aprobación parcial con datos | request_confirmation con pista y payload | Valida el payload contra la llamada original |
| Aprobación desde correo o chat | Confirmación REST mediante el servidor API | Autentica el canal del aprobador |
Tres advertencias importan en producción. La documentación de ADK etiqueta la confirmación de herramientas como experimental y señala que DatabaseSessionService y VertexAiSessionService no la admiten. Comprueba tu servicio de sesiones antes de apoyarte en la confirmación como control.
La segunda advertencia es CVE-2026-18236. Antes de la corrección, una confirmación falsificada en el historial de la sesión podía aprobar una herramienta que el agente no tenía. Parchea primero y mantén las aprobaciones sensibles fuera de la sesión del propio agente siempre que puedas. Nuestra guía sobre excessive agency explica por qué la aprobación por sí sola no basta.
La tercera viene de las notas de migración de ADK 2.0. Un bloque except demasiado amplio dentro de una herramienta oculta los fallos al framework, y capturar BaseException atrapa la interrupción que pausa un flujo a la espera de una persona. Deja que las excepciones se propaguen, para que las pausas de aprobación sigan funcionando.
Cómo proteger toolsets MCP y agentes A2A en Google ADK
MCP y A2A conectan un agente de ADK con código y agentes que no escribiste, y forman la frontera de confianza más amplia. En ADK, McpToolset se conecta a servidores MCP por stdio, server-sent events o HTTP en streaming. A2A permite que los agentes de ADK llamen a agentes de otros frameworks o sean llamados por ellos.
Filtra las herramientas MCP. La lista de comprobación de resolución de problemas MCP de ADK dice que siempre indiques tool_filter en McpToolset. El filtro enumera las únicas herramientas que ve el modelo. Un servidor de sistema de archivos puede exponer muchas herramientas, pero un agente lector solo necesita list_directory y read_file.
Define timeouts y gestiona credenciales. La misma lista recomienda un timeout explícito en las conexiones stdio, por ejemplo de cinco segundos, para evitar subprocesos colgados. En los servidores remotos, McpToolset admite un auth_scheme y un auth_credential. Guarda esas credenciales en un gestor de secretos, no en el código del agente.
Sigue las reglas de MCP. Según las Security Best Practices de MCP (2026-07-28), los ataques de confused deputy, el token passthrough y el compromiso de servidores locales son riesgos clave. La guía indica que los servidores MCP no deben aceptar tokens que no se hayan emitido expresamente para ellos. También advierte de que los servidores locales inseguros pueden alcanzarse mediante DNS rebinding. Nuestra guía de inyección de prompt en MCP muestra cómo las descripciones y los resultados de las herramientas transportan instrucciones ocultas.
Trata a los agentes A2A como no fiables. Según la especificación del protocolo A2A (1.0.0), los agentes publican una Agent Card que describe sus capacidades y sus requisitos de autenticación. Una tarjeta te dice cómo conectarte, no si debes fiarte de la respuesta. Valida lo que devuelve un agente remoto, como harías con la salida de cualquier herramienta.
| Conexión | Control de ADK | Control extra que necesitas |
|---|---|---|
| Servidor MCP local por stdio | tool_filter y un timeout | Fija el paquete y la versión del servidor |
| Servidor MCP remoto por HTTP | tool_filter, auth_scheme y auth_credential | Tokens emitidos solo para ese servidor |
| Servidor MCP de terceros | tool_filter | Revisa las descripciones de las herramientas en busca de instrucciones ocultas |
| Agente A2A remoto | Datos de autenticación de la Agent Card | Validación de salidas y límites de bucles |
Las configuraciones multiagente traen sus propios modos de fallo. Los agentes pueden pasarse tareas de un lado a otro hasta agotar los presupuestos. Nuestro artículo sobre el bucle A2A explica cómo limitar esos intercambios.
Identidad, aislamiento y controles de red
La última defensa en ADK es lo que el agente puede alcanzar, no lo que decide. La documentación describe la identidad del agente, la ejecución de código aislada y los perímetros de red como límites gruesos pero deterministas. Funcionan sea cual sea la salida del modelo, así que son la capa base de cualquier agente en producción.
Agent-auth o user auth. Con agent-auth, la herramienta actúa como la cuenta de servicio del agente. La documentación de ADK señala que esto encaja con agentes cuyos usuarios comparten el mismo acceso. Con user auth, la herramienta usa el token OAuth del usuario, así que el agente solo puede hacer lo que podría hacer ese usuario. La documentación avisa de que los scopes de OAuth suelen ser más amplios de lo que el agente necesita.
Ejecución de código aislada. ADK trata la ejecución de código como una herramienta especial con riesgo añadido. Puedes usar ejecución aislada en el servidor o una extensión de intérprete de código. Si creas la tuya, la documentación recomienda entornos herméticos, sin conexiones de red y con una limpieza total de datos entre ejecuciones.
Perímetros de red. Ejecutar un agente dentro de un perímetro de VPC Service Controls mantiene las llamadas a API sobre recursos dentro de ese perímetro. La documentación de ADK llama controles gruesos a la identidad y a los perímetros. Los guardarraíles de herramientas cubren los huecos.
Escapa la salida en tu interfaz. ADK advierte de que la salida del modelo mostrada en un navegador debe escaparse. De lo contrario, una inyección indirecta de prompt podría colar una etiqueta de imagen que envíe el contenido de la sesión a otro sitio.
Seguridad y gobernanza: los controles del framework necesitan una capa en tiempo de ejecución
Los controles de ADK viven dentro del código de cada agente, así que la cobertura depende de que cada equipo acierte cada ajuste. Basta un filtro de herramientas olvidado, un adk web sin parchear o un canal de aprobación sin comprobar. Gobernar es verificar esos ajustes en todos los agentes y añadir controles independientes de cualquier base de código.
Las listas OWASP de 2026 ofrecen una forma de auditarlo. Según OWASP (2026), Excessive Agency es ahora LLM03, porque los agentes con herramientas ejecutan comandos y llaman a APIs sin control. El OWASP Top 10 for Agentic Applications 2026 añade ASI02 para el mal uso de herramientas y ASI03 para el abuso de identidad y privilegios. La tabla asigna los controles de ADK a esas entradas, como lectura nuestra y no como mapeo de OWASP.
| Control de ADK | Entrada OWASP 2026 que aborda |
|---|---|
| tool_filter y política en la herramienta | LLM03 Excessive Agency, ASI02 Tool Misuse and Exploitation |
| User auth y scopes OAuth estrechos | ASI03 Identity and Privilege Abuse |
| Confirmación de herramientas | LLM03 Excessive Agency (autonomía excesiva) |
| Sandboxes herméticos y servidores de desarrollo parcheados | ASI05 Unexpected Code Execution |
| Servidores MCP de confianza, paquetes fijados | ASI04 Agentic Supply Chain Vulnerabilities |
| Llamadas A2A autenticadas, validación de salidas | ASI07 Insecure Inter-Agent Communication |
Un equipo de seguridad sigue necesitando pruebas de que cada agente usa estos controles. Por eso muchos equipos añaden una gateway entre los agentes y las herramientas y modelos a los que llaman. Una gateway ve el tráfico de todos los frameworks, de modo que un agente de ADK con un callback débil no se convierte en la única línea de defensa. Nuestra guía del plano de control de seguridad de la IA agéntica explica el patrón.
NeuralTrust trata la seguridad de los agentes como un problema de tiempo de ejecución entre frameworks. Su Agent Gateway (TrustGate) es una sola gateway para modelos, servidores MCP y agentes A2A, con acceso a herramientas por usuario y un registro de auditoría de cada llamada. Ofrece más de 200 servidores MCP preconfigurados y se despliega como SaaS, en nube híbrida o en tus propias instalaciones. Forma parte del Runtime Security Mesh, junto a Agent Runtime Security (TrustGuard), Agent Posture Management (TrustLens) y AI Red Teaming (TrustTest).
¿Cuál deberías elegir?
Empieza por el control que cierre tu mayor exposición hoy. Si ejecutas una versión de ADK anterior a las correcciones de 2026, parchear va primero. Después, elige controles según lo que toquen tus agentes. El acceso a datos pide identidad y filtros, mientras que los pagos y las escrituras piden aprobación.
| Si tu agente... | Empieza por | Después añade |
|---|---|---|
| Ejecuta ADK Python anterior a 2.7.0 o ADK Java anterior a 1.13.0 | Actualizar y volver a desplegar copias locales y de producción | Mantener los servidores de desarrollo fuera de redes compartidas |
| Consulta bases de datos internas | Política en la herramienta con acceso de solo lectura | User auth con scopes estrechos |
| Mueve dinero o cambia registros | Confirmación de herramientas con umbral | Un canal de aprobación autenticado |
| Usa servidores MCP de terceros | tool_filter en cada McpToolset | Revisión de descripciones y tokens acotados |
| Habla con otros agentes por A2A | Validación de salidas | Límites de bucles y de presupuesto |
| Ejecuta código generado por el modelo | Un sandbox hermético | Bloqueo de la salida a red |
| Es uno de muchos agentes de varios equipos | Un plugin compartido en el runner | Una gateway delante de modelos y herramientas |
Conclusión
Google ADK te da piezas de seguridad reales, pero ninguna protege a un agente por defecto. Actualiza ADK Python a la 2.7.0 o posterior, pasa ADK Java a la 1.13.0 y mantén los servidores de desarrollo fuera de redes compartidas. Después añade política en la herramienta, callbacks o plugins y filtros de herramientas en cada toolset MCP. Usa la confirmación de herramientas para acciones de riesgo, acota las identidades y aísla el código generado. Por último, verifica estos ajustes en cada agente de google adk.
Asegura tus agentes de Google ADK en producción con NeuralTrust
Pon una Agent Gateway delante de cada modelo, servidor MCP y agente A2A que usen tus agentes de ADK, y conserva un registro de cada llamada.
)
Comparativas relacionadas
- OWASP Top 10 para aplicaciones LLM 2026
- Los mejores MCP gateways
- El plano de control de seguridad de la IA agéntica
- NeuralTrust frente a Google
Preguntas frecuentes sobre Google ADK
1. ¿Google ADK es de código abierto?
Sí. La documentación de ADK lo describe como un framework de desarrollo de agentes de código abierto. Está disponible en Python, TypeScript, Go, Java y Kotlin, y en Python se instala con pip install google-adk. Puedes ejecutarlo en tu propia infraestructura o desplegarlo en servicios de Google Cloud como Cloud Run y GKE.
2. ¿Google ADK está listo para producción?
Google posiciona ADK para agentes en producción, y ADK 2.0 alcanzó la disponibilidad general en Python el 19 de mayo de 2026. Que esté listo para tu caso depende de la configuración. Necesitas una versión parcheada, endpoints autenticados, identidades acotadas y guardarraíles en las herramientas sensibles. Algunas funciones, como la confirmación de herramientas, siguen marcadas como experimentales en la documentación.
3. ¿Qué vulnerabilidades de ADK debo parchear primero?
Empieza por CVE-2026-79696, que obtuvo 10,0 y permitía ejecutar código sin autenticación a través de adk web en las versiones 2.0.0 a 2.6.0. Después revisa CVE-2026-4810, CVE-2026-79707, CVE-2026-18236 y los dos registros de octubre. Actualizar ADK Python a la 2.7.0 o posterior cierra cinco de los seis, y ADK Java necesita la 1.13.0.
4. ¿Qué diferencia hay entre callbacks y plugins en ADK?
Los callbacks se asocian a un agente y sirven para comprobaciones propias de ese agente, como contrastar un ID de usuario. Los plugins se registran una vez a nivel del runner y se aplican a todos los agentes que lo usan. La documentación de ADK recomienda los plugins para políticas de seguridad que deben cubrir toda una aplicación.
5. ¿Cómo limito las herramientas MCP que puede usar un agente de ADK?
Pasa una lista tool_filter a McpToolset. La lista de comprobación MCP de ADK dice que siempre indiques una, para que el modelo solo vea las herramientas que necesita la tarea. Añade un timeout explícito para servidores stdio y guarda las credenciales remotas en un gestor de secretos. Revisa las descripciones de herramientas de terceros, porque pueden llevar instrucciones ocultas.
6. ¿ADK admite aprobación humana?
Sí, mediante la confirmación de herramientas. Una herramienta puede pedir una respuesta de sí o no, o un payload estructurado, antes de ejecutarse. La función es experimental y la documentación indica que no admite DatabaseSessionService ni VertexAiSessionService. Actualiza más allá de CVE-2026-18236, que permitía confirmaciones falsificadas, antes de depender de ella.
7. ¿Google ADK puede usar modelos distintos de Gemini?
Sí. La documentación de ADK dice que funciona con casi cualquier modelo de IA generativa y ofrece adaptadores para otros proveedores y modelos que se ejecutan en local. Los filtros de contenido integrados de Gemini solo se aplican a modelos Gemini. Si usas otro modelo, planifica tu propio filtrado de contenido con callbacks, plugins o una gateway.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
Consultadas el 6 de noviembre de 2026.
- Google, "Safety and Security for AI Agents", documentación de Agent Development Kit, consultada el 6 de noviembre de 2026.
- Google, "Get action confirmation for ADK Tools", documentación de Agent Development Kit, consultada el 6 de noviembre de 2026.
- Google, "MCP tools" y "Welcome to ADK 2.0", documentación de Agent Development Kit, consultadas el 6 de noviembre de 2026.
- NIST National Vulnerability Database, registros de CVE-2026-115522, CVE-2026-107858, CVE-2026-79696, CVE-2026-79707, CVE-2026-18236 y CVE-2026-4810, publicados entre el 13 de abril y el 28 de octubre de 2026.
- Python Package Index, historial de versiones de "google-adk", consultado el 6 de noviembre de 2026.
- Model Context Protocol, "Security Best Practices", versión 2026-07-28.
- A2A Project, "Agent2Agent (A2A) Protocol Specification", versión 1.0.0, consultada el 6 de noviembre de 2026.
- OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2026", agosto de 2026.
- OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications for 2026", 9 de diciembre de 2025.