Google ADK y agentes de IA zero trust: seguridad para automatizar mejor

Resumen rápido

La nueva publicación de Google Developers sobre Agent Development Kit merece atención porque trata a los agentes de IA como software de producción. El ejemplo de un agente de soporte y reembolsos muestra tres ideas centrales: las acciones sensibles deben firmarse, el código no confiable debe ejecutarse en sandbox y las entradas y salidas necesitan reglas que puedan probarse. Para los equipos que evalúan herramientas de IA, el mensaje es claro: la calidad del modelo no basta si la plataforma no ofrece identidad verificable, ejecución limitada, auditoría y controles resistentes a prompt injection.

Por qué este cambio importa

Los agentes de IA ya no viven solo en demos. Están entrando en atención al cliente, IDEs, paneles internos, operaciones y flujos financieros. Un asistente que redacta una respuesta puede ser revisado por una persona; un agente que aprueba un reembolso, modifica un archivo, llama una API privada o responde con datos de cliente necesita un modelo de seguridad real. La guía de Google en https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/ convierte la seguridad de agentes en un diseño concreto.

Zero trust significa no confiar en una frontera única. Un prompt de sistema ayuda, pero una instrucción maliciosa puede llegar en un ticket, documento, página web, nombre de archivo o salida de herramienta. El modelo puede razonar, pero la plataforma debe imponer límites cuando hay dinero, datos, identidad o código en juego.

Patrones de arquitectura recomendables

El primer patrón es separar intención y autoridad. El agente puede concluir que un reembolso tiene sentido, pero la escritura final debe ir firmada por una identidad específica y ser verificada por el servicio receptor. Así se puede saber qué agente actuó, qué flujo generó la solicitud y si el mensaje fue alterado.

El segundo patrón es el aislamiento. Los agentes suelen ejecutar fragmentos, transformar archivos o invocar herramientas. Eso no debe dar permisos amplios sobre el host. Un sandbox reduce el radio de daño si el código generado falla o si una entrada externa intenta manipular el flujo.

El tercer patrón es una barrera semántica. No basta revisar dominios o extensiones. La política debe entender si un reembolso supera un límite, si una respuesta revela datos privados, si un comando es destructivo o si una herramienta se usa fuera de la petición del usuario. Estas reglas deben probarse en CI, no esconderse en una frase del prompt.

Cómo cambia la selección de software

Cuando compares asistentes de programación o automatización en https://www.bttc.site/software, incluye pruebas de seguridad en la evaluación. Busca identidades de servicio separadas, credenciales con alcance, aprobación humana, ejecución aislada, registros de auditoría, políticas exportables y documentación clara. Una demo atractiva no compensa una herramienta que ejecuta todo con el mismo token personal.

Los equipos pequeños también pueden aplicar el enfoque. Define a qué repositorios, cuentas de nube, documentos y sistemas de pago puede acceder el agente. Mantén las acciones de alto riesgo bajo revisión humana. Conserva registros de decisiones y llamadas a herramientas. Consulta más análisis en https://www.bttc.site/blog al seguir la evolución de las herramientas de IA.

Lista práctica para equipos

Empieza con un inventario de acciones. Enumera si el agente puede leer documentos, buscar código, crear tickets, modificar archivos, ejecutar comandos, enviar mensajes, aprobar pagos o llamar APIs. Clasifica cada acción por reversibilidad e impacto. Leer una FAQ pública es bajo riesgo; cambiar facturación, autenticación, configuración de producción o datos de clientes requiere controles fuertes.

Después, asigna identidades estrechas y credenciales temporales. No permitas que todos los flujos usen el token personal de un desarrollador. Limita red, archivos, memoria y tiempo. Por último, crea casos de regresión con prompt injection, solicitudes de datos sensibles y comandos destructivos. La meta no es que el modelo sea perfecto, sino que el comportamiento peligroso falle de forma segura.

Preguntas frecuentes

¿Basta con un buen prompt de sistema?

No. Un prompt orienta al modelo, pero no es una barrera de seguridad. Las acciones sensibles necesitan credenciales con alcance, firmas, sandbox, aprobaciones y auditoría.

¿Qué deben copiar los equipos de Google?

La separación entre razonamiento y autoridad. El agente puede proponer, pero los servicios y las políticas deben decidir qué puede ejecutarse.

¿Cómo ayuda esto al comprar software?

Convierte la seguridad de agentes en una lista comprobable: identidad, logs, permisos, ejecución segura y pruebas de políticas.

Conclusión

Los agentes de IA zero trust no frenan la automatización; la hacen apta para trabajo real. La guía de Google ADK es valiosa porque transforma la seguridad en ingeniería verificable: firmar escrituras, aislar ejecución, filtrar entradas y salidas, y elegir herramientas que demuestren sus controles.