Cross-cloud governance for Vertex AI Agent Builder

Short answer. Vertex AI Agent Builder controls agents that run inside Google Cloud. ACP covers the agents that run elsewhere, such as Claude Code, Cursor, and your CrewAI or LangGraph agents on other clouds, and puts both in one audit trail. Use Vertex for agents you build in Google Cloud and ACP for the rest. If you use ADK, you can run it locally with ACP and deploy it to Agent Engine under Vertex governance. The code stays the same, and each environment gets its own controls.

Google’s Vertex AI Agent Builder is the managed agent product that sits above the Agent Development Kit (ADK). Each agent gets a verifiable cryptographic ID and is registered as an IAM Principal, so its actions tie back to access policies. The Cloud API Registry is a central catalog of approved agents and tools, and administrators manage per-developer tool access in the console. Agent Engine runtime pricing dropped in January 2026.

For agents that live inside Vertex, this is a solid setup, especially if your organization already runs on Google Cloud.

It doesn’t reach the rest of your stack: Claude Code in a developer’s terminal, Cursor in their IDE, CrewAI on Render, LangGraph on Cloud Run, or Anthropic Agent SDK code on AWS. Vertex’s boundary is Google Cloud.

Agentic Control Plane checks tool calls from those other agents through hooks and SDKs, and records them with the user’s identity. This page covers what Vertex handles, what it doesn’t, and how the two fit together.

What Vertex Agent Builder ships

• Agent Identity. Each agent gets an IAM Principal and a verifiable cryptographic ID, so actions can be tied to access policies.
• Cloud API Registry tool governance. Administrators manage which tools developers can use, in the console, from a central catalog.
• Agent Engine. A managed runtime for ADK-built agents, with audit, observability, and scaling. ADK itself is the open-source Python SDK and is separate.
• Per-agent IAM identities flow into Google Cloud’s IAM, BigQuery audit logs, and Cloud Logging.
• Gemini Enterprise Agent Platform (announced April 2026). It bundles Agents CLI, Agent Runtime, Cloud Run, and GKE Autopilot deployment targets with admin controls.

Where Vertex stops

1. Google Cloud only. Vertex governs agents that run in Agent Engine, Cloud Run, or GKE Autopilot. Agents on AWS, Azure, on-prem, or a developer laptop are outside it.
2. ADK is the SDK and Agent Engine is the runtime. ADK code runs anywhere Python runs, but Vertex governance applies only when it runs on Vertex’s managed surfaces. The same code on a laptop or another cloud gets none of it. That’s where ACP fits.
3. Per-agent identity, not per-end-user identity. Agent Identity is the agent’s IAM Principal. Passing along the human the agent acts for takes custom claim handling. It isn’t built in the way Microsoft Entra Agent IDs pair with Conditional Access.

Where ACP plugs in

Path 1: ADK code run anywhere

Run ADK locally, on Cloud Run, on Render, on Fly.io, or in CI. ACP checks each tool call at the decorator:

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],
)

It behaves the same wherever you deploy. If the ACP gateway is unreachable, the SDK fails open: the tool runs and the call is logged as ungoverned. See the Google ADK integration and Governed Google ADK in 3 minutes for the full recipe.

Path 2: Agent Engine agents calling external tools

Your Agent Engine agent calls a tool that your own service exposes, such as a custom MCP server, an HTTP endpoint, or an internal API. Vertex governs the call, but your tool’s handler isn’t covered by Vertex. Wrap the handler with @governed to get PII redaction, an audit row, and policy on the actual dispatch.

Path 3: Vertex agents using ACP as an MCP backend

Register https://api.agenticcontrolplane.com/mcp as an MCP server in your Vertex Agent Builder configuration. Your Vertex agents then call ACP’s tools over standard MCP. Vertex’s identity can flow in through custom claims, and ACP’s policy and audit run downstream.

Side by side

Of the three big cloud agent products, ADK is the most portable, since the SDK runs anywhere Python does. That keeps the split simple: ADK with ACP outside Google Cloud, Agent Engine with Vertex inside it.

Install

For self-built agents (Path 1):

pip install acp-governance google-adk

For coding agents:

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

irm https://agenticcontrolplane.com/install.ps1 | iex

Limitations

• Vertex-internal calls aren’t visible to ACP. Agent-to-agent calls inside Agent Engine stay in Google Cloud. Use Cloud Logging for those.
• Per-agent IAM identities don’t carry over to ACP. Vertex’s identity is the agent’s IAM Principal, not the end user. For per-user attribution in ACP’s audit log, pass it as a custom JWT claim.
• Deployment targets differ. Agent Engine is the most managed. Cloud Run and GKE Autopilot give you more control but less native governance. ACP plugs in the same way on all three.
• Fail-open SDK. The acp-governance decorator runs the tool ungoverned, with a logged warning, if the gateway can’t be reached.

Related

• Google Agents CLI integration: the deployment surface (Agent Runtime, Cloud Run, GKE)
• AWS Bedrock integration: the same comparison for Amazon
• Microsoft Foundry integration: the same for Azure
• Governed Google ADK in 3 minutes: a runnable starter
• Reference architecture: how ACP sits next to cloud-native controls