BENGALURU, India, June 28, 2026, 12:40 p.m. IST – Google Cloud has added new VPC Service Controls capabilities aimed at agentic AI workloads, a move that brings one of cloud security’s older perimeter ideas closer to the way modern AI agents call tools, read enterprise data and trigger actions across business systems.
The company said on June 27 that VPC Service Controls now supports agent identities in directional perimeter rules, conditional controls for Model Context Protocol tool use, and native integration with the Gemini Enterprise Agent Platform. For developers, DevOps engineers and platform teams, the practical signal is clear: production AI agents are becoming infrastructure subjects that need identities, network boundaries, tool policies and audit paths, not just prompt guidelines.
The announcement is especially relevant because agentic systems are moving from chat interfaces toward delegated workflows. An agent that can search documents, call APIs, open tickets or send email has a different risk profile from a chatbot that only drafts text. Google Cloud is positioning VPC Service Controls as one layer for reducing data-exfiltration and over-permissioning risks when those agents operate inside Google Cloud environments.
What Google Cloud Confirmed
In its official Cloud Blog post, Google Cloud said administrators can add agentic identities directly to VPC Service Controls ingress and egress rules using standard IAM principals. A single principal can map to an individual agent, while a principalSet can represent a broader fleet. The company said this lets teams apply consistent access policies and revoke perimeter access if an agent is compromised.
Google also said VPC Service Controls can now use MCP-related attributes for conditional access decisions. The blog names attributes including mcp.toolName, mcp.method and mcp.tool.isReadOnly, while related Google Cloud MCP documentation describes controls such as mcp.is_mcp, mcp.tool.is_read_only and the OAuth client ID of the agent principal. The implementation detail matters: teams should verify the exact attribute names and policy surfaces they use before rolling this into production.
The third confirmed change is integration with the Gemini Enterprise Agent Platform. Google Cloud said that when Agent Platform is included as a protected service within a VPC Service Controls perimeter, public internet access to the Agent Platform instance is blocked automatically.
Why It Matters For DevOps Teams
VPC Service Controls is not a new security product, but applying perimeter rules to AI agent identities and tool calls is a notable shift. Google’s VPC Service Controls documentation describes the service as a way to create perimeters around specified Google Cloud services and reduce accidental or targeted data-exfiltration risks from services such as Cloud Storage and BigQuery. Agentic AI increases the importance of that model because agents can combine retrieval, reasoning and action in a single workflow.
For platform teams, the immediate work is inventory. Teams need to know which agents exist, which MCP servers or tools they can call, which data stores they can reach, and whether each tool call is read-only or capable of changing state. That inventory should then map to IAM, VPC Service Controls, logging, approval workflows and incident response procedures.
This also raises the bar for LLMOps and CI/CD practices. Agent policies should be reviewed like infrastructure policy, tested before release, and monitored after deployment. If a team already maintains policy-as-code for cloud resources, agent identity and tool-access rules should become part of the same release process rather than a separate console-only configuration.
The Security Context
The announcement lands amid growing concern about prompt injection, sensitive information disclosure and excessive agency in generative AI systems. The OWASP Top 10 for LLMs and Generative AI Apps lists those risks among the major issues for teams building and operating AI applications.
Perimeter controls do not eliminate prompt injection. They also do not replace application-level authorization, data classification, output validation or human approval for high-impact actions. Their value is narrower and more operational: if an agent is tricked, compromised or misconfigured, the surrounding infrastructure policy can limit which services it can reach and which actions it can perform.
What Teams Should Do Next
Teams running AI agents on Google Cloud should start by separating experimental agents from production agents. Production agents should have explicit owners, unique identities, minimal permissions, logging coverage and documented rollback or revocation steps.
Teams using retrieval-augmented generation should also revisit how agents reach vector databases, document stores and business systems. GravityDevOps readers working on RAG systems should treat retrieval permissions as part of the production security model, not just an application feature. The same is true for teams building prompt workflows; prompt engineering can reduce mistakes, but it cannot substitute for cloud controls around tools and data.
For DevOps groups, the safest rollout pattern is incremental: create a small set of read-only agent paths first, test blocked write paths, add alerts for denied calls, and require explicit approval for agents that can mutate data, send messages or change infrastructure. The controls should be validated in the same release discipline used for CI/CD tooling and other production automation.
Balanced Read
The Google Cloud update is useful because it translates agent risk into infrastructure controls that cloud teams already understand. It also confirms that MCP and agent identity are becoming governance points for enterprise AI, not just developer conveniences.
The limitation is scope. These controls are most relevant to teams already using Google Cloud services, VPC Service Controls, MCP servers or Gemini Enterprise Agent Platform. Multicloud teams will still need equivalent controls across AWS, Azure, SaaS APIs and self-hosted tools. Teams should also expect the MCP policy model to keep evolving as vendors standardize agent-to-tool integration patterns.
Questions Platform Teams Should Ask
Does this make AI agents safe by default? No. It adds enforceable perimeter controls, but agent safety still depends on identity design, authorization, logging, model behavior, tool design and human review for sensitive actions.
Is MCP now mandatory for agent governance? Not necessarily. The announcement shows MCP becoming an important control surface, but many production agents also use direct APIs, workflow engines and SaaS connectors. Those paths need the same least-privilege review.
What is the first practical step? Build an agent inventory that lists each agent identity, tool, data source, read or write capability, owner and production approval status. Without that map, perimeter rules are easy to misconfigure.
Sources: Google Cloud’s June 27 announcement on VPC Service Controls for agentic AI, Google Cloud VPC Service Controls documentation, Google Cloud MCP perimeter-control documentation, Google Cloud Agent Identity documentation, and the OWASP Top 10 for LLMs and Generative AI Apps.
