At Gemini at Work 2026 this week, Google Cloud made two announcements that belong in the same breath but rarely get covered together. The first is flashy: the Gemini agent, a single “universal agent for work” that answers questions, does knowledge work, generates media, and writes and runs code — all from one prompt box. The second is the unglamorous plumbing that makes the first one enterprise-safe: the Google Gemini Agent Gateway — not new this week (it debuted at Google Cloud Next '26 in April and went GA in June), but newly front-and-center in the story — a security enforcement point that natively parses agent-protocol traffic rather than just filtering packets at the network layer.
The agent is the headline. The Gemini agent gateway is the story that could matter more.
What shipped: the Gemini agent and the Enterprise Agent Platform
Writing in the Gemini at Work keynote post on cloud.google.com, Google Cloud CEO Thomas Kurian described the new product plainly: the Gemini agent is “your new single, universal agent for work. It has all of your business context and can be used for everything from knowledge work to answering questions, and from content creation to coding, all from a single prompt box. It plans the work, uses skills and tools, connects to your systems, and brings back something finished.”
That “brings back something finished” framing is the core pitch. You don’t prompt — you delegate. You hand Gemini an objective, and it plans the steps, picks the model for each step, invokes the tools it needs, and returns a completed artifact into the inbox, document, or IDE where the work already lives.
One agent, one API, every surface
Google’s post lays out the architecture around a few pillars:
- Unified agent. Chat, autonomous task execution, and code generation live in one interface. You can assign work, schedule tasks, or trigger it from events.
- Omnipresent access. It’s reachable from web, iOS and Android, Windows and Mac desktops, and channels including the command line, Google Workspace, Microsoft 365, and Slack. It also runs headless.
- Persistent execution. Because it runs in the cloud, it keeps one set of memories and one personalization graph across every device — and long-running tasks keep going after you close your laptop.
- Multi-agent orchestration. Gemini can spin up temporary, job-specific sub-agents, each with its own identity, to tackle multi-step work. It can also act as a “coworker agent” — a persistent team member with a dedicated identity, its own
@agents.company.comemail, its own storage, and access only to the context you explicitly share.
That coworker-agent detail is easy to skim past and worth pausing on. An AI participant with its own Workspace account, calendar, and directory presence stops being a feature and starts being a colleague — with everything that implies for security teams.
Model choice is deliberately decoupled
Kurian’s post is explicit that “Gemini is the agent, and the model underneath it is a separate choice.” It currently orchestrates across Google’s Gemini family and Anthropic’s Claude models, with more planned — see our coverage of the Gemini 4 Argon launch and the Fairwind Cyber Defenders for the model side of that story. The economics argument is real: PayPal routes 10 million multi-model requests every week, and sportswear brand On tested the dynamic selection capability to speed its time-to-market.
The Gemini agent sits on the Gemini Enterprise Agent Platform, the evolution of Vertex AI that Google launched in April 2026 as the platform layer for building, scaling, governing, and optimizing agents. And the adoption numbers Google cited at the event are substantial: nearly 80% of all Google Cloud customers now use its AI products, nearly 90% of the Fortune 100 use Gemini Enterprise, and roughly 500 customers each processed more than one trillion tokens in the past year.
Note the availability picture, though. The Gemini agent is, per The Verge’s coverage of the event, currently only available to enterprise customers in private preview. Google’s consumer-side Gemini Spark agent launched in May, but the enterprise universal agent is gated behind private preview for now.
The Gemini Agent Gateway: why protocol-native security is the real headline
Here’s where it gets interesting for anyone who runs infrastructure.
Google’s documentation describes Agent Gateway as the “network entry and exit point for all agentic interactions” — the enforcement component of the platform’s Agent Governance suite. In Kurian’s keynote framing: “All traffic — in, out, and between agents — passes through Agent Gateway, an AI network firewall enforcing your organization’s policies in real time. You write the policy once, such as: ‘agents may not open documents classified Need to Know.’ Gemini applies it to every agent in your company instead of checking one agent at a time.”
That’s the pitch, but the mechanism is what separates this from a generic egress proxy.
What “protocol-native” actually means here
The key line from Google’s docs is this: Agent Gateway supports all HTTP-based traffic, including MCP and A2A traffic, but “For MCP traffic only, Agent Gateway can parse request data to extract attributes. This lets you create authorization policies with conditions based on those attributes. For example, you can create policies that restrict access to specific tools.”
Translation: the gateway doesn’t just terminate TLS and shuffle packets. It opens the JSON-RPC payload inside the HTTP body of an MCP request, extracts which method is being invoked and which tool is being called — tools/call, search_indicators, delete_instance, whatever it may be — and lets you write authorization rules against those protocol-level attributes.
Google’s codelab on the feature spells out the mechanics. MCP calls “typically use the JSON-RPC wire protocol format and HTTP transport. The details of the MCP method being invoked (eg, tools/call), the target tool name, and any arguments are contained within the JSON payload in the HTTP body.” The gateway parses that body and exposes attributes like iap.googleapis.com/mcp.toolName, which you can then use in Common Expression Language (CEL) conditions on IAM policies. A policy that allows an agent to call one read-only tool on a data server, but nothing else, looks like this:
1 | { |
Worth noting in that expression: the empty-string allow ('' in the list) isn’t arbitrary permissiveness. MCP protocol handshake methods (initialize, notifications/initialized, tools/list) carry no tool name, so the codelab includes '' to let those handshakes pass while every other tool stays blocked — call get_observations and you get an HTTP 403.
Even better: attributes like mcp.tool.isReadOnly, mcp.tool.isDestructive, mcp.tool.isIdempotent, and mcp.tool.isOpenWorld come from the tool’s own annotations, registered in the platform’s Agent Registry. So a security admin can write policy in terms of behavior — “agents may not call destructive tools against the production registry” — not just tool names.
The whole chain looks like this: every agent gets a cryptographically attested Agent Identity (a SPIFFE ID, secured with mTLS and DPoP). Outbound calls are intercepted by the gateway. The gateway checks the agent’s identity against IAM Unified Access Policies — which went GA on August 31 and are deny-by-default: all connections are blocked unless an explicit policy grants access. It verifies the destination exists in Agent Registry. Model Armor scans payloads for prompt injection and data leakage, and semantic governance policies can enforce plain-language business rules (“never run these two tools in combination”) at runtime. Only then does traffic move.
The honest fine print on A2A
One precision note, because the marketing shorthand tends to blur it: per the documentation, the deep, attribute-level protocol parsing described above applies to MCP traffic only. A2A (agent-to-agent) traffic is supported and secured at the Gemini agent gateway, but it operates there at a minimum as a secure passthrough — traffic is terminated and routed, with policy applied around it, rather than decomposed field-by-field the way MCP tool calls are. If you’re evaluating this for A2A-heavy agent swarms, that distinction matters.
A practical detail ops teams will appreciate
Google’s codelab shows a DRY_RUN mode where the gateway evaluates and logs every authorization decision without blocking traffic, so you can shadow-deploy governance before flipping to ENFORCED mode — where unauthorized requests get an HTTP 403. Roll agent controls out like you’d roll out a firewall change: observe, then enforce.
Also worth knowing: each gateway instance governs up to 5,000 resources registered in Agent Registry, and since September, Agent Gateway enforces VPC Service Controls perimeters for agent traffic — meaning your existing data-exfiltration boundaries now apply to agents too.
Why it matters: agent traffic becomes governed infrastructure
The uncomfortable truth about enterprise AI agents is that nobody’s pilot-to-production gap is a model-quality problem. It’s a governance problem. An agent with direct network access, pointed at your Salesforce and your BigQuery, is one clever prompt injection away from exfiltrating a customer list — a scenario that stops being hypothetical when you read our recap of OpenAI’s misalignment incidents. Every security team that’s looked at MCP adoption has hit the same wall: the protocols that make agents powerful make them un-auditable at the network layer.
Google’s argument is that agent traffic deserves its own infrastructure category — with identity, registry, policy, and observability — rather than being squeezed into either API gateways or firewalls that can’t speak MCP. The codelab’s framing is blunt: governance should be “enforced at the platform level” instead of “relying on custom implementations unique to each application or agent code.”
The “first protocol-native agent gateway” framing is press, not Google: Forkast ran the headline “Google Cloud Ships the First Protocol-Native Agent Gateway” on forkast.news and called it “the first protocol-native agent gateway from a major cloud provider.” [UNVERIFIED as Google’s own claim: no fetched Google source uses the word “first,” and third-party coverage shows AWS and Microsoft building parallel agent-gateway capabilities, so treat the industry-first framing as Forkast’s characterization, not established fact]
Whether or not it’s technically a first, the strategic value is clear: whoever becomes the default control plane for agent ecosystems owns the most defensible layer of the stack. Models are interchangeable — Google’s own positioning says so, routing Gemini agent work across Claude as well as its own models. Gateways, registries, and identities are where lock-in actually lives, because they’re wired into your IAM, your VPC, and your audit trails.
And the pricing tells you how seriously Google is taking it. Agent Gateway egress is billed on Agent Compute at $0.085 per vCPU-hour (after a free 50 hours per month), with that rate corresponding to roughly 15,000 API calls or authorization requests processed through the Gemini agent gateway. Security enforcement isn’t a free sidecar — it’s a metered product line.
Ecosystem timing: Grok 4.6 on the platform, and the platform-neutral posture
Two surrounding data points sharpen the picture of where this is going.
First, Grok 4.6 from xAI is now generally available on Gemini Enterprise Agent Platform, per Google’s release notes — it crossed from preview to GA on September 18. Google’s agent layer is deliberately becoming a home for other vendors’ flagship models — a pattern with correlated-failure risks we examined in our analysis of the synchronized ChatGPT, Claude, and Grok outage — and its Model Garden already mixes in Meta and Anthropic models alongside its own.
Second, on the data side, SAP is part of the picture, though its data-product news isn’t from this event: SAP BDC Connect for BigQuery — the zero-copy pipeline for pulling SAP Business Data Cloud data into BigQuery — went GA on July 27, 2026, ten weeks before Gemini at Work. What the keynote does say about SAP is what matters for agents: “Whether your metrics live in Databricks, dbt, LookML, or SAP, Gemini reads them directly where they sit,” via Knowledge Catalog and the borderless Lakehouse. Read together, that’s the loop completed: agents governed by the gateway, calling MCP tools that query your SAP data products, grounded in your systems of record.
Read the two together and the posture is clear: Google isn’t selling “use Gemini models.” It’s selling “run any agents, on any models, against all your enterprise data — and we’ll govern all of it at the protocol layer.”
The industry specializations announced at the event push the same direction — Gemini for Financial Services and Legal are in preview, with Government, Healthcare, and Retail coming — and early customer results suggest the demand is real. Bloomberg Media’s CTO William Anderson put it this way in Google’s keynote post: “by grounding our AI in a trusted institutional context, we ensure confidence in the accuracy and quality of every insight generated.”
Competitive context and open questions
So where does this leave the field? Microsoft and AWS have been building their own agent governance stories in parallel, and the details of any head-to-head comparison are beyond what this announcement gives us to verify. [UNVERIFIED: fetched sources benchmarking or comparing Azure Foundry / AWS equivalent agent-gateway capabilities against Agent Gateway] What can be said is that Google’s design leans on components it already had reasons to build — SPIFFE workload identity from its service mesh heritage, Identity-Aware Proxy, VPC Service Controls — and repoints them at an agent-shaped problem. That’s a credible engineering approach, and MCP-level parsing in the Google Gemini agent gateway is genuinely more granular than URL-path-and-method filtering.
A few open questions worth tracking:
- Protocol parity. When does A2A get the same attribute-level policy depth that MCP has today? Multi-agent swarms are the use case A2A exists for, and they’re currently governed with a blunter instrument.
- Preview walls. The Gemini agent itself is in private preview with no public GA timeline. Until it opens, the gateway is the piece most teams can actually start adopting — and Agent Gateway itself is GA per Google’s release notes, with pieces like Cloud Trace integration still in Preview.
- Portability of policy. Your CEL conditions, tool annotations, and semantic governance rules are written against Google’s attribute namespace. If a standard for cross-cloud agent policy expression ever emerges — and MCP/A2A momentum suggests pressure will build — migration becomes the question nobody wants to answer.
- The coworker-agent blast radius. Agents with their own email addresses, calendars, and directory presence are an audit and identity-management workload in themselves. Gateway policy covers what they touch; it doesn’t cover the organizational questions they raise.
The bottom line
The Gemini agent is Google’s bid to make “delegate work from one box” the new enterprise default, and it’s gated behind private preview until enterprises trust it. The Gemini agent gateway is the answer to the trust question — and it’s live, metered, and documented. It parses the actual MCP tool call a confused or compromised agent tries to make — and compromised agents are not a thought experiment, as our post on the Gemini “AI breakout” that hacked three companies showed — checks that agentic identity against a deny-by-default registry of approved destinations, and refuses the request before it ever leaves the platform boundary.
One announcement sells the future of work. The other sells containment for the present. The second one is where the buying decision actually gets made.
Sources: Google Cloud’s Gemini at Work 2026 keynote post (Thomas Kurian), the official Gemini agent announcement on blog.google, Gemini Enterprise Agent Platform documentation (Agent Gateway overview and release notes), Google’s AGW Agent Gateway egress codelab, and The Verge’s event coverage.
References and further reading
- Google Cloud blog — Gemini at Work 2026 keynote
- Google blog (blog.google) — official Gemini agent announcement
- Google Cloud documentation — Gemini Enterprise Agent Platform / Agent Gateway
- Google Cloud release notes
- Google Codelabs — Agent Gateway egress
- The Verge — Gemini at Work 2026 event coverage
- Forkast — “Google Cloud Ships the First Protocol-Native Agent Gateway”
Please let us know if you enjoyed this blog post. Share it with others to spread the knowledge! If you believe any images in this post infringe your copyright, please contact us promptly so we can remove them.