Reviewing Google's Gemini Enterprise Agent Platform — the Vertex AI and Agentspace merger

The consolidation itself is review-relevant: two previously separate products (a developer-facing agent-building toolkit and an enterprise-search-and-agent product) are now one platform. A review scoping a Gemini Enterprise deployment should confirm which of the former products' capabilities are actually in use — Agent Studio and ADK for custom-built agents, versus Agentspace-lineage features for enterprise search and pre-built agents — since they carry different data access patterns.

The platform follows a serverless pattern: agent state is stored in Cloud Spanner or AlloyDB rather than in-process, so Cloud Run instances can scale to zero without losing state — Spanner in particular offers global scale with ACID transactional consistency for distributed enterprise deployments. The security framework includes defenses against prompt injection, a zero-trust posture for decentralized agents, and access control via Google Cloud IAM and VPC Service Controls.

For a review, persisted agent state in a shared database is the detail worth isolating: the same question that applies to LangGraph's checkpoint store (see reviewing LangChain and LangGraph) applies here — is the Spanner/AlloyDB state store properly scoped per tenant, and are queries against it parameterized rather than built from agent- or user-supplied input.

MCP servers are natively supported across BigQuery and Google Maps, and Anthropic's Claude models are first-class citizens in Model Garden alongside Gemini — meaning a Gemini Enterprise deployment can reach both Google-first-party MCP surfaces and cross-vendor agents over A2A, now running in production rather than preview. Both connection types are real trust boundaries a review needs to enumerate, not assume are covered by the platform's general IAM posture.

VPC Service Controls now supports agent identities directly as IAM principals in perimeter ingress/egress rules — a single agent, or a principal set covering a group of agents — and, more specifically, conditional access rules keyed on Model Context Protocol request attributes, so network policy can discriminate by the shape of an MCP request, not only by which identity sent it. That's a genuine capability upgrade worth confirming is actually configured, not just available, for any deployment relying on VPC-SC as its network isolation boundary.

Pillar Security (researcher Dan Lisichkin) disclosed a concrete incident in Google's Agent Development Kit for Python — the same ADK bundled into this platform — where a low-privileged, public-facing agent could be prompt-injected into posting a @gemini-cli command as a GitHub PR comment, triggering a workflow that escalated into a maintainer-privileged agent's full capabilities, including arbitrary bash access and its GitHub token.

With that stolen token, the attacker could fabricate a false “human reviewed and approved” trail on a malicious pull request — actual tampering with the review record, not just data exfiltration. Google fixed the underlying issue but declined a bug bounty, arguing the attack required social engineering; a second, related ADK finding was fixed separately in late July 2026.

The review-relevant point isn't whether the bounty decision was fair — it's that a low-privileged agent escalating into a higher-privileged one's capabilities through an ordinary, unauthenticated input channel (a PR comment) is exactly the kind of cross-agent trust question the platform's “zero-trust posture for decentralized agents” claim is supposed to prevent. A review should ask for the specific mechanism enforcing that posture, not accept the phrase itself as evidence.

For any system built on Gemini Enterprise Agent Platform, a design-time review should be able to answer:

• Is the Spanner/AlloyDB state store scoped per tenant, with parameterized access rather than agent-influenced query construction?
• What VPC Service Controls and IAM scope actually apply to each agent, verified per-agent rather than inherited from a project-wide default?
• Which BigQuery/Maps MCP surfaces and A2A-connected peer agents does each deployed agent actually reach, and has each been reviewed?
• Is the deployment built on the current Gemini Enterprise naming and architecture, or does its documentation still reference the pre-rebrand Vertex AI Agent Builder / Agentspace split?
• If ADK is used for automation that reacts to GitHub PR/issue comments, is the triggering content validated against its actual origin rather than trusted because it came through an authenticated bot's identity?
• Does VPC Service Controls actually enforce agent-identity-scoped and MCP-attribute-conditional rules, or is the perimeter relying on broader, less granular defaults?