A coding agent may need root in its sandbox. Does it also need to hold backend API credentials there? Google Cloud's Agent Compute Engine separates those boundaries: working data and short-lived workload identity remain inside, while backend token exchange happens at an external gateway.

Agent Compute Engine is not generally available. In its October 22 announcement, Google said a preview is coming "in the coming months" and that the system currently runs Gemini and internal evaluation and reinforcement-learning workloads. The diagram below reconstructs the official architecture description, rechecked October 26. We did not operate the Google runtime or measure its costs.

Separate an announced architecture from available services

The October 22 announcement says Agent Compute Engine will enter preview in the coming months. Internal use at Google does not establish availability to external customers today.

Agent Sandbox on GKE has its own documentation and operating requirements. Do not transfer density or startup claims for related runtimes into an Agent Compute Engine service guarantee. The announcement reviewed here does not provide final ACE pricing, regions, quotas, or an SLA.

Architecture: brain outside, hands inside

Google splits an agent in two. The harness, the brain, calls the model and decides the next action. The sandbox, the hands, runs code, a shell, and a browser. The harness runs outside the sandbox, and the sandbox executes only the commands the harness explicitly sends.

harness (outside, trusted)
   │  explicit tool call
   ▼
microVM (inside, untrusted)
   ├─ own guest kernel, root access
   ├─ no NIC, no metadata route
   └─ virtio-vsock → local unprivileged proxy
                        │ mTLS
                        ▼
                 Agent Gateway (off-node)
                   ├─ verify user delegation
                   ├─ verify SPIFFE workload identity
                   ├─ policy / DLP
                   └─ in-flight token swap → backend

Four details matter.

  1. There is no network interface. The microVM boots without a standard NIC. All traffic goes over vsock to a local proxy, and the VM is never attached directly to the VPC.
  2. The metadata server is unreachable. That removes the classic SSRF path to cloud credentials.
  3. There are no long-lived backend credentials. User tokens, OAuth refresh tokens, and service-account keys are not in guest memory or on the guest disk. The guest holds a session-scoped, short-lived SPIFFE certificate and a short-lived token.
  4. Token exchange happens outside. Agent Gateway validates user delegation, agent identity, and node identity, then attaches the backend credential as the request leaves the gateway.

Google describes four identities: the user, a delegation identity acting for the user, a workload identity bound to the microVM, and the agent's own workforce identity. Only the third is present inside the sandbox, and leaking it does not let an attacker call backend APIs directly. Its job is to prove which sandbox sent the packet.

What "no credentials" does and does not mean

The threats this removes are concrete.

  • Prompt injection reads a key from an environment variable or home directory and exfiltrates it.
  • Sandbox root leads to cloud metadata and a stolen token.
  • A guest memory dump or snapshot yields a long-lived secret.

But "no secrets" is not "no authority." The sandbox still performs work the harness requested, and the gateway still injects backend tokens within policy. An attacker who fully owns the guest can do the following.

Attacker capability Remaining control Residual risk
Guest root Backend long-lived keys kept outside Exfiltration over allowed egress, resource abuse
Malicious prompt drives tool calls Gateway policy, DLP, approvals Broad policy makes the request look normal
Snapshot or disk access IPU-backed encryption, token required Abuse by a principal with restore rights
Attack another VM on the host Hypervisor boundary, side-channel mitigations Shared-resource channels such as cache timing
Compromise the gateway mTLS, policy engine The gateway becomes the high-value target

That last row is the important one. Moving credentials out makes the sandbox a less attractive target and makes the gateway a more attractive one. "No secrets" is not the end of security. It is a design that consolidates the trust boundary in one place.

A portable sandbox audit

A credential audit must not become another disclosure channel. Log variable names, never their values: dumping env can copy keys into CI artifacts and terminal history. This example reads a fictional object only, not the real process environment. Save it as env-audit-demo.mjs and run it with Node 18 or later. Its output was checked locally; no network or dependency installation is involved.

// env-audit-demo.mjs — Node 18+, synthetic fixture only
function credentialNames(environment) {
  return Object.keys(environment)
    .filter(name => /key|token|secret|password|credential/i.test(name))
    .sort();
}
const fixture = { PATH: "/usr/bin", API_KEY: "fictional", SESSION_TOKEN: "fictional" };
console.log(JSON.stringify(credentialNames(fixture)));

["API_KEY","SESSION_TOKEN"]

This is a name heuristic, not a secret scanner. Ordinary names containing key can be false positives, while a secret named AUTH may be missed. An operational audit must distinguish permitted short-lived identity from forbidden long-lived keys and separately inspect credential handling in files, memory, and logs. This synthetic output is not a security verdict on a real sandbox.

Check Pass condition If it fails
Long-lived keys in env None Strip before sandbox creation
Metadata access Timeout or 403 Block with network policy
Default route None, or proxy only Remove the direct path
DNS Allowed domains and record types only Separate resolver policy
Shared mounts Read-only, minimal scope Revoke write access
Session identity Short TTL, session-scoped Do not fall back to static keys
Audit log Tool calls joinable to network requests Add correlation IDs
Idle snapshot Encrypted, restore restricted Rework the retention policy

Idle cost: when checkpointing pays

The practically important part of Google's description is that most agents wait. They wait for model output and for user input. Reserving CPU and memory during that wait wastes money. Agent Compute Engine detects idleness at the application level, checkpoints, and restores on the next tool call.

Keep units consistent. Let H be hours observed, r the active fraction, a active cost in dollars/hour, s snapshot retention cost in dollars/hour, n the restore count, and w dollars per restore. A simple model is:

always_on_usd = H * a
checkpoint_usd = H * r * a + H * s + n * w
Input or result Illustrative assumption
H, r 24 hours, 20%
a, s $0.10/hour, $0.005/hour
n, w 12 restores, $0.002/restore
Always on $2.40
Checkpoint $0.48 + $0.12 + $0.024 = $0.624
Break-even 900 restores cost $2.40 under the same assumptions

These are original arithmetic examples, not Google prices or measurements. They assume snapshot retention for the entire observation period and omit network, disk I/O, minimum billing, and checkpoint creation charges. A low active share alone does not guarantee savings. Frequent restores or large state writes can reverse the result. Restore latency is a separate requirement: a cheaper system must still meet the product's p95 waiting-time budget.

Remaining risk and open questions

  • Preview status. Price, regions, quotas, SLA, and data-retention policy are unpublished. Get them in writing before committing.
  • Side channels. Google says it applies CPU side-channel mitigations, but sharing a host leaves cache-timing channels theoretically possible. OpenAI's separate disclosure of cache-timing communication between sandboxes on the same host is a concrete example.
  • Gateway concentration. Credential exchange converges on one point, so the gateway's availability and authorization checks can become the single failure point for the whole security model.
  • Policy breadth. "Allowed egress" is also the data-exfiltration path. Review DLP and destination allowlists together.

The trust boundary matters more than the microVM

The real message of Agent Compute Engine is not "one VM per agent." It is: keep the harness outside the sandbox, keep credentials outside the guest, funnel all traffic through a policy-enforcing gateway, and issue a short-lived identity per session. The microVM is one way to implement that.

You can apply four of those ideas today without Google's service. Do not put long-lived keys in a sandbox. Block metadata and DNS separately. Funnel egress through one proxy. Checkpoint idle sessions. Validate these items separately from the microVM boundary. Checkpointing is a cost and lifecycle optimization, not a security control by itself.

The final paid promotion covers agent execution structures through harnesses, loops, and graphs. It connects to execution-boundary design here; it is not a Google Cloud operations course or a security certification.

Related reading

Sources