Vertex AI Agent Builder + ACP — Cross-cloud governance install guide

Google’s Vertex AI Agent Builder is the managed agent surface that sits above the Agent Development Kit (ADK). Each agent gets a verifiable identity through cryptographic IDs and is registered as an IAM Principal — creating a clear audit trail tied to defined access policies. The Cloud API Registry serves as a centralized catalog of approved agents, tools, and capabilities, with per-developer tool governance managed in the console. Pricing for Agent Engine runtime dropped in January 2026.

For agents that live inside Vertex — built with ADK, deployed to Agent Engine, integrated with Google’s identity and policy primitives — Agent Builder is a real governance surface, especially for organizations already deep in Google Cloud.

What it doesn’t span: the rest of your AI stack. Claude Code in your developer’s terminal. Cursor in their IDE. CrewAI on Render, LangGraph on Cloud Run, custom Anthropic-Agent-SDK code on AWS. Vertex’s enforcement boundary is Google Cloud — by design.

Agentic Control Plane is the layer above. This page is the honest read on what Vertex covers, what it doesn’t, and how the two compose into one identity-attributed audit trail across every environment your agents run in.

TL;DR. Use Vertex for agents you build inside Google Cloud. Use ACP for everything else and for unified audit across both. ADK developers benefit from running ADK locally with ACP and deploying to Agent Engine with Vertex governance — same code, two governance scopes.

What Vertex Agent Builder ships

• Agent Identity — each agent assigned an IAM Principal, with a verifiable cryptographic ID. Auditable record of actions tied to access policies.
• Cloud API Registry tool governance — administrators manage available tools for developers across organizations directly in the console. Centralized catalog of approved agents, tools, and capabilities.
• Agent Engine — managed runtime for ADK-built agents (separate from ADK itself, which is the open-source Python SDK). Ships with audit, observability, scaling.
• Per-agent IAM identities flow through Google Cloud’s existing IAM, BigQuery audit logs, and Cloud Logging.
• Gemini Enterprise Agent Platform (announced April 2026) — bundles Agents CLI, Agent Runtime, Cloud Run, and GKE Autopilot deployment targets with admin controls.

For Google-Cloud-native enterprises, this is a coherent story — and Google’s pricing reduction in January 2026 made it materially cheaper than at launch.

Where Vertex stops

Same architectural pattern as the other two hyperscalers:

1. Google Cloud only. Vertex governs agents that run inside Google Cloud — Agent Engine, Cloud Run, GKE Autopilot. Agents on AWS, Azure, on-prem, or developer laptops are outside the boundary.
2. ADK is the SDK; Agent Engine is the runtime. ADK code can run anywhere Python runs. Vertex governance applies when the code runs on Vertex’s managed surfaces. Same SDK code on developer laptops or non-Google clouds gets no Vertex governance — that’s where ACP fits.
3. Per-agent identity, not per-end-user identity. Vertex’s Agent Identity is the agent’s IAM Principal. Per-end-user identity propagation (the human on whose behalf the agent acts) requires custom claim threading — it’s not an out-of-the-box default the way Microsoft Entra Agent IDs combine with Conditional Access.

Where ACP plugs in

Path 1 — ADK code run anywhere (works today)

Run ADK locally, on Cloud Run, on Render, on Fly.io, in CI — wherever Python runs. ACP governs at the tool-decorator layer:

from acp_governance import configure, governed, set_context
from google.adk.agents import Agent

configure(base_url="https://api.agenticcontrolplane.com")

@governed("lookup_record")
def lookup_record(id: str) -> dict:
    """Look up a record by ID."""
    return db.records.find_one({"id": id})

agent = Agent(
    name="my_agent",
    model="gemini-flash-latest",
    tools=[lookup_record],
)

Same code, same starter, same governance — independent of where you deploy. See the Google ADK integration and the Governed Google ADK in 3 minutes post for the full recipe.

Path 2 — Vertex Agent Engine deployments calling external tools

Your Agent Engine agent calls a tool exposed by your service (custom MCP server, HTTP endpoint, internal API). Vertex governs the call — your tool’s handler doesn’t have Vertex’s interception. Wrap the handler with @governed for PII redaction, audit row, and policy on the actual tool dispatch.

Path 3 — Vertex agents using ACP as MCP backend

Register mcp.agenticcontrolplane.com/mcp as an MCP server in your Vertex Agent Builder configuration. Your Vertex agents call ACP-governed tools through standard MCP — Vertex’s identity propagation flows in via custom claims; ACP’s policy and audit fire downstream.

Honest comparison

ADK is the most portable of the three hyperscaler agent surfaces — the SDK runs anywhere Python runs. That makes the ADK-on-ACP / Agent-Engine-on-Vertex split clean: same code, two governance scopes, one developer experience.

Install

For self-built agents (Path 1):

pip install acp-governance google-adk

For coding agents:

curl -sf https://agenticcontrolplane.com/install.sh | bash

Limitations

• Vertex-internal calls aren’t visible to ACP. Agent-to-agent calls inside Agent Engine stay in GCP — outside ACP’s interception. Use Cloud Logging for those.
• Per-agent IAM identities don’t auto-propagate to ACP. Vertex’s per-agent identity is the agent’s IAM Principal, not the end user. For per-end-user attribution in ACP audit, propagate via custom JWT claim.
• Agents CLI deployment targets vary. Agent Engine is the most managed; Cloud Run and GKE Autopilot give you more control but less native governance. ACP plugs in identically across all three.

Related

• Google Agents CLI integration — separate page for the deployment surface (Agent Runtime, Cloud Run, GKE)
• AWS Bedrock integration — equivalent honest read for Amazon’s surface
• Microsoft Foundry integration — equivalent for Azure
• Governed Google ADK in 3 minutes — runnable starter
• Reference architecture — how ACP composes with cloud-native governance layers