Zero Credentials in the Sandbox: What Google's Agent Compute Engine Changes About Agent Blast Radius

Why Blast Radius Is the Right Lens

Traditional service-to-service security assumes a bounded, auditable set of callers. An agent breaks that assumption, because the agent decides at runtime which tools to call and with what arguments, driven by a language model that an attacker may be able to steer through injected instructions in a document, an email, or an API response the agent reads.

That makes the credential the agent carries the single most important variable in the system's security. If the agent holds a long-lived API key scoped to an entire CRM, then a successful prompt injection does not just produce a bad answer — it hands the attacker the agent's full reach: read every contact, export every record, call every endpoint that key permits, for as long as the key is valid. The model's reasoning is the vulnerability; the credential is the blast radius.

The engineering question is therefore not only 'how do we stop prompt injection' (you reduce it, you do not eliminate it) but 'when a step is compromised, how little can it reach?' That is a question about credential design, and it has a ladder of answers.

What Agent Compute Engine Actually Is

Google Cloud announced Agent Compute Engine on 22 October 2026 at the Linux Foundation's AGNTCon + MCPCon event in San Jose. The reported design is that each AI agent runs in its own hardware-isolated micro virtual machine, each with its own guest kernel, built on Cloud Hypervisor. Google says the platform already runs its own Gemini agents and that a customer preview is planned; it has not announced pricing or a firm preview date.

The property worth the article is the credential posture. According to Google's materials and launch-week reporting, the sandbox is designed to hold no persistent credentials: short-lived service credentials are injected from outside the microVM rather than stored inside it, and idle microVMs can be suspended and later restored. In blast-radius terms, that means a prompt injection running inside the sandbox has no long-lived key to exfiltrate, because one was never placed within its reach.

Treat the specifics as vendor-reported and pre-release — they may change before general availability. What does not depend on any one vendor is the underlying design pattern, which you can adopt today regardless of where your agents run. Google also open-sourced a related Kubernetes runtime, Agent Substrate, aimed at running large numbers of agents at high density and framework-agnostic across runtimes such as ADK, LangChain and Claude Code; its density figures are Google's own and are best treated as such.

The Credential-Scoping Ladder

The Broker Pattern, Illustrated

# Illustrative and vendor-neutral. This is NOT Agent Compute Engine's API
# (that product is in preview); it shows the design property the product
# embodies, and which you can apply on any runtime today.
#
# The agent never holds a long-lived secret. It asks a broker for a
# short-lived, least-privilege token for ONE specific action. Per-agent
# runtime isolation (e.g. a microVM per agent) is complementary: it keeps
# even that short-lived token out of a process other agents could read.

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone


@dataclass(frozen=True)
class ScopedToken:
    value: str
    scope: str              # e.g. "crm:contacts:read"
    expires_at: datetime


class CredentialBroker:
    """Holds the long-lived secret OUTSIDE the agent and mints short-lived,
    least-privilege tokens on demand. The agent calls this; it never sees
    the root credential."""

    def __init__(self, allowed_scopes: set[str]):
        self._allowed_scopes = allowed_scopes

    def issue(self, scope: str, ttl_seconds: int = 300) -> ScopedToken:
        if scope not in self._allowed_scopes:
            raise PermissionError(f"scope '{scope}' not permitted for this agent")
        # In production, exchange the root secret for a scoped, short-lived
        # token here (STS AssumeRole, Workload Identity, OAuth token exchange).
        # The root secret stays in the broker, never in the agent.
        token_value = mint_from_secret_manager(scope, ttl_seconds)
        return ScopedToken(
            value=token_value,
            scope=scope,
            expires_at=datetime.now(timezone.utc) + timedelta(seconds=ttl_seconds),
        )


def agent_step(broker: CredentialBroker) -> None:
    # The agent requests exactly the access this step needs, nothing more.
    token = broker.issue("crm:contacts:read", ttl_seconds=120)
    # ... make a single scoped call with `token`; it expires in two minutes ...
    # A prompt injection that hijacks this step cannot exfiltrate a long-lived
    # key, because one was never within the agent's reach. At most it gets a
    # 2-minute, read-only contacts token — a narrow, expiring compromise.
    _ = token

The broker pattern keeps the long-lived secret outside the agent and mints short-lived, least-privilege tokens per action. Per-agent runtime isolation (such as a microVM per agent) is complementary — it keeps even the short-lived token out of a process other agents share. `mint_from_secret_manager` is a provider-specific helper (STS, Workload Identity, or an OAuth token-exchange endpoint).

What to Do Now, Regardless of Runtime

• Inventory every credential your agents hold and classify each by rung. Any agent that reads untrusted input while holding a long-lived, broadly-scoped key (rung 1) is your highest-priority fix.
• Narrow scopes to least privilege (rung 2): read-only where the agent only reads, one data domain rather than the whole account, per agent role rather than one shared service account.
• Move to short-lived tokens (rung 3) via your identity provider's token exchange or workload identity, so a stolen credential expires in minutes rather than persisting until manual rotation.
• Adopt the broker pattern (rung 4) for the most sensitive actions, so the agent never holds the root secret and at most carries one in-flight scoped token.
• Treat per-agent runtime isolation (rung 5) — whether Agent Compute Engine when it is generally available, or a microVM/gVisor sandbox you run yourself — as the substrate that makes the rungs above hold under a real compromise, not as a replacement for them.
• Document the blast radius of each agent role explicitly: if this agent were fully compromised mid-step, what is the worst reachable action? That single sentence per role drives the scoping decisions above.

How Inductivee Approaches Agent Credentials

We treat the credential-scoping ladder as a design decision made before any agent code is written, not a hardening pass afterwards. Every agent role gets an explicit blast-radius statement — the worst reachable action if the role were fully compromised mid-step — and that statement sets the scope, the token lifetime, and whether a broker sits between the agent and the secret. Per-agent isolation, where the deployment target supports it, is the substrate we build that on, not a substitute for it.

This is the same discipline we apply to prompt-injection defence and tool-permission scoping in our agentic security threat model: assume the model can be steered, and engineer the system so that a steered step reaches as little as possible. If you are deploying agents against real systems and want that reviewed before it ships, that is a conversation worth having early — credential design is far cheaper to get right before launch than to retrofit after an incident.

Sources & Further Reading

• Google Cloud — Agent Compute Engine deep dive (official blog)
• The Decoder — Agent Compute Engine gives every Gemini agent its own hardware-isolated microVM
• The New Stack — Google's Kubernetes AI agent runtime (Agent Substrate)