Orquestador de agentes Google AX: seguridad frente a LangGraph y CrewAI

Google publicó AX, un runtime de código abierto y nativo de Kubernetes para ejecutar cargas de trabajo de agentes de IA en sandboxes, con una lista explícita de destinos de red permitidos y checkpointing integrados. Es el diseño más deliberadamente orientado a la seguridad entre los grandes orquestadores de agentes disponibles hoy. Y también, según una revisión independiente, viene con una configuración de ejemplo con una política de red totalmente abierta y un control de presupuesto desactivado explícitamente. Ambas cosas son ciertas a la vez, y esa combinación es la verdadera noticia: la intención de diseño declarada de un framework y su configuración por defecto no son lo mismo, y el hueco entre ambas es justo donde ocurren los incidentes.

Esta es una comparación centrada en la seguridad de cinco orquestadores de agentes (Google AX, LangGraph, CrewAI, Microsoft Agent Framework y el OpenAI Agents SDK), ordenados por sandbox, control de la salida de red, barreras de costo y madurez, no por número de funciones ni por lo rápido que puedes publicar una demo.

Qué es realmente Google AX

Según su propio README, AX se construye en torno a cuatro primitivas:

• Task: ejecuta código de agente no confiable en un sandbox aislado con límites de CPU y memoria.
• Workspace: preconfigura los repositorios Git, los servidores MCP y los paquetes de skills que necesita un agente.
• Gateway: restringe el tráfico de red saliente de un agente a una lista explícita de destinos permitidos.
• Model: gestiona las credenciales y la configuración del LLM.

También incluye ax suspend / ax resume para hacer checkpoints de agentes de larga duración y ax ssh para depurar, se configura de forma declarativa con manifiestos YAML en lugar de código imperativo y funciona sobre Agent Substrate, la capa de sandbox separada de Google. Tiene licencia Apache 2.0 y, de forma destacable, solo funciona sobre Kubernetes: no hay forma de desplegarlo fuera de K8s.

El hueco entre la intención de diseño y la configuración por defecto

Una revisión de seguridad independiente de Wavect encontró dos cosas que conviene saber antes de tratar las primitivas de AX como garantías de seguridad en lugar de como andamiaje con forma de seguridad:

• El ejemplo documentado del Gateway está totalmente abierto. Según la revisión, la configuración de ejemplo contiene host: "*" en el puerto 443: acceso HTTPS amplio a cualquier host, no una lista de producción. Un operador tiene que sustituirla explícitamente por restricciones de destino reales; nada en la configuración por defecto lo empuja a hacerlo.
• El control de presupuesto todavía no existe. La revisión indica que el campo 9 de TaskSpec, antes reservado para la configuración de presupuesto y de política de aprobación, figura explícitamente como eliminado por ahora. Hay estadísticas de uso, pero nada en el propio AX detiene una factura de tokens desbocada. Como dice la revisión: un sandbox puede contener a un agente sin contener su factura.

Ninguno de los dos hallazgos hace que AX sea inusual: lo hace normal. Todos los frameworks de esta comparación tienen alguna versión de este hueco entre lo que su arquitectura está diseñada para hacer cumplir y lo que realmente hace cumplir sin configuración adicional. AX simplemente es lo bastante nuevo, y lo bastante concreto en sus afirmaciones, como para que el hueco ya esté documentado en público.

La comparación

Esta tabla refleja la documentación pública y la cobertura de terceros a septiembre de 2026, no pruebas de penetración propias de PlayCISO sobre cada framework. Tómala como un mapa de partida para tu propia evaluación, no como un sustituto de ella: mira el checklist de abajo.

El ranking, con la salvedad honesta

Ordenar la «postura de seguridad» de frameworks pensados para formas de despliegue distintas es, por naturaleza, aproximado. Este ranking pondera cuánto del trabajo relevante para la seguridad está diseñado dentro del framework por defecto frente a cuánto se deja por completo en manos de quien lo despliega, no la capacidad bruta, la facilidad de uso ni el tamaño del ecosistema.

1. Google AX: la arquitectura más orientada a la seguridad de las cinco (ejecución de Task en sandbox, lista explícita de permitidos del Gateway, checkpointing), pero tiene días de vida al momento de escribir, solo funciona sobre Kubernetes y sus propios valores por defecto documentados y sus huecos de aplicación (arriba) aún no se han endurecido con kilometraje real en producción.
2. OpenAI Agents SDK: el sandbox nativo reportado y el soporte de MCP le dan una forma de seguridad más sólida de serie que los frameworks de aplicación autoalojados, a costa de estar construido en torno a los modelos y el alojamiento de la propia OpenAI.
3. Microsoft Agent Framework: la fusión de AutoGen y Semantic Kernel hereda las herramientas empresariales de identidad y políticas de Microsoft cuando se ejecuta en Azure, pero el aislamiento de la ejecución sigue siendo en gran medida algo que configura el equipo que despliega y no algo que el framework haga cumplir por sí solo.
4. LangGraph: el más maduro y adoptado de los cinco, con licencia MIT y un gran ecosistema, pero deja claro que eres tú, y no la biblioteca, quien se encarga del sandbox de cualquier paso de herramientas o ejecución de código, salvo que integres un proveedor de sandbox aparte.
5. CrewAI: con licencia MIT y rápido para construir, pero la seguridad es por diseño responsabilidad exclusiva del operador, y la cobertura pública lo describe como todavía en camino hacia certificaciones formales de cumplimiento, no como poseedor de ellas.

Qué comprobar de verdad antes de que cualquiera de estos toque producción

1. ¿El código que ejecuta el agente corre en un sandbox real? ¿Aislamiento de contenedor o VM con límites de recursos aplicados, o tu propio proceso, confiando en que la salida del modelo no haga nada que no deba?
2. ¿La salida de red es de denegación por defecto con una lista explícita de permitidos, o de permiso por defecto? Un framework que anuncia «sandbox» puede dejar igualmente la red totalmente abierta: verifica el valor por defecto real, no la descripción de marketing de la función.
3. ¿Hay un tope de gasto que se aplique, o solo un reporte de uso a posteriori? Un panel que te muestra la factura después de que se haya disparado no es una barrera de protección.
4. ¿Dónde viven las credenciales y los secretos, y qué puede leerlos? Un agente que puede llamar a herramientas suele necesitar claves de API o credenciales de servicio a su alcance: mapea exactamente qué es alcanzable desde una tarea comprometida o que se comporta mal.
5. ¿Hay un registro de auditoría que puedas consultar de verdad en mitad de un incidente? «Registramos cosas» y «podemos responder ahora mismo, bajo presión, qué hizo este agente en la última hora» son capacidades distintas.

Ninguno de los cinco frameworks comparados responde favorablemente a las cinco preguntas por defecto. No es una crítica a ninguno en concreto: es el estado actual de una categoría realmente joven. Trata las afirmaciones de seguridad de cualquier orquestador como una hipótesis que verificar, no como un control en el que confiar.

PlayCISO no está afiliado a Google, LangChain, CrewAI, Microsoft, OpenAI ni Wavect. Este artículo es una comparación independiente basada en documentación pública, repositorios de los proyectos y cobertura de terceros al momento de escribir; las capacidades y los valores por defecto de los frameworks cambian rápido en esta categoría: verifícalos directamente antes de tomar una decisión de producción.