Custom AI Agents Get a MicroVM Security Model
Google Cloud's Agent Compute Engine matters to teams building custom AI agents because it changes the default runtime assumption. Instead of treating an agent like ordinary application code inside a container, Google is treating each session as untrusted code that deserves its own hardware-isolated boundary. For enterprise AI security, that is a notable shift.
According to the Google Cloud technical deep dive and the original Marktechpost report, Agent Compute Engine gives every agent session its own microVM, keeps credentials out of the sandbox, and checkpoints idle sessions to zero active resources. The larger story is not only about speed. It is about AI integration architecture, identity design, and what secure AI automation agents may look like in production.
What is custom AI agents?
Custom AI agents are task-specific software agents that can reason, call tools, run code, browse systems, and take actions inside business workflows. In this launch, the term matters because Google is introducing infrastructure designed specifically for those agents, rather than asking teams to run them on general-purpose containers or VMs.
Why does Google's microVM-per-agent model matter?
Google announced Agent Compute Engine this week at AGNTCon and MCPCon, with customer preview planned for the coming months. The core design is simple: one hardware-isolated microVM for each agent session, with its own guest kernel, root access, and storage path.
That design matters because many AI agent development projects now involve code execution, shell commands, browser sessions, and external API calls. In a conventional container model, those actions often sit closer to shared host resources and long-lived credentials than security teams prefer. Google is explicitly assuming the sandbox may be compromised by prompt injection or malicious tool use.
The market is splitting along three lines. First, some vendors are optimizing for developer convenience. Second, some are optimizing for cloud density. Third, a smaller group is optimizing for blast-radius control. Agent Compute Engine belongs in the third category.
Google says the service already powers Gemini for work tasks. It also says the host layer runs on Google-managed systems using Titan silicon and the Titanium IPU, with a Cloud Hypervisor boundary around each microVM. What remains undisclosed is just as important: no public pricing, no ACE-specific boot time, no density numbers, and no exact preview date.
How does the harness-and-sandbox split change AI integration architecture?
Google divides an agent into two components. The harness, effectively the control plane, calls the model and decides what happens next. The sandbox runs the code, shell commands, or browser actions. This separation is more consequential than it first appears.
In practical terms, it means the reasoning layer and the execution layer no longer need to share the same trust boundary. The harness can remain outside the sandbox while the sandbox is treated as disposable and untrusted. That is a cleaner model for private AI solutions than the common pattern of giving a single runtime broad access to tools, memory, and credentials.
The network path reinforces that separation. Google says microVMs have no standard network interface, no default gateway, and no direct VPC access. Traffic crosses a virtio-vsock boundary to a local proxy, then reaches an off-node gateway where policy checks happen before any real credential is introduced. This is closer to a service-mediation pattern than a normal runtime pattern.
For enterprise teams designing AI automation implementation services, the non-obvious lesson is that agent infrastructure is starting to look more like zero-trust workload design than chatbot deployment. That affects where AI API integration logic should live, how audit trails are collected, and how enterprise AI integrations are segmented by risk.
Why remove credentials from the agent node entirely?
The strongest design choice in Agent Compute Engine is not the microVM itself. It is the refusal to leave useful secrets inside the sandbox.
Google describes four identities for agent workloads: the user identity, a delegated on-behalf-of identity, an agent workload identity, and an agent workforce identity. Only the short-lived workload identity enters the sandbox, reportedly using SPIFFE semantics. That identity is mainly useful for saying which sandbox sent a packet. It is not supposed to be enough for direct backend access.
The real backend credential is swapped in later by Agent Gateway after policy checks. Google is effectively moving the secret-bearing moment off the compute node. That is a meaningful architectural choice for enterprise AI security because it reduces the value of exfiltration from inside the runtime.
This is also where custom AI agents become an identity problem, not just an orchestration problem. If an agent can act on behalf of a user, an enterprise needs to know which permissions came from the person, which came from the agent's own account, and which were granted only for the session. AWS has made similar moves with AgentCore Runtime, while Microsoft has discussed isolation and lifecycle trade-offs in Azure dynamic sessions. Google's contribution is to make that identity split central to the product narrative.
What does idle checkpointing change for AI automation agents?
Most agents spend large stretches waiting: for a model response, for a user decision, or for an external system. Google says Agent Compute Engine checkpoints idle microVMs to zero active resources and resumes them from snapshots when the next tool call arrives.
If that works as described, the operational effect could be significant. AI automation agents are expensive when teams provision them like always-on application workers. They become more economical when the runtime can preserve state while dropping active compute use close to zero.
Google has not published the key ACE figures, but it has published numbers for the open-source sibling, Agent Substrate on GKE. Those figures include up to 10x higher compute density than traditional compute, 500 activations per second, under 500 ms suspend-resume latency, and more than 1,000 dormant agents per host in a 200,000-agent benchmark.
Those are useful directional signals, not direct proof points for Agent Compute Engine itself. Still, they suggest where the economics of AI agent development may move next: fewer long-lived workers, more resumable sessions, and more reliance on copy-on-write memory sharing plus prewarmed snapshots.
How does Agent Compute Engine compare with AgentCore, Azure, and E2B?
The comparison is less about raw feature parity and more about what each platform chooses to disclose.
| Platform | Isolation model | Idle handling | Credentials in sandbox | Availability |
|---|---|---|---|---|
| Google Agent Compute Engine | Cloud Hypervisor microVM per session | Checkpoint to zero active resources | None, according to Google | Preview in coming months |
| Google Agent Substrate | Cloud Hypervisor microVM or gVisor | Snapshot and free CPU/RAM | Via egress proxy pattern | GKE non-production, GA allowlist |
| AWS AgentCore Runtime | Dedicated microVM per session | Consumption billing spans active and idle periods until termination | Managed by AgentCore Identity | Available |
| Azure dynamic sessions | Hyper-V sandbox | Session pool with prewarmed ephemeral environments | Not clearly disclosed | Multi-region availability |
| E2B | Firecracker microVM | Pause preserves files and memory | Not clearly disclosed | Available |
Google's strongest differentiator is the explicit claim that no backend credentials live inside the sandbox. Its weakest point today is product uncertainty. Buyers still do not have pricing, boot metrics, or a firm preview date. By contrast, E2B's documentation is clearer on resume behavior, and AWS is clearer on general availability.
What should enterprise teams validate before adopting this model?
Three questions matter more than the launch headline.
First, which workloads actually need microVM isolation? High-risk browser use, code execution, and broad enterprise AI integrations are obvious candidates. Simple retrieval or form-filling flows may not justify the additional complexity.
Second, where should the policy boundary sit? The most important design decision may be less about model choice and more about where delegated authorization, token exchange, and outbound filtering occur.
Third, how much architecture should be built around a preview product? The prudent move is to test the pattern, not hard-code to every Google-specific detail. That means proving the value of workload identity, resumable sessions, and secretless sandboxes before committing to one vendor's runtime.
FAQ
What is Google Agent Compute Engine?
It is a Google Cloud compute service for AI agents that runs each agent session in its own hardware-isolated microVM. Google says the sandbox contains no credentials and can be checkpointed when idle, which makes the launch relevant to secure custom AI agents.
How is Agent Compute Engine different from containers?
Containers typically share a kernel and rely on software isolation inside a shared host environment. Agent Compute Engine places each session in a dedicated microVM with its own guest kernel, which is better aligned with untrusted code execution and enterprise AI security requirements.
Has Google published pricing or boot time?
No. Google has not published pricing, boot time, density, or an exact preview date for Agent Compute Engine. It has shared stronger benchmark data for Agent Substrate, but that is a related product rather than the managed service itself.
Why is the four-identity model important?
Because it separates the user, the delegated authorization, the sandbox workload identity, and the agent's own account. That split reduces the usefulness of any credential taken from inside the sandbox and makes AI API integration flows more auditable.
Should teams choose Agent Compute Engine or Agent Substrate first?
Teams that want a managed path may wait for ACE preview. Teams that want earlier experimentation or more control may evaluate Agent Substrate on Kubernetes first, especially for non-production testing of AI integration architecture.
Key takeaways
- Custom AI agents are starting to get purpose-built runtimes rather than being treated like ordinary app workloads.
- Google's main innovation is not only microVM isolation, but keeping useful credentials out of the sandbox entirely.
- Idle checkpointing could materially change the cost profile of AI automation agents if ACE approaches Substrate-level resume performance.
- The main trade-off is uncertainty: pricing, density, boot time, and preview timing are still not public.
- Enterprise teams should test the architectural pattern first, then decide whether the managed service is mature enough for production.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn