Skip to lesson

Google CloudProfessional Agentic Architect2026-092.1 Using coding agents effectively

Choose a coding-agent sandbox

Completed by the knowledge check

Learning objective

Choose among an Antigravity sandbox, Cloud Workstations, and GKE Agent Sandbox for a coding-agent workload. Match the environment to who uses it, where code runs, how long state must live, and who operates the platform. This lesson does not define the detailed permissions that code receives inside the chosen environment.

Core idea

Start with the unit being isolated:

  • An Antigravity sandbox isolates agent-initiated commands on a developer’s computer.
  • Cloud Workstations gives each developer a centrally configured remote development environment.
  • GKE Agent Sandbox lets an application request isolated execution environments for agent workloads at runtime.

These products solve problems at different layers. Choose the smallest operating model that supplies the required trust boundary. Local assistance usually does not need a Kubernetes control plane. A fleet of customer-facing agents should not depend on developers’ workstations.

How it works

Antigravity sandbox: protect an interactive local session

Antigravity runs coding agents against local project folders. When terminal sandboxing is enabled, agent shell commands run inside an operating-system-level boundary. The sandbox exposes approved workspace paths, blocks other paths, and denies network access unless a domain is allowed. Native operating-system primitives avoid a virtual machine or container startup cycle (Antigravity terminal sandbox).

This option fits a developer who wants low-friction agent assistance on an existing machine. It operates at project or conversation scope, not as a managed workstation or production pool. Permissions and approval rules still matter: Antigravity supports explicit unsandboxed exceptions, so a bypass changes the effective boundary for that command.

Cloud Workstations: govern a developer environment

Cloud Workstations provides managed development environments that developers open from a browser, a supported local editor, or SSH. A workstation configuration defines the machine, container image, editor, and optional persistent storage. Each workstation runs on its own Compute Engine virtual machine (VM) in the organization’s project and VPC network (Cloud Workstations overview).

The VM is ephemeral, but an optional persistent home directory survives across sessions. Administrators can apply updates on restart and set idle or running timeouts. They can also govern access through Identity and Access Management (IAM), private networking, and organization controls.

Choose Cloud Workstations when a human developer needs a reproducible, cloud-hosted environment with central administration. A coding agent can run inside that environment, but the workstation remains a developer workspace, not a sandbox allocation API. Google also advises one workstation per developer and warns that workstation containers run privileged with root access; the dedicated per-workstation VM supplies the stronger isolation boundary (Cloud Workstations security best practices).

GKE Agent Sandbox: serve programmatic agent execution

GKE Agent Sandbox is a managed GKE add-on for isolated, stateful, single-replica workloads such as untrusted model-generated code. A SandboxTemplate defines the Pod and network policy. A client or controller creates a SandboxClaim, and the controller binds that request to a sandbox. Warm pools keep ready instances for low startup latency. Persistent volumes can support state when the workload needs it (About GKE Agent Sandbox, Agent Sandbox CRDs).

This option fits a product that must create and retire sandboxes through an API. It provides Kubernetes extensibility and security-focused runtimes such as gVisor, but the platform team must operate capacity, templates, policies, routing, observability, and workload identity. Under the managed default network posture, ingress comes through the Sandbox Router; public internet egress is allowed, while private address ranges, cluster DNS, and the cloud metadata server are blocked. Customize network policy when the sandbox needs private services or Google Cloud identity (Run Agent Sandbox in production).

Key distinctions and trade-offs

Use the following decision frame:

Decision signalAntigravity sandboxCloud WorkstationsGKE Agent Sandbox
Primary consumerOne developer using a coding agentA developer in a managed environmentAn application or agent orchestrator
Compute locationDeveloper’s machineDedicated VM in a Google Cloud VPCSandboxed Pod on a GKE cluster
LifecycleInteractive command or conversationStart-and-stop developer workspaceClaim-driven workload; optionally warm-pooled
StateExisting local workspaceOptional persistent home diskExplicit Pod and persistent-volume design
Main advantageFast local feedback with little infrastructureCentralized developer environment governanceProgrammable scale and Kubernetes control
Main costDepends on endpoint security and local capacityPer-workstation cloud resources and service operationsCluster engineering and capacity management

The isolation mechanisms are not interchangeable labels. An Antigravity worktree separates Git changes but is not a security boundary. A Cloud Workstations cluster is a regional service control plane, not a GKE cluster. GKE Sandbox, the gVisor-based runtime, protects the host kernel; GKE Agent Sandbox adds the lifecycle API, claims, templates, routing, and warm pools needed by agent workloads (GKE Sandbox).

Architecture / decision scenario

A bank has two coding-agent uses. Its engineers need access to private source repositories and development APIs, while a customer-facing analysis service generates and executes short Python programs from natural-language requests.

For engineers, the bank chooses Cloud Workstations. Platform administrators publish a patched image, assign one workstation to each developer, attach the workstation cluster to the development VPC, restrict access with IAM, and stop idle sessions. Developers may run Antigravity inside a workstation, but its terminal sandbox is an additional command boundary, not a replacement for the managed remote environment.

For the customer-facing service, the bank chooses GKE Agent Sandbox. The orchestrator creates one claim per execution from a hardened template. A warm pool meets interactive startup needs, and the platform sets resource limits, short lifetimes, and an egress policy. The sandboxes receive no developer home directories and no broad service identity. Cloud Workstations would optimize for a human session, and local Antigravity sandboxes would not provide a production allocation plane.

An individual engineer prototyping the same analysis logic on non-sensitive sample data can start with Antigravity’s local sandbox. The production architecture changes when the consumer, scale, and trust boundary change.

Common exam traps

  • Choosing the product by the word sandbox instead of identifying whether the consumer is a developer or an application.
  • Treating an Antigravity worktree as security isolation, or assuming a sandbox bypass keeps the same protection.
  • Choosing Cloud Workstations as an autoscaled runtime for end-user agent jobs.
  • Assuming a Cloud Workstations container is the outer security boundary; each developer’s dedicated VM is the more important boundary.
  • Choosing GKE Agent Sandbox for one local coding session because it offers the most controls, while ignoring cluster complexity.
  • Assuming GKE Agent Sandbox blocks all outbound internet traffic by default.

What to remember

  • Choose Antigravity for local, interactive command containment.
  • Choose Cloud Workstations for centrally governed, human development environments.
  • Choose GKE Agent Sandbox for programmatic, scalable agent execution.
  • Compare the consumer, compute location, lifecycle, state, and operating model before comparing features.
  • Layer permissions, identities, and network policy inside every chosen boundary.

Knowledge check

References