Google Agent Sandbox

Executive Summary

Google Agent Sandbox is the managed execution environment inside the Gemini Enterprise Agent Platform — the platform Google announced on April 22, 2026 as the evolution of Vertex AI, consolidating model selection, agent building, and agent operations under one roof.^[1] The sandbox is the platform's answer to the category's core question: where does model-generated code actually run? Each sandbox is isolated from other sandboxes and the host system, operations inside it are restricted, and harmful commands are contained — so an agent can write and execute code, manage files, and drive a browser for computer-use tasks without touching anything it shouldn't.^[2] Sandboxes are created and execute code in under a second, maintain execution state for a configurable TTL of up to 14 days, and support file input and output up to 100MB per request or response.^[3]

The caveats are equally concrete. Code Execution is in Preview under Google's Pre-GA Offerings Terms, is supported only in the us-central1 region, allows no network access from inside the sandbox, and does not permit custom library installation.^[3] There is also a naming trap: Google separately ships an open-source, Kubernetes-native "Agent Sandbox" — a kubernetes-sigs project with a Sandbox CRD for isolated, stateful agent workloads — that shares the name and the company but nothing else.^[4] This profile centers on the managed Gemini Enterprise offering and treats the OSS project as a distinct sibling.

---

Product Overview

Agent Sandbox sits in the "Scale" pillar of the Gemini Enterprise Agent Platform, alongside Agent Runtime (sub-second cold starts), Agent Memory Bank, and multi-day workflow support.^[1] An agent — built with any framework and any generative model, with no Agent Platform deployment required — calls the sandbox API to create an isolated execution space, run model-generated code with state maintained across calls, and read or write files up to the 100MB request/response limit.^[3]

Key Capabilities

Name Collision: Two Google "Agent Sandboxes"

---

Technical Architecture

The platform documentation distinguishes the agent's runtime from its sandboxes: a sandbox is an "auxiliary environment spawned by the agent or the platform," typically short-lived or session-based, holding state only for the duration of a task or session (extendable to the 14-day TTL for Code Execution).^[2][3] Security rests on three mechanisms — isolation from other sandboxes and the host, restricted in-sandbox operations, and containment of harmful commands — so model-generated code cannot reach credentials or tenant data.^[2] The Python environment ships 150+ packages but is sealed: limited file system, no network access, no custom installs.^[3]

Key Technical Details

---

Strengths

• Sub-second sandbox lifecycle — sandboxes are created and execute code in under a second, matching the latency bar set by E2B and AgentCore rather than the multi-second container spin-ups of generic infrastructure.^[3]
• 14-day stateful persistence — execution state (memory) survives across calls for a configurable TTL up to 14 days, supporting the platform's multi-day agent workflows; most competitors measure session persistence in hours.^[3][1]
• Code execution and computer use in one primitive — the same sandbox family covers model-generated code and browser-based automation, where most rivals sell those as separate products.^[2]
• Framework- and model-agnostic entry point — usable with any agent framework and any generative model, with no requirement to deploy to Agent Platform first, making it a low-commitment on-ramp.^[3]
• Platform-scale security context — sits inside a governance stack (Agent Identity, Model Armor, anomaly and threat detection) processing 6+ trillion tokens monthly through ADK on Gemini models.^[1]

---

Cautions

• Preview-only, single-region — Pre-GA Offerings Terms apply, and Code Execution runs only in us-central1; data-residency and EU-sovereignty buyers are excluded for now.^[3]
• Sealed runtime — no network access from inside the sandbox, limited file system, and no custom library installation; the 150+ pre-installed packages are the ceiling unless you adopt BYOC sandboxes.^[3][2]
• Snapshots don't cover Code Execution — the snapshot save/restore capability advertised for sandboxes is unsupported for Code Execution sandboxes specifically.^[3]
• Naming confusion is real — Google itself uses "Agent Sandbox" for both this managed feature and the open-source Kubernetes project, and HN threads about the Vertex AI rebrand show buyers already struggling to track the portfolio.^[4][6]
• Pricing opacity during Preview — costs are folded into Agent Runtime's vCPU-hour/GiB-hour metering with standard billing starting July 1, 2026; there is no published per-sandbox price to compare against E2B or Daytona today.^[7]
• Platform gravity — the sandbox is most valuable inside the full Gemini Enterprise Agent Platform, and Google says all Vertex AI services will be delivered exclusively through Agent Platform going forward — adopting the primitive pulls you toward the whole stack.^[1]

---

What Developers Say

Sandbox-specific community discussion is thin as of June 2026 — the launch threads on Hacker News drew single-digit comment counts, and sentiment attaches to the parent platform and the Vertex AI rebrand rather than the sandbox itself.^[8]

"Google is such a confusing mess. They have every reason to win in AI." — an HN commenter, on the Vertex AI–to–Agent Platform rebrand^[6]

"The word agent is used 142 times in this single blog post, They are going overboard." — an HN commenter, on the launch announcement^[8]

"Looks more like hype than anything useful." — an HN commenter replying in the same thread^[8]

"Making sandboxed execution first-class rather than an afterthought is the right architectural call." — developer SK Firdous Ali, in a DEV Community first look^[9]

"But it's a 1.0. Ambitious, coherent, and not quite finished." — the same reviewer's overall verdict^[9]

The split is consistent: hands-on reviewers credit the security architecture while flagging that "pricing transparency is lacking," and drive-by HN sentiment reads the platform as branding churn.^[9][6]

---

Pricing & Licensing

Licensing model: Proprietary managed service under Google Cloud terms; Preview features carry Pre-GA Offerings Terms with no SLA.^[3] The separate kubernetes-sigs project is Apache-2.0.^[4]

Hidden costs: Model token usage (Gemini or third-party) billed separately, Agent Runtime compute for the calling agent, and the operational cost of being pinned to us-central1 — cross-region egress and latency for everything else in your stack.^[7][3]

---

Competitive Positioning

Direct Competitors

When to Choose Google Agent Sandbox Over Alternatives

• Choose Google Agent Sandbox when: you are already building on Gemini Enterprise Agent Platform or ADK, want code execution plus computer use as one managed primitive, and can live with us-central1 and Preview terms.
• Choose E2B or Daytona when: you need open source, multi-region or self-hosted deployment, custom packages, or network access from inside the sandbox.
• Choose AWS AgentCore Code Interpreter when: your agent stack lives on AWS and Bedrock.
• Choose kubernetes-sigs/agent-sandbox when: you run GKE or any Kubernetes cluster and want Google's isolation patterns without the managed platform.^[5]

---

Ideal Customer Profile

Best fit:

• Enterprises already committed to Google Cloud and the Gemini Enterprise Agent Platform (the Comcast/PayPal/L'Oréal cohort the launch showcased)^[1]
• Teams whose agents need long-lived state — the 14-day TTL fits multi-day analysis and workflow agents^[3]
• Data-science-heavy agent workloads served by the 150+ pre-installed Python packages^[3]
• Security-led buyers who want sandboxing, identity, and threat detection from one vendor^[1]

Poor fit:

• Anyone with data residency requirements outside us-central1^[3]
• Workloads needing in-sandbox network access, custom dependencies, or pip installs^[3]
• Multi-cloud or vendor-neutral architectures (use E2B or Daytona)
• Production systems that cannot accept Pre-GA terms without an SLA^[3]

---

Viability Assessment

The honest framing: this is a Preview feature of a two-month-old platform from a company with infinite resources and a documented habit of renaming and reshuffling its AI portfolio — HN's reaction to the Vertex rebrand was confusion, not excitement.^[6] But the platform's stated role as the exclusive delivery vehicle for former Vertex AI services makes abandonment unlikely; single-region Preview status is the real near-term risk.^[1][3]

---

Bottom Line

Google Agent Sandbox is a credible, specs-competitive managed sandbox — sub-second creation, 14-day stateful persistence, 100MB file I/O, and computer use in the same primitive — wrapped in the most restrictive availability terms in the category: Preview, us-central1 only, no network access, no custom packages.^[3] It is a feature of a platform, not a standalone product, and its value scales with how much of the Gemini Enterprise Agent Platform you adopt. The duplicate "Agent Sandbox" name on Google's own OSS Kubernetes project is an unforced branding error buyers must navigate.^[4]

Recommended for: GCP-committed enterprises building on ADK or Agent Platform that want managed, stateful code execution and browser automation without operating sandbox infrastructure.

Not recommended for: Multi-region or data-residency-bound deployments, workloads needing custom dependencies or sandbox network access, and teams unwilling to build on Pre-GA terms.

Outlook: Expect GA, more regions, and concrete per-unit pricing around the July 1, 2026 billing start; until then E2B, Daytona, and AgentCore remain the safer production defaults while Google's offering matures inside its platform.^[7]

---

Research by Ry Walker Research • methodology