Per-Agent Isolation Without Google's Agent Compute Engine: How to Get the Same Three Guarantees on Kubernetes Today

Yes, you can get the same three guarantees as Google's Agent Compute Engine today, on Kubernetes, in your own AWS, GCP, Azure, or Scaleway account. Run each agent session in its own ephemeral pod on a sandboxed RuntimeClass (gVisor or Kata Containers), give the agent an identity it can use but never read, and log every action it takes to a sink it cannot touch.

Key Points:

• Agent Compute Engine is announced, not available. Google introduced it on October 22, 2026 and says it "will be available in preview in the coming months" (Google Cloud blog).
• A safe agent runtime is three separable properties: an isolation boundary stronger than a shared container kernel, credential exteriorization so the agent uses an identity it can never read, and a per-action audit trail tied to that identity.
• Hardware isolation is the easiest property to buy and the least likely to save you. Over-scoped credentials and unlogged tool calls cause the damage, which is why OWASP ranks Excessive Agency as a top LLM risk.
• Qovery is not a microVM vendor. It runs agents as ephemeral environments on Kubernetes in your own cloud account or existing cluster, with per-environment RBAC and an audit trail. The kernel boundary is a RuntimeClass on that cluster.

What exactly did Google Cloud ship with Agent Compute Engine?

Agent Compute Engine is Google Cloud's announced managed runtime for AI agents: each agent session gets its own hardware-isolated microVM, and the platform keeps credentials outside the guest, so a compromised agent can use a permission without ever reading the secret behind it.

According to Google's launch post and technical deep dive, both dated October 22, 2026:

• Isolation: "Each agentic session runs inside a dedicated, single-tenant and memory-safe microVM" on a Cloud Hypervisor boundary "with its own guest kernel".
• Credentials: "service credentials are injected in egress outside the microVM." The guest holds only a session-scoped SPIFFE certificate and a short-lived identity token.
• Location: "Google manages the underlying fleet." The microVMs have no "direct VPC access" and reach private resources through Agent Gateway and Private Service Connect.
• Status: "targeted for preview in the coming months", with a sign-up form and no public docs or pricing yet.

Google built this because agents run model-generated code and tool calls that nobody reviewed beforehand. The threat model is right and the design is good. My disagreement is about where the boundary lives: Google's fleet or your account. And some decisions stay yours either way: how broad the brokered credential is, which tools the agent may call, and who keeps the logs.

Which three properties actually make an AI agent runtime safe?

A safe AI agent runtime is three separable properties: an isolation boundary stronger than a shared container kernel, credentials the agent can use but never read, and an append-only audit trail of every action tied to an agent identity. You can buy or build each one independently.

1. Isolation boundary. A runc container shares the host kernel. gVisor's Sentry "intercepts and responds to system calls" and "does not pass system calls through to the host kernel" (gVisor docs). A microVM gives the agent its own guest kernel behind a hypervisor.
2. Credential exteriorization. The agent calls a broker that holds the identity and returns a short-lived scoped token, or performs the action and returns only the result. The secret never exists inside the agent process.
3. Audit boundary. Every tool call, deployment, and data access is attributable to an agent identity and lands in a log the agent cannot write to or delete.

Add a fourth, blast radius: one agent run, one ephemeral environment, destroyed afterwards. A sandbox that lives for weeks accumulates tokens and state, so statelessness belongs on your security checklist.

Most teams over-invest in property 1 and under-invest in 2 and 3. OWASP's LLM06:2025 Excessive Agency traces damaging agent actions to "excessive functionality; excessive permissions; excessive autonomy". A perfect microVM does nothing when the agent calls DeleteBucket with the admin token you gave it.

Can you get hardware-level isolation per agent on Kubernetes today?

Yes. Kubernetes RuntimeClass lets you schedule agent pods onto gVisor or onto Kata Containers microVMs (Firecracker, Cloud Hypervisor, or QEMU) on GKE, EKS, AKS, or your own cluster, while every other workload keeps running on runc.

RuntimeClass has been "Stable since Kubernetes v1.20". One field, runtimeClassName: gvisor or runtimeClassName: kata, selects the sandbox per pod. Kata "supports multiple hypervisors" including Firecracker and Cloud Hypervisor (Kata docs). Firecracker itself boots "to application code in less than 125ms" with "memory overhead of less than 5MB" per microVM, and powers AWS Lambda and Fargate (Agache et al., USENIX NSDI 2020).

The costs are documented:

• gVisor "only implements a subset of the Linux syscall ABI" (gVisor compatibility), and the overhead hits "applications that are system call bound" (gVisor performance).
• GKE Sandbox: "MicroVMs don't support GPUs", gVisor GPU support is CUDA-only on a subset of models, you "can't enable GKE Sandbox on the default node pool", and each microVM pod carries "250 mCPU and 130 MiB" of overhead with a one to two second start (GKE Sandbox docs).

Run one pod per agent run, with a TTL and automatic teardown. The open source Agent Sandbox project under Kubernetes SIG Apps packages that pattern as Sandbox, SandboxTemplate, and SandboxWarmPool CRDs on top of gVisor or Kata, on any conformant cluster.

This is heavier than clicking a managed service: you own node pools, runtimes, and upgrades. That is the price of keeping the cluster, the IAM, and the logs in your account.

How do you keep credentials outside the agent, the way Agent Compute Engine does?

You keep credentials outside an AI agent by never issuing it one: the agent calls a broker it cannot bypass, the broker holds the identity, and the agent receives only short-lived scoped tokens or the result of a pre-authorized action. Kubernetes gives you four documented patterns.

• Workload identity federation. EKS Pod Identity maps an IAM role to a service account "instead of creating and distributing your AWS credentials to the containers". GKE Workload Identity Federation issues "a short-lived federated access token". Microsoft Entra Workload ID works on AKS "without managing secrets".
• Egress proxy. Route agent traffic through a proxy that injects auth and logs every call. The agent sees a URL, never a secret. Google's Agent Gateway does exactly this.
• Scoped MCP tool servers. The agent gets tools instead of API keys, read-only by default.
• Human approval for mutating actions, recorded as an audit event.

The anti-pattern is an admin key in an env var "because the container is sandboxed anyway." Isolation does not shrink credential scope. Datadog's State of Cloud Security found that "59% of IAM users have an active access key older than one year" and 19.4% of EC2 instances are overprivileged, and the 2025 Verizon DBIR puts use of stolen credentials at 22% of breaches. An agent with a static key inherits all of that.

Where does the audit boundary actually live, in the sandbox or in the control plane?

The audit boundary for AI agents lives in the control plane. A microVM proves the agent could not escape; only an identity-tied action log proves what it did, and that log belongs in a sink the agent cannot write to and a vendor cannot take away.

A usable record holds the agent identity, the triggering human, the tool or API called, parameters, target environment, approval state, result, and timestamp. Most sources already exist: Kubernetes auditing records "who initiated it? on what did it happen?", CloudTrail records the assumed role behind each call, and Cloud Audit Logs answers "who did what, where, and when?"

The missing link is identity propagation. Cloud logs show a service account calling an API, not "agent X acting for engineer Y on ticket Z". Fix it with one identity or session tag per agent run, carrying the requesting user and ticket.

Ownership matters as much as content. Auditors testing SOC 2 change management (AICPA Trust Services Criteria, CC8) or ISO/IEC 27001 logging and change controls want authorized, attributable production changes. They never ask about your hypervisor, and if the logs sit in a vendor's account, your incident response inherits that vendor.

Should you wait for Agent Compute Engine or run agents on your own Kubernetes?

Use Agent Compute Engine, once it reaches Preview, if your agents live entirely inside Google Cloud and you want strong isolation with minimal operations. Run agents on Kubernetes in your own account if they must reach your VPC and data, if your compliance perimeter has to contain them, or if you won't accept a single-cloud agent layer.

Launch stage is a schedule risk. Google Preview offerings come with "no SLAs or technical support commitments", are "intended for use in test environments only", and last "about six months" on average (Google Cloud launch stages). Cost differs too: sandboxed pods run on nodes covered by the commitments you already bought, and the bill stays in your name.

A hybrid often wins: prototype on a managed runtime and keep the tool layer portable (MCP, provider-neutral tool specs) so the runtime stays swappable. Each alternative has a real strength. AgentCore is GA and AWS-native, E2B offers Firecracker sandboxes with BYOC, Modal shines for Python and GPU jobs, Daytona runs sandboxes on your compute, and Fly Machines are fast, cheap Firecracker VMs.

How does Qovery give you a per-agent isolation and audit boundary in your own cloud account?

Qovery runs agent workloads as isolated, ephemeral environments on Kubernetes inside your own AWS, GCP, Azure, or Scaleway account or existing cluster, so each agent run gets its own environment, scoped permissions, and deployment audit trail, while the cluster, the IAM, and the bill stay in your name.

• Ownership: cluster audit logs, cloud audit logs, and workload identities live in your account. Qovery's control plane keeps the deployment audit log of who or what deployed which service, where, and when.
• Blast radius: an ephemeral environment per agent run, with auto-shutdown, so nothing long-lived accumulates state or tokens.
• Scoped authority: per-environment RBAC gives an agent write on staging and read-only on production, enforced by the platform instead of a prompt.
• Opt-in writes: the Qovery MCP Server "connects in read-only mode unless you say otherwise." Writes need read_write=true on the URL and a separate write-access setting in the Qovery Console.

Qovery is not a microVM sandbox vendor. For Firecracker-grade kernel isolation, install gVisor or Kata on a node pool of the cluster Qovery manages and set runtimeClassName on the agent workload, for example in a Helm service. Qovery owns the environment, RBAC, and audit layer, and the RuntimeClass owns the kernel boundary.

How do I set this up with Qovery from Claude Code, Cursor, or Codex?

Install the Qovery Agent Skills once and your coding agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI, and others) can create isolated environments on your own cluster in plain language. Add the MCP Server when you want the agent to operate what already exists, read-only by default.

curl -fsSL https://skill.qovery.com/install.sh | bash

# MCP Server for Claude Code, OAuth, read-only
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you mean it (also enable write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-preview, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-terraform, and more) deploy; the MCP Server operates. The agent never receives your cloud credentials: it acts through an authenticated Qovery session scoped by RBAC, and every action lands in the audit trail. See the AI agent quickstart and the Claude Code integration.