Google Cloud gives every agent a SPIFFE identity and a sandbox that holds no secrets

Google Cloud gives every agent a SPIFFE identity and a sandbox that holds no secrets

by

Google Cloud has made agent identity an infrastructure primitive rather than an application feature. Announced at AGNTCon + MCPCon on 22 October, Agent Compute Engine gives every agent its own hardware-isolated microVM, and every microVM gets a short-lived, cryptographically attested identity built on SPIFFE — the Secure Production Identity Framework for Everyone, the CNCF workload-identity standard.

What happened

Google Cloud launched three things that fit together:

  • Agent Compute Engine — a compute service built for agent lifecycles. Each agentic session runs in a dedicated, single-tenant microVM behind a Cloud Hypervisor boundary, with its own guest kernel and root access. Idle agents are checkpointed and paused, then resumed from snapshot, which is what makes running large fleets economically plausible. It will be available in preview “in the coming months”; it already runs Gemini’s work agents internally.
  • Agent Identity — every agent gets a unique secure ID based on SPIFFE, used for authentication, access control and auditing. In the deep dive, Google describes the mechanism concretely: each microVM receives “only an ephemeral, session-scoped public SPIFFE certificate and short-lived identity token via a dedicated, per-VM isolated local listener.”
  • Agent Registry and Agent Gateway — the registry is a central record of approved running agents, tools, MCP servers, skills, models and endpoints; the gateway enforces policy on client-to-agent and agent-to-anything traffic and brokers egress.

The security design is the part worth reading closely. Google’s stated rule is to “assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use.” MicroVMs hold no user credentials, API keys, OAuth refresh tokens or service-account keys in memory or on disk, and have no access to the instance metadata server. Long-lived credentials stay off-host and are swapped in by the gateway only after it has validated the session’s mTLS identity and egress policy. The host runs a read-only root filesystem; attestation keys live outside the guest in the Titanium IPU.

Governance is being extended beyond Google Cloud: policy enforcement points for multicloud and on-premises environments, OS-level sandboxing for local coding agents such as Claude Code and Antigravity CLI, and delegated user authorization with third-party identity providers Ping Identity, SailPoint and Saviynt.

Why it matters for KYA

The identity question is being answered at the wrong layer for most buyers — which is good news. Until now, an agent’s identity was usually whatever its builder remembered to implement. Putting issuance in the platform means the default becomes: an agent exists ⇒ it has a verifiable identifier, a key, and a short lifetime. That removes the most common failure mode in KYA — agents deployed with a shared API key and no attributable identity.

Short-lived and session-scoped is the right shape. A credential that expires with the session cannot be exfiltrated from a snapshot and reused next week, and it gives the relying party something to check at the moment of the request. It also makes revocation tractable: kill the session, not the integration.

A registry is a KYA control, not a directory. The Agent Registry is the piece that answers “is this agent allowed to exist in my estate?” — an allowlist of agents, tools, MCP servers and models, with policy attached. That is closer to an inventory under governance than to a public agent registry, and practitioners should read it that way.

Two gaps remain, and they are the interesting ones. First, identity is not authority: a SPIFFE ID proves which workload is calling, not what it may do on whose behalf. Google’s answer to delegation is third-party IdP integration and OAuth through the Agent Identity auth manager — that is where the hard KYA questions (scope, consent, onward delegation) still live. Second, the deterministic audit trail Google describes correlates harness tool calls with sandbox compute activity; it does not, on its own, tell a downstream service that a specific human authorised a specific transaction.

The competitive effect matters. When a hyperscaler ships agent identity as a default, “does your agent have an identity?” stops being a differentiator and becomes table stakes. The differentiation moves to evidence: can you show a relying party the delegation chain, the human approval, and the audit record — in a form they can verify without trusting your platform.

Caveats: this is a preview announcement with no published pricing, no independent security review, and Google’s own performance figures. The SPIFFE-based identity is real and documented; treat the broader governance claims as roadmap until the endpoints are generally available.

Sources

Note: Agent Compute Engine is announced for preview “in the coming months”; capability descriptions are as published by Google Cloud on 22 October 2026.

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.