Google’s Managed Shell Sandbox Is GA—But the Security Boundary Is Still Yours

Published September 13, 2026

Google has removed a meaningful infrastructure burden from teams that let AI agents execute commands. The product is officially named Gemini Enterprise Agent Platform, and its managed Shell sandbox became generally available on September 9, 2026. Google describes a managed, isolated Linux container with shell execution, private-connectivity controls, customer-managed encryption keys, and lifecycle APIs.

GA does not make the sandbox an authorization system, credential broker, output validator, or workflow recovery engine. The real deployment decision is therefore not “sandbox or no sandbox,” but which execution plane can meet the workload’s isolation, networking, observability, portability, latency, and recovery requirements while keeping policy authority outside the model-controlled path.

Key Takeaways

Gemini Enterprise Agent Platform’s Shell sandbox became GA on September 9, 2026. Google documents it as a managed, isolated Linux container reached through Shell-specific execution calls.

Commands run as unprivileged appuser without sudo; each call starts a new shell, while files under /workspace can preserve state between calls. Outbound internet is disabled unless a template enables it.

Google owns the managed execution environment and its documented isolation controls. Customers still own task authorization, IAM and credential scope, business rules, output trust, budgets, retries, rollback, and incident handling.

Managed Shell is the strongest default for GCP-centric, ephemeral, command-oriented workloads when its documented contract is sufficient. GKE Agent Sandbox or an application-owned service remains appropriate when teams need Kubernetes control, custom isolation, placement, portability, or deeper telemetry.

Do not extend this production recommendation to Computer Use. Google’s September 9 release note calls Computer Use GA, while its dedicated documentation still labels the feature Preview and applies Pre-GA terms.

What Google Actually Made GA

The September 9 release note says Shell sandboxes can run untrusted commands, install packages, and manipulate files in an isolated Linux container through direct /exec calls. The current Shell sandbox quickstart, last updated September 9, supplies the more precise execution contract.

A Shell sandbox is attached to an Agent Platform instance, yet Google says no agent deployment is required to use one. The documented helper returns stdout, stderr, returncode, and duration_ms. Shell sandboxes do not accept the send_command() or execute_code() interfaces intended for Code Execution sandboxes.

Inside the container:

Commands execute as unprivileged appuser; sudo is unavailable.
Every command starts in a new shell, so cd and shell variables do not carry across calls.
Files under /workspace can retain state between calls.
/workspace is the default working directory unless cwd is specified.
Outbound internet access is off unless enabled by the sandbox template.
Deleting the sandbox destroys the container; the management guide also says configuration changes require deletion and recreation.

Google says a sandbox “typically” reaches STATE_RUNNING in about 20 seconds. That number appears in a vendor quickstart for the demonstrated creation path, not in a benchmark report with disclosed region, image state, concurrency, trial count, or percentile. Treat it as an orientation point—not a latency SLO and not a fair comparison with pre-warmed alternatives.

Google calls the mechanism “secure container sandboxing” and a “strong security boundary.” The reviewed Shell documentation does not identify the service as a microVM, promise a dedicated guest kernel, or publish an absolute escape-resistance claim. Architecture reviews should use the documented container contract rather than assigning undocumented isolation primitives to the service.

Runtime and Sandbox Are Separate Trust Zones

Google’s sandbox architecture overview draws a clear distinction. Agent Runtime is the trusted environment for application code, agent decision-making, orchestration, and lifecycle management; a sandbox is an auxiliary environment for a specific, potentially unsafe task. Google explicitly recommends generated computation run in the sandbox rather than the agent’s runtime.

That supports—but does not itself implement—the central application-security rule: a model may propose an action, but a trusted component should independently decide whether the exact action, target, parameters, identity, and authorization state are acceptable. OWASP similarly recommends least-privilege tools, explicit authorization for sensitive operations, separation of decision-making from execution, parameter-bound approvals, output validation, bounded autonomy, and adversarial release testing.

A defensible production flow is:

Normalize the proposed action into a structured request.
Evaluate policy outside the model-controlled execution path.
Supply only the command, files, network routes, and short-lived authority required for the approved task.
Treat every returned artifact as untrusted.
Validate or quarantine results before a repository, database, deployment pipeline, or other higher-trust component consumes them.
Apply idempotency, compensation, cleanup, and retry limits at the workflow layer.

These are editorial architecture recommendations, not claims that Shell sandbox automatically provides those controls.

Figure 1: Illustrative photograph: the google logo is displayed on the side of a building. Image: Unsplash / Adarsh Chauhan

The Boundary Runs in Both Directions

Ingress includes commands, files, environment configuration, network policy, resource limits, and any deliberately exposed credentials. Egress includes command output, exit status, generated files, configuration changes, package state, and potentially snapshot state. A successful return code proves that the process completed as reported; it does not prove the result is authorized, correct, harmless, or safe for downstream execution.

A July 22, 2026 Cloud Security Alliance AI Safety Initiative research note analyzed seven findings involving Cursor, Codex CLI, Gemini CLI, and Antigravity. Its central pattern was a trust handoff: an agent wrote a file that a more privileged external component later read, loaded, scanned, or executed. The reported issues did not require directly breaking the sandbox in each case.

Those findings are not evidence of a vulnerability in Gemini Enterprise Agent Platform’s managed Shell sandbox. They do support a broader engineering conclusion: an agent’s effective blast radius includes downstream systems that automatically trust agent-authored artifacts.

Choosing the Execution Plane

Choice	Status and execution boundary	Platform-managed responsibilities	Customer responsibilities	Network, identity, and encryption	Observability and recovery	Best-fit constraints
Gemini Enterprise Agent Platform managed Shell sandbox	GA since September 9, 2026; Google-managed isolated Linux container. No documented basis to call it a microVM or dedicated-kernel environment.	Managed container provisioning, Shell command interface, documented non-root execution, lifecycle resources, and deletion. Pause/resume REST methods exist; snapshots remain Preview.	Task admission, session-to-task mapping, authorization, IAM and credential scope, business rules, output inspection, idempotency, compensation, retry limits, budgets, quarantine, and incident response.	Internet off unless enabled. PSC-E provides private ingress; PSC-I routes egress into the customer VPC. CMEK covers specified at-rest surfaces, not all metadata or custom images.	Command responses expose stdout, stderr, return code, and duration. VPC-SC-protected resources lack request/response logging; application-level audit and recovery controls remain necessary.	Best for GCP-hosted, ephemeral shell tasks where managed lifecycle matters more than runtime customization. Validate latency, billing, and recovery against the actual workload.
GKE Agent Sandbox	GA since May 20, 2026. Kubernetes-native abstraction for isolated, stateful, single-replica workloads, commonly using gVisor; open-source Kata Containers can also be integrated.	Google manages the lifecycle of the GKE add-on controller, including automatic upgrades and security patches. Core GKE services remain managed according to the selected cluster mode.	Cluster architecture, node and runtime choices, templates, images, capacity, storage, tenancy, IAM, credentials, application policy, validation, backups, telemetry, and incident operations.	Default-deny networking is documented; operators define allowed ingress and egress. Identity, storage encryption, residency, and tenant isolation depend on cluster and workload configuration.	Kubernetes and application telemetry can be designed by the operator. Pod snapshots can support save/restore, subject to version, machine, and feature limitations.	Best when Kubernetes extensibility, custom runtime selection, stable identity, stateful storage, or cluster-level observability is mandatory.
Application-owned ephemeral container or microVM service	Internally selected and operated; the boundary depends on the chosen runtime, virtualization technology, host integration, and hardening.	Only the underlying cloud or infrastructure services selected by the organization.	Full execution control plane: provisioning, patching, images, scaling, placement, tenancy, authorization, secrets, telemetry, validation, rollback, quarantine, deletion, and on-call response.	Organization defines egress, DNS, identity injection, key management, residency, and hybrid or cross-cloud connectivity.	Maximum customization, paired with maximum operational responsibility. Recovery guarantees must be engineered and tested.	Best for air-gapped, on-premises, cross-cloud, sovereignty, specialized hardware, custom-isolation, or audit requirements that managed offerings cannot evidence.
Direct execution in Agent Runtime — risk baseline	No independent execution zone; generated commands share the trusted runtime’s accessible resources and identity. Google assigns potentially unsafe tasks to sandboxes instead.	Runtime services adopted by the team.	All policy and recovery duties, without an independent execution boundary containing command effects.	Same trust zone unless separately constrained by the application.	Application logs and recovery only; no distinct containment layer for generated execution.	A comparison baseline, not the recommended production design for untrusted or model-generated commands.

Figure 2: Illustrative photograph: person using macbook pro on table. Image: Unsplash / Firmbee.com

Editorial recommendation: Start with managed Shell when every mandatory control can be enforced around it and its Linux, networking, logging, placement, and lifecycle contract fits. Choose GKE when Kubernetes control and extensibility are requirements rather than preferences. Retain an application-owned service when sovereignty, portability, custom isolation, host integration, or audit evidence cannot be satisfied by either Google-managed option.

Networking Controls Have Material Constraints

Google’s sandbox VPC-SC and PSC guide separates two paths. PSC-E provides private ingress to the interactive sandbox data plane. PSC-I bridges sandbox egress into a customer VPC, where customer-controlled routes, firewall policy, DNS, proxying, and—if public internet access is required—Cloud NAT govern the onward path.

Important documented limits include:

Private ingress supports exactly one consumer project, which must be the same user project in which the sandbox runs.
Only private DNS resolution through DNS peering is supported; public DNS forwarding is disabled.
Request and response logging is unavailable for resources protected by VPC Service Controls.
Programmatic and console access from outside the perimeter is denied unless the caller satisfies an access level.
The documented PSC-I setup uses a dedicated subnet with a minimum /28 range.

The /28 is a configuration requirement, not a throughput claim. The one-consumer-project constraint can shape centralized platform designs, while the logging limitation can be decisive for regulated incident response. Teams should prove that compensating telemetry captures authorization decisions, command hashes, artifact lineage, policy versions, and outcomes without recreating sensitive payload logging elsewhere.

CMEK Protects Specific Surfaces—not Everything

The sandbox CMEK guide says a key configured when the parent Agent Platform instance is created protects sandbox at-rest surfaces: the GKE node boot disk/root filesystem, including session-written files and memory paged to disk, plus the Cloud Storage bucket used for snapshot disk and memory checkpoints.

The customer key does not cover resource names, labels, state, connection information, environment variables, service-account email addresses, or custom container images. Custom images require separate CMEK configuration on the organization’s Artifact Registry repository.

Only single-region keys are supported. The chosen key is immutable for the Agent Platform instance; changing to another key requires a new instance, while rotating to a new version of the same key is supported and applied automatically. Disabling or destroying the active key version—or revoking the Encrypter/Decrypter role—prevents sandbox provisioning or resume operations and causes snapshot writes to fail.

CMEK administration is therefore part of availability and recovery engineering, not merely an encryption checkbox.

Lifecycle and Status Documentation Is Not Fully Aligned

The September 9 release note says pause/resume can deschedule idle compute while preserving filesystem state and connection identity, with resume “in seconds.” The v1 REST reference exposes both sandboxEnvironments.pause and sandboxEnvironments.resume, each returning a long-running operation.

However, the dedicated Manage sandboxes guide reviewed on September 13 still documents only list, view, and delete operations. Its navigation contains no pause/resume section, despite the release note linking to a pause anchor. Teams should validate the exact API version and SDK surface they intend to support rather than assuming every documentation path has converged.

Snapshots are independently documented as Preview under Pre-GA terms. They can preserve installed libraries, filesystem changes, and memory state, but restore requires matching server architecture, sandbox runtime version, and container image URI.

Agent Platform Sessions are separate from Shell filesystem state. Sessions maintain interaction history, events, temporary conversational state, and cross-session memory concepts; Shell itself is not the conversation-state service.

A second discrepancy concerns Computer Use. The release note says both Computer Use and Shell are GA, but the dedicated Computer Use page still says Preview, invokes Pre-GA terms, requires full network access, and warns that higher traffic can experience elevated latency.

This article therefore makes a production recommendation only for Shell sandbox. Computer Use’s status should be treated as unresolved until Google aligns the release note, product page, and applicable terms.

GKE Performance Numbers Need Their Warm-Pool Context

Google announced GKE Agent Sandbox GA on May 20, 2026. Its blog says the integrated warm pool can allocate 300 sandboxes per second per cluster, with 90% of allocations completing within 200 milliseconds. Those are vendor-reported allocation figures for a pre-warmed pool—not a cold-creation result and not directly comparable with managed Shell’s “about 20 seconds” quickstart example.

GKE’s documentation describes Sandbox, SandboxClaim, SandboxTemplate, and SandboxWarmPool resources; stable network identity and storage; default-deny network policy; gVisor-based isolation; optional open-source Kata Containers; and integration with Pod snapshots. Google manages the add-on controller, but customers still operate workload configuration and the surrounding cluster architecture.

Pricing Does Not Yet Establish a Shell Cost Model

Google’s official 2026 Agent Platform price sheet lists unified rates of $0.085 per vCPU-hour, $0.009 per GiB-hour of memory, and $0.30 per GiB-month of storage. It says Runtime, Code Execution Sandbox, Sessions, and Memory Bank are transitioning to those unified SKUs.

The document does not explicitly name Shell sandbox or map Shell operations to invoice lines, idle treatment, or metering granularity. These rates should therefore be treated as Agent Platform SKU evidence—not a verified Shell task-cost model. Production approval should use billing exports from the deployed workload, including applicable network, snapshot, storage, idle, and operational costs.

Proposed Validation Plan—Not Yet Executed

Status: Proposed editorial test design. Tech Trend Insight has not run these experiments, and the sample size below is not claimed to be statistically sufficient.

Evaluate managed Shell, GKE Agent Sandbox, and one application-owned container or microVM baseline in the same GCP region. Use the same repository snapshot, dependency manifest, command corpus, network allowlist, output-validation pipeline, input hashes, and canary-secret design.

Run 30 trials per scenario per alternative: 15 cold and 15 warm or reused trials where reuse is supported.

Test seven workload classes:

Trivial local execution returning stdout, stderr, and exit status.
Dependency installation and tests against a fixed small repository.
File transformation followed by independent validation.
Attempts to access prohibited host paths, metadata endpoints, environment credentials, and network destinations.
Resource exhaustion with an enforced timeout.
An agent-authored Git, task, or configuration artifact offered to a quarantined downstream consumer.
Forced interruption followed by retry, restore, or compensation.

Measure p50, p95, and p99 creation and command latency; completion rate; expected access denials; canary-secret exposure; artifact-validation failures; post-recovery state hashes; billed compute, memory, storage, snapshot, and network cost; and operator actions per incident.

The proposed release gate should require: complete denial of prohibited access; zero canary-secret disclosure; quarantine until independent validation; deterministic timeout and cleanup; no unauthorized downstream execution; compliance with a predeclared application SLO; the expected post-recovery state hash; and cost below a predeclared per-task budget.

Publish distributions and failure cases. Do not turn the fastest run into a product conclusion.

Figure 3: Illustrative photograph: low-angle photography of metal structure. Image: Unsplash / Alina Grubnyak

Tech Trend Insight Editorial Verdict

Adopt—for the right workload, with external policy gates. Managed Shell is the sensible default for GCP-centric teams that need ephemeral command execution and want Google to operate the documented container lifecycle. It is not a substitute for authorization, credential brokering, structured validation, workflow recovery, or incident response.

Choose another execution plane when approval requires cross-cloud or on-premises placement, a specific isolation primitive, complete request/response visibility inside a VPC-SC boundary, custom host integration, verified Shell-specific billing, or recovery guarantees that documentation and workload-matched testing cannot demonstrate.

Evidence that could change this recommendation includes independently reproduced findings against the managed Shell service, a Shell-specific SLA and billing map, broader placement options, improved protected-boundary logging, or controlled p95/p99 and recovery results showing materially lower operational risk from another option.

Conclusion

Gemini Enterprise Agent Platform’s managed Shell sandbox removes real undifferentiated work: providing a managed Linux execution environment, enforcing the documented unprivileged contract, transporting commands, exposing lifecycle resources, and destroying containers on deletion.

The work left to the application team is the work that determines whether an agent is safe to operate: authorizing exact actions, minimizing credentials and IAM scope, governing network access, distrusting every returned artifact, bounding retries and spend, and recovering predictably when technical execution succeeds but the business operation does not.

The right execution plane is not the product with the strongest isolation headline or the lowest vendor-reported latency. It is the least operationally burdensome option that can prove ingress authority, execution containment, and egress trust under the organization’s actual workload.

FAQ

1. Does managed Shell replace Kubernetes, containers, or microVMs for AI agents?

No. It can replace a separately operated command-execution service when Google’s managed Linux contract satisfies the workload. GKE or an application-owned service remains appropriate when teams require custom runtimes, placement, portability, tenancy, telemetry, storage, or recovery behavior.

2. What remains the developer’s responsibility?

The team must authorize tasks and tools, scope IAM and credentials, decide what data enters the sandbox, validate stdout and files, quarantine agent-authored configuration or code, cap retries and concurrency, and implement rollback, compensation, cleanup, and incident response. Conversation history and memory require separate session or application design.

3. When should a team choose managed Shell instead of GKE Agent Sandbox or its own service?

Choose managed Shell for ephemeral, command-oriented GCP workloads when its documented network and lifecycle contract fits. Choose GKE when Kubernetes extensibility, custom runtime choice, stateful identity, or cluster-level operations are requirements. Choose an application-owned service when placement, sovereignty, portability, isolation evidence, or observability requirements cannot be met by either Google-managed alternative.

Tech Trend Insight