The Gap Google’s Controls Do Not Close
Google’s Gemini Enterprise Agent Platform is now part of the Gemini Enterprise Agent Platform, and enterprises are moving production agents onto it fast. The platform is capable and the deployment experience is polished. But there is a security gap that Google’s own native controls do not close, and it sits exactly where the risk is highest.
Gemini Enterprise Agent Platform runs agents in a Google-managed tenant project. That is by design, and it is a good default for simplicity. But it means the agent’s tool calls, remote MCP connections, and any calls to non-Gemini model endpoints are indistinguishable on the wire from legitimate work, with no inline enforcement point your security stack can observe. This posture creates two attack vectors:
Egress to attacker infrastructure when a prompt injection or compromised dependency redirects the agent: in other words, an open door for data exfiltration.
Lateral movement to adjacent workloads if the agent's spoke can reach the rest of the fabric: in other words, an open door to the rest of your network and its data.
Shutting down these attack vectors is a containment issue, not a question of how quickly you can detect malicious activity. When prevention fails and detection is too slow, containment decides whether the incident becomes a catastrophic breach. Google offers three controls that address adjacent concerns:
VPC Service Controls stops Google-to-Google data exfiltration. It is blind to an agent calling api.openai.com or any non-Google host.
Model Armor and Agent Gateway inspect prompts and model responses at the request boundary. They do not govern third-party tool calls on the wire.
Secure Web Proxy does FQDN allow-listing and is a real, capable control.
But it is GCP-only and per-region, with its own console and policy language. If you run agents on more than one cloud platform, it does not follow them.
None of these is the network egress firewall for non-Google destinations across your whole estate. If an agent is prompted into calling an attacker-controlled endpoint, or if a compromised dependency redirects a tool call, there is no default control that stops the socket from opening. That is an ungoverned Blast Radius.
What the Validated Containment Architecture Delivers
Aviatrix has shipped a Validated Containment Architecture for Gemini Enterprise Agent Platform to empower you to use this AI platform securely. It is the Gemini-specific instantiation of AgentGuard, the Containment Platform for AI agent workloads, and it ships as part of the eight-in-eight Validated Containment Architectures program: a lab-tested, Terraform-deployable blueprint with every component needed to go from a fresh GCP project to enforced containment in under 45 minutes.
The architecture works in two deployment shapes:
The managed runtime shape fronts the Agent Engine’s managed runtime with a Private Service Connect interface (PSC-I). All non-Google agent egress leaves the tenant project through that PSC-I network attachment into a customer VPC, where the Aviatrix gateway inserts transparently at Layer 3. The agent makes the same outbound calls it always made. There is no HTTPS_PROXY setting, no SDK change, and no redeploy. The gateway is transparently in path, performing NAT and acting as a transparent forward proxy. The containment policy enforces at the network layer, not inside the agent.
The GKE shape targets a GKE-hosted custom Agent Development Kit (ADK) runtime. It uses Aviatrix Kubernetes SmartGroups keyed to pod identity and adds selective transparent TLS decryption for URL-path enforcement.
Both shapes run under one Distributed Cloud Firewall policy model, in one CoPilot dashboard.
How this Validated Containment Architecture Complements Your Security Stack
The AI agent landscape is irreducibly diverse. No enterprise ends up on a single agent platform: they run Bedrock AgentCore and Gemini Enterprise Agent Platform and Foundry and a half-dozen self-hosted frameworks on Kubernetes, and they adopt a new one every quarter. Each ships its own native egress story — VPC Service Controls and Secure Web Proxy on Google, something different on every other cloud — and securing that with a per-platform firewall means a different policy engine, audit trail, and enforcement primitive for every agent type.
Validated Containment Architectures give enterprises the opposite: one control plane, one policy model, and one audit log across every agent platform and framework, proven per platform. This Validated Containment Architecture brings that consistency to Google's managed agent runtime; the pattern is the same every Friday: a new agent platform, the same containment.
The Policy Pack
The baseline Distributed Cloud Firewall policy pack enforces three things that Google’s native controls do not:
Default-deny egress. Every agent starts denied. Only explicitly approved tool destinations, MCP servers, and RAG endpoints are reachable. A WebGroup allow-list defines those destinations; everything else is blocked and logged.
A named shadow-model deny. The pack ships a vca-vertex-shadow-model-deny rule placed ahead of the tool allow-list. It denies and logs any attempt to reach api.openai.com, *.anthropic.com, api.mistral.ai, or *.perplexity.ai, and any other non-sanctioned model provider your governance names. VPC Service Controls does not see these destinations. This rule does. Every blocked attempt is visible in CoPilot FlowIQ with a human-readable rule name.
East-west isolation. SmartGroup deny rules between the agent spoke and every other spoke in the fabric contain lateral movement. If a prompt injection or supply-chain compromise redirects an agent, the Blast Radius stops at the spoke, not at the edge of the enterprise.
On the GKE shape, a UDP/53 deny blocks DNS-tunneled exfiltration, and selective transparent TLS decryption scoped tightly to a destination FQDN SmartGroup enables URL-path filtering. The scenario set in the blueprint proves this side-by-side: a compromised supply-chain path on raw.githubusercontent.com is blocked while a legitimate path on the same host returns HTTP 200.
What the Architecture Proves
The scenario set in the blueprint runs against the OWASP LLM Top Ten and MITRE ATLAS in a live deployment.
Prompt injection driving tool-abuse exfiltration is closed by default-deny on the attacker domain. DNS-tunneled exfiltration to external resolvers is closed by the UDP/53 deny. Supply-chain compromise where a sanctioned host serves both clean and poisoned paths is closed on the GKE shape by selective TLS decryption and a URL-filter deny. An agent reaching an unsanctioned model endpoint, what OWASP LLM08 calls excessive agency, is closed by the named shadow-model deny rule. Every blocked flow is visible in CoPilot FlowIQ.
The compliance evidence is continuous. CoPilot’s per-connection logs are the audit trail that the control is operating. The same policy model and log format apply whether the agent runs on Gemini, AgentCore, or your own cluster, so auditors see one control, not one per platform.
How to Get Started
The VCA is available now. The Terraform blueprint, the Solution Brief, Security Architecture Brief, and Technical Brief ship together. Aviatrix Distributed Cloud Firewall customers on Controller 8.1 or later can deploy the SNI and domain baseline today. Selective TLS decryption, URL-path filtering, and egress IDS/IPS require Controller 9.0.
Request an architecture review to see the Validated Containment Architecture for Gemini Enterprise Agent Platform.
Learn about Validated Containment Architectures for other AI platforms.
Frequently Asked Questions
It is a lab-tested, Terraform-deployable blueprint that puts Vertex AI agents behind a default-deny network boundary. It ships with a Distributed Cloud Firewall policy pack, SmartGroup East-West isolation, and a named shadow-model deny rule. The full blueprint, architect guide, and Terraform code are included. Customers on Controller 8.1 or later can deploy the baseline in under 45 minutes.
Each Google control addresses a different problem. VPC Service Controls blocks Google-to-Google exfiltration but is blind to non-Google hosts. Model Armor inspects prompts, not third-party tool calls on the wire. Secure Web Proxy does FQDN allow-listing but is GCP-only and per-region. None of them is the network egress firewall for non-Google destinations across your whole estate.
The policy pack closes two vectors across both deployment shapes: prompt injection driving data exfiltration to an attacker domain, and excessive agency where an agent calls an unsanctioned model provider such as OpenAI or Anthropic. On the GKE shape, two additional vectors are closed: DNS-tunneled exfiltration via UDP/53, and supply-chain compromise where a sanctioned host serves both clean and malicious content. All blocked flows are visible in CoPilot FlowIQ.
No. The managed runtime shape inserts transparently at Layer 3 through a Private Service Connect interface. The agent makes the same outbound calls it always made. There is no HTTPS_PROXY setting, no SDK change, and no redeploy. Enforcement happens at the network layer outside the agent, not inside it.
Yes. The same Distributed Cloud Firewall policy model, SmartGroups, WebGroups, and CoPilot audit log apply across Vertex AI Agent Engine, Bedrock AgentCore, Azure AI Foundry, and self-hosted Kubernetes agent frameworks. One control plane, one policy model, one audit log regardless of which platform the agent runs on.
Ready to see Aviatrix in action?
Get a personalized live demo walkthrough or explore our latest deep-dive cloud threat research intelligence.
