Google AX Agent Orchestrator: Security vs LangGraph

Short answer: Compared on security, no AI agent or model orchestrator is safe by default. Google AX has the most security-shaped design (sandboxed tasks, an explicit network allowlist), but an independent review found its sample gateway allows every host on port 443 and its budget control is disabled, so for AX, LangGraph, CrewAI, Microsoft Agent Framework and the OpenAI Agents SDK you must verify egress rules, spend limits and audit trails yourself before production.

Last reviewed 4 November 2026. To test those controls, try the egress-containment lab, the tool-scope lab, the kill-switch drill and the harness attack-surface lab.

Google released AX — an open-source, Kubernetes-native runtime for running AI agent workloads in sandboxes, with an explicit network allowlist and checkpointing built in. It's the most deliberately security-shaped design among the major agent orchestrators available today. It also, per an independent review, ships a sample configuration with a wide-open network policy and an explicitly disabled budget control. Both things are true at once, and that combination is the actual story: a framework's stated design intent and its default configuration are not the same thing, and the gap between them is exactly where incidents happen.

This is a security-first comparison of five agent orchestrators — Google AX, LangGraph, CrewAI, Microsoft Agent Framework and the OpenAI Agents SDK — ranked on sandboxing, network egress control, cost guardrails, and maturity, not on raw feature count or how fast you can ship a demo.

What Google AX actually is

Per its own README, AX is built around four primitives:

• Task — runs untrusted agent code in an isolated sandbox with CPU and memory limits.
• Workspace — pre-configures the Git repos, MCP servers and skill packages an agent needs.
• Gateway — restricts an agent's outbound network traffic to an explicit allowlist.
• Model — manages LLM credentials and configuration.

It also ships ax suspend / ax resume for checkpointing long-running agents and ax ssh for debugging, configured declaratively via YAML manifests rather than imperative code, and runs on top of Google's separate Agent Substrate sandboxing layer. It's Apache 2.0 licensed and, notably, Kubernetes-only — there's no non-K8s deployment path.

The gap between design intent and default config

An independent security review by Wavect found two things worth knowing before anyone treats AX's primitives as security guarantees rather than security-shaped scaffolding:

• The documented Gateway example is wide open. Per the review, the sample configuration contains host: "*" on port 443 — broad HTTPS access to any host, not a production allowlist. An operator has to explicitly replace it with real destination restrictions; nothing about the default steers them there.
• Budget enforcement doesn't exist yet. The review reports that field 9 of TaskSpec — previously reserved for budget and approval-policy configuration — is explicitly described as removed for now. Usage statistics exist, but nothing in AX itself stops a runaway token bill. As the review puts it: a sandbox can contain an agent without containing its bill.

Neither finding makes AX unusual — it makes AX normal. Every framework in this comparison has some version of this gap between what its architecture is designed to enforce and what it actually enforces without additional configuration. AX is simply new enough, and specific enough in its claims, that the gap has already been documented in public.

The comparison

This table reflects public documentation and third-party reporting as of September 2026, not PlayCISO's own hands-on penetration testing of each framework. Treat it as a starting map for your own evaluation, not a substitute for it — see the checklist below.

Ranked, with the honest caveat

Ranking "security posture" across frameworks built for different deployment shapes is inherently approximate. This ranking weighs how much of the security-relevant work is designed into the framework by default versus left entirely to whoever deploys it — not raw capability, ease of use, or ecosystem size.

1. Google AX — the most security-shaped architecture of the five (sandboxed Task execution, an explicit Gateway allowlist, checkpointing), but it's days old at the time of writing, Kubernetes-only, and its own documented defaults and enforcement gaps (above) haven't yet been hardened by real production mileage.
2. OpenAI Agents SDK — reported native sandboxing and MCP support give it a stronger out-of-the-box security shape than the self-hosted application frameworks, at the cost of being built around OpenAI's own models and hosting.
3. Microsoft Agent Framework — the AutoGen/Semantic Kernel merger inherits Microsoft's enterprise identity and policy tooling when run on Azure, but execution isolation is still largely something the deploying team configures rather than something the framework enforces on its own.
4. LangGraph — the most mature and widely adopted of the five, MIT-licensed, with a large ecosystem — but it is explicit that you, not the library, own sandboxing any tool or code-execution step unless you integrate a separate sandbox provider.
5. CrewAI — MIT-licensed and fast to build with, but security is entirely the operator's responsibility by design, and public reporting describes it as still working toward formal compliance certifications rather than holding them.

What to actually check before any of these touch production

1. Does agent-executed code run in a real sandbox? Container or VM isolation with enforced resource limits — or your own process, trusting the model's output not to do anything it shouldn't?
2. Is network egress default-deny with an explicit allowlist, or default-allow? A framework advertising "sandboxing" can still leave the network wide open — verify the actual default, not the marketing description of the feature.
3. Is there an enforced spend ceiling, or only usage reporting after the fact? A dashboard that shows you the bill after it's been run up is not a guardrail.
4. Where do credentials and secrets live, and what can read them? An agent that can call tools usually needs API keys or service credentials in reach — map exactly what's reachable from a compromised or misbehaving task.
5. Is there an audit trail you can actually query mid-incident? "We log things" and "we can answer what this agent did in the last hour, right now, under pressure" are different capabilities.

None of the five frameworks compared here answer all five questions favorably by default. That's not a knock on any one of them specifically — it's the current state of a genuinely young category. Treat every orchestrator's security claims as a hypothesis to verify, not a control to trust.

PlayCISO is not affiliated with Google, LangChain, CrewAI, Microsoft, OpenAI or Wavect. This article is an independent comparison based on public documentation, project repositories and third-party reporting at the time of writing; framework capabilities and defaults change quickly in this category — verify directly before making a production decision.