In May 2026, InfoQ published Google Announces GKE Agent Sandbox and Hypercluster at Next ‘26, Positioning Kubernetes as AI Agent Runtime, covering the announcements of GKE Agent Sandbox and Hypercluster at Google Cloud Next '26. In this strategic update positioning Kubernetes as the "standard runtime for AI agents," an end-to-end foundation covering multi-tenancy, isolated execution, and GPU pooling was established.
In our custom AI agent projects, requests to "safely isolate and operate agents for multiple clients on a single infrastructure" are increasing. In this article, we outline the architectural design, billing separation, and SLAs for building an agent platform for client projects using GKE Agent Sandbox and Hypercluster.
What has changed — Kubernetes built for agents
GKE Agent Sandbox and Hypercluster are two mechanisms optimized not for "generic container workloads," but for "requirements unique to AI agents."
| Features | Details | Value in custom development projects |
|---|---|---|
| Agent Sandbox | Enforced agent-level isolation | Secure isolation between clients and between agents |
| Hypercluster | Multi-cluster GPU pooling | Dynamic allocation of GPU inventory across projects |
| Lifecycle Hook | Standardized agent initialization and termination | Integrated cost accounting and audit logging |
| Resource Quota | Limits on GPUs, tokens, and APIs | Per-client billing separation |
| Audit by Default | Audit logs for all agent executions | Meets deployment requirements for regulated industries |
In particular, "Agent Sandbox" is a mechanism for designing "behavioral boundaries per agent" rather than "security per Pod." Incidents that previously required custom safeguards—such as "the filesystem being breached via prompt injection"—are now absorbed as platform standards.
This represents the cloud provider standardized version of the "agent isolation in K8s" concept covered in Safely Operating Autonomous AI Agents on Kubernetes, creating a structure that cuts in-house Pod Security Policy design effort by two-thirds.
The four tiers of a "multi-tenant agent platform" built in custom development
When building a client agent platform leveraging GKE Agent Sandbox and Hypercluster, the tiers can be organized as follows.
[Tier 1: Hypercluster (GPU / 計算リソース基盤)]
├ 複数 GKE クラスタを横断
├ GPU をプール → 案件横断で動的配分
└ Spot / Preemptible で 50〜70% コスト削減
[Tier 2: Tenant Cluster (案件 = テナント)]
├ 案件ごとに論理的なテナント
├ Resource Quota で GPU / トークン / API 上限
└ 課金タグで請求分離
[Tier 3: Agent Sandbox (エージェント = サンドボックス)]
├ 各エージェントを強制隔離
├ ネットワーク / FS / API スコープを制限
└ prompt injection 対策をプラットフォーム任せ
[Tier 4: Workload (実行単位)]
├ MCP サーバー / Tool / RAG パイプライン
├ 短命 Job として実行
└ Lifecycle Hook で監査ログ送信Specifically, Tier 1 Hypercluster directly addresses the specific need in custom development to "deliver client projects without having to maintain a dedicated GPU inventory." Even when handling ten mid-scale client projects that each use only 100 hours of GPU per month, dynamically allocating resources from a pool keeps overall GPU utilization high.
Billing separation — Enabling client-specific billing in custom development
The most difficult challenge in a multi-tenant platform is isolating "who used what and how much." With GKE Agent Sandbox, this can be tracked across the following three dimensions.
| Metric | Collection method | Impact on client invoicing |
|---|---|---|
| GPU usage hours | Hypercluster usage logs | Hourly rate × usage time |
| Token consumption | Lifecycle hook + audit logs | Per-model rate × tokens |
| API calls | Sandbox network logs | Grouped by external API vendor |
| Storage | PVC / object storage | GB × retention period |
| Data transfer | Egress logs | Cross-project traffic |
In particular, "data transfer" is easy to overlook in custom development; in projects handling massive embedding vectors via RAG, there are cases where egress charges exceed GPU costs.
This can be viewed as extending the "billing visibility" covered in GitHub Copilot Metered Billing and Token Consumption Governance down to the infrastructure layer.
"Multi-tenant clauses" to include in client contracts
Here are the clauses to include in contracts when operating GKE Agent Sandbox and Hypercluster in custom development projects.
| Clause | Details | Client alignment points |
|---|---|---|
| Tenant boundaries | Definition of 1 client = 1 tenant | Handling of subsidiaries and departments |
| Isolation guarantees | No inter-sandbox communication allowed | Exception request workflow |
| GPU priority | Tiering into high priority, standard, and spot | Degradation order during failures |
| Billing transparency | Correspondence between measured items and invoices | Monthly reporting format |
| Incident SLA | Response protocol when a single tenant is affected | Remediation protocol when isolation is breached |
In particular, if "GPU priority" is not clearly articulated upfront, disputes will arise when GPU inventory becomes tight and clients demand "prioritize our project." Stating pricing differences across three tiers—Spot, Standard, and High Priority—in the contract and letting clients choose ensures operations remain sustainable.
Five common pitfalls
Pitfall 1: Defining tenant boundaries using "only Namespaces"
Namespace isolation does not cover all aspects of networking, filesystems, and IAM. Always combine it with enforced isolation via Agent Sandbox.
Pitfall 2: Forgetting disaster recovery design for Hypercluster
While Hypercluster spans multiple GKE clusters, an architecture where a total outage in a single region halts all client projects is dangerous. Incorporate a multi-region design from the outset.
Pitfall 3: Lenient enforcement of billing tags
If tagging per agent is optional, "unidentified GPU charges with unknown project attribution" will inevitably emerge at month-end. Enforce an admission policy that denies launches without tags at Tier 2.
Pitfall 4: Forgetting to transmit audit logs via lifecycle hooks
If you don't implement hooks for agent start and termination, audit logs will end up with gaps. Enforce no hook = launch rejected via admission policy.
Pitfall 5: Compromising production quality by using Spot instances
Using "Spot instances for cost reduction" leads to incidents where preemptions abruptly cut off conversations. Restrict Spot instances exclusively to non-interactive batch jobs, and assign standard nodes to conversational agents.
Conclusion — Shifting from "building from scratch" to "delegating to the platform"
With the arrival of GKE Agent Sandbox and Hypercluster, the choice to "build an agent platform from scratch" has shrunk to "only when there is an explicit reason to do so." In an era where multi-tenancy, isolation, and GPU pooling can be absorbed by platform standards, custom development providers should shift their value from "building infrastructure" to "operational and contract design."
In multi-tenant agent platforms, configurations and required effort vary significantly based on how tenant boundaries are drawn, GPU reservation strategies, and audit requirements. If you are considering "safely isolating and operating multiple clients' agents on a single platform" or "running custom development projects without holding GPU inventory," we provide individualized estimates after reviewing your specific requirements. Feel free to reach out via our contact form.
