The next sovereign question
For years, organizations with the strictest data requirements faced a real compromise: adopt frontier AI, or protect their data. Pick one. With Google’s Gemini models available on Google Distributed Cloud, that compromise is over. Intelligence agencies, defense programs, regulated financial institutions, and public sector organizations can now run Google's most advanced AI models entirely within their own environments, including environments that never touch the public internet.
Solving the model question surfaces the next one. Organizations deploying Gemini models on Google Distributed Cloud aren't stopping at prompts and chat interfaces. They're building agents: software that reasons over confidential data, calls tools, coordinates with other agents, and acts on mission-critical systems. Every sovereignty question already answered for models repeats at the agentic layer. Where do agents run? What can they access? Who governs the tools they call? How is their behavior observed and audited, in an environment that by design has no connection to any external control plane?
This post is about how kagent and agentgateway extend sovereignty up the stack, to the agents, models, and tools running on top of Google Distributed Cloud, as open source projects under neutral governance.
Google Distributed Cloud: the sovereign foundation
With Google Distributed Cloud, the hardest problem in sovereign AI, running frontier models fully disconnected, is solved. The question for platform teams now is what to build on top of it.
From models to agents
A model endpoint answers questions. An agentic platform puts those answers to work. As organizations move from experimentation to production agents, a familiar set of operational questions arrives, the same ones platform teams asked a decade ago when microservices replaced monoliths.
- Lifecycle: How do you create, version, deploy, and retire agents with the same rigor as any other workload?
- Model connectivity: How do agents leverage Gemini alongside locally hosted open models through one consistent interface?
- Tools: How do you deploy MCP tool servers, control which agents can call which tools, and keep that inventory curated?
- Identity and access: When an agent acts on behalf of a user, how is that identity established, propagated, and enforced?
- Communication: How do agents discover and talk to each other securely?
- Observability and evaluation: How do you see what agents are doing, measure whether they're doing it well, and produce the audit trail accreditation requires?

Kubernetes answered these questions for microservices, and it's the foundation Google Distributed Cloud customers already run and have already accredited. The agentic era calls for infrastructure that extends that same operational model to agents.
kagent and agentgateway: the agentic layer

kagent is a CNCF project that makes agents first-class citizens of Kubernetes. Agents, model configurations, and tools are declarative resources, managed with the same kubectl and GitOps workflows Google Distributed Cloud platform teams already operate. kagent installs as a Kubernetes-native controller, so it extends the platform teams already run rather than introducing a separate operational model to learn. Lifecycle, RBAC, human-in-the-loop consent, and end-to-end tracing are built in, and governance is inherited from the Kubernetes foundation already approved to run in the environment.
kagent's agent catalog gives teams a curated starting point: prebuilt agents for common operational tasks, plus the ability to publish their own agents for reuse across teams. In a disconnected environment, where developers can't browse the open internet for examples and integrations, a locally available catalog shortens the path from idea to running agent considerably.
Tools follow the same pattern. MCP tool servers are declarative resources with their own lifecycle, deployed, versioned, and retired alongside the agents that use them. Teams start from prebuilt community servers for common integrations, build their own, or register MCP servers they already run. That last case matters most in a disconnected environment, because an organization's most valuable tools are usually the ones wrapping its own internal systems, and those were never in a public registry to begin with. agentgateway then enforces which agents can call which of those tools at runtime.
On the model side, kagent connects agents to Gemini endpoints on Google Distributed Cloud and to locally hosted open models through the same declarative configuration. Teams choose the right model per agent and per task without changing how agents are built or operated.
agentgateway, part of the Agentic AI Foundation (AAIF) under the Linux Foundation, is a data plane purpose-built for agentic traffic. It provides a single enforcement and observability point for the three traffic patterns that define agentic systems: agent-to-LLM, agent-to-tool over MCP, and agent-to-agent over the Agent2Agent (A2A) protocol. Through that one control point, platform teams apply authentication and authorization, tool-level access policy, rate limits and token budgets, and consistent telemetry.
Model estates in sovereign environments are rarely uniform. A production deployment might route sensitive reasoning to Gemini models on Google Distributed Cloud while running lighter or specialized tasks on local open models. agentgateway applies the same policy and produces the same telemetry regardless of where the call lands, so governance doesn't fragment across model providers.
Everything here runs in-cluster. kagent and agentgateway have no SaaS control plane dependency and require no external connectivity to function, the difference between software that works on premises Data and operational sovereignty come from Google Distributed Cloud. Software sovereignty comes from the agentic layer being open source under neutral governance, agentgateway part of the Agentic AI Foundation under the Linux Foundation, kagent in the CNCF. The code is auditable, the projects are community-governed, and the stack stays as portable and vendor-neutral as the infrastructure beneath it.
Google recently open-sourced a related project, Agent Substrate, which addresses agent execution density and isolation. kagent already supports it, though the combination isn't yet part of the validated Google Distributed Cloud architecture described here, and we'll cover it in a dedicated post as that work matures.
Validated deployments
Solo.io collaborated with Google Cloud on kagent and agentgateway deployment across Google Distributed Cloud components. On Google Distributed Cloud air-gapped, kagent and agentgateway deploy to standard clusters and connect to Gemini models running entirely on-premises. For Gemini models on Google Distributed Cloud connected API, both deploy to a Kubernetes cluster outside the Google Distributed Cloud connected hosting Gemini model and consume Gemini capabilities through its local endpoint.
Deployment guides cover each of those configurations. To get them for your environment, reach out to the Solo.io team or your Google Cloud representative.
Both kagent and agentgateway are available through the Google Cloud Ready - Distributed Cloud Initiative, giving Google Distributed Cloud customers a supported path to deploy a full agentic layer alongside the platform they already operate.
Looking forward
Solo.io’s direction from here is straightforward: deepening integration across the Google Distributed Cloud portfolio and expanding the set of jointly validated patterns as more organizations bring agents into sovereign environments.
If you're one of them, start with what's already open. Because kagent and agentgateway are open source, your team can evaluate the entire agentic layer inside your own environment, fully disconnected, with no external dependency. When you're ready for production, the Google Distributed Cloud Marketplace is the supported path. To go deeper on architecture or validation for your environment, reach out to the Solo.io team or your Google Cloud representative.









%20(1).png)



















%20a%20Bad%20Idea.png)








