ACP and Vertex AI Agent Builder: same ADK code, two governance scopes
Google’s Vertex AI Agent Builder is the managed agent surface above the Agent Development Kit (ADK). Per-agent IAM Principal identities, cryptographic agent IDs, Cloud API Registry-backed tool governance in the console, and Agent Engine — the managed runtime that runs ADK-built agents — got a meaningful price drop in January 2026.
ADK has a property the other two hyperscalers’ agent SDKs don’t: it’s open-source Python that runs anywhere Python runs. The same agent code can run on a developer’s laptop during dev, deploy to Agent Engine for production, run on Cloud Run for a custom managed setup, deploy to GKE Autopilot for full control. That portability is unusual — and it changes the governance composition story in a useful way.
This post is the honest read on what Vertex covers, what it doesn’t, and how the same ADK code gets governed by ACP in dev and by both ACP and Vertex in production.
What Vertex Agent Builder covers well
- Per-agent identity — each agent gets a verifiable cryptographic ID and an IAM Principal. Auditable record of actions tied to defined access policies. Clean integration with Google Cloud’s existing IAM tooling.
- 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. Handles scaling, observability, audit. Pricing dropped January 2026 — meaningfully cheaper for production workloads.
- Native integration with Cloud Logging, BigQuery audit logs, IAM policies.
- Gemini Enterprise Agent Platform — bundles deployment targets and admin controls (announced April 2026).
For Google-Cloud-native enterprises — orgs already using BigQuery, Vertex AI, GKE — this is a coherent, native-feeling story.
What’s outside Vertex’s scope
Same architectural pattern as the other hyperscalers: Vertex is designed to govern agents that run inside Google Cloud.
The wrinkle: ADK itself is portable. The SDK runs anywhere Python runs. So the “Vertex governs Vertex-deployed agents” boundary maps to deployment target, not codebase. Same ADK code running on a developer laptop is outside Vertex’s enforcement scope; same code deployed to Agent Engine is inside.
Four categories sit outside the Vertex enforcement surface — by design:
- ADK code running outside Google Cloud. Local dev, AWS, Azure, on-prem, customer environments — these run at a different architectural layer than the Vertex runtime.
- Non-ADK agent code. Claude Code, Cursor, CrewAI, LangGraph, Vercel AI SDK, Pydantic AI — Vertex’s interception is built around ADK + Agent Engine. Other frameworks have a different intercept point: the tool dispatch boundary in their own code.
- Per-end-user identity propagation. Vertex’s Agent Identity is the agent’s IAM Principal — service identity rather than the human-on-whose-behalf identity. Per-end-user attribution flows in via custom claims, which is a separate architectural concern.
- Coding-agent surface. Same as the other hyperscalers — Claude Code or Cursor traffic uses the agent runtime’s own hook surface, a different intercept layer.
Again: not bugs in Vertex. The natural boundary of what a Google-Cloud-native control plane is built to govern.
The clean split: same ADK code, two governance scopes
Where Vertex’s portability story actually matters: ACP and Vertex compose unusually cleanly for ADK developers. Same code, governed by ACP everywhere; additionally governed by Vertex when deployed to Agent Engine.
from acp_governance import configure, governed, set_context
from google.adk.agents import Agent
configure(base_url="https://api.agenticcontrolplane.com")
@governed("query_warehouse")
def query_warehouse(sql: str) -> dict:
return warehouse.execute(sql)
agent = Agent(
name="my_agent",
model="gemini-flash-latest",
tools=[query_warehouse],
)
That code runs:
- Locally during dev — only ACP governs it (the only governance layer in scope).
- Deployed to Agent Engine — both ACP (tool-layer interception) and Vertex (per-agent IAM identity, Cloud API Registry, audit). Two layers, complementary.
- Deployed to Cloud Run or GKE Autopilot via Agents CLI — same as Agent Engine, with different runtime characteristics.
- Deployed to AWS Lambda or Azure Functions — only ACP. (ADK is portable; deploy targets aren’t Vertex-only.)
Three scenarios, one codebase, governance scoped appropriately to each.
Where ACP composes alongside Vertex
- Cross-cloud unified audit. Same audit log across Vertex-deployed agents, AWS-deployed agents, Azure-deployed agents, and developer-laptop coding agents.
- Cross-framework breadth. 15 framework / client integrations beyond ADK. Most ADK-using enterprises also have Claude Code on developer machines, Cursor in IDEs, maybe a CrewAI service somewhere. ACP covers the lot.
- Per-end-user identity propagation. ACP’s
set_context(user_token=...)binds the human identity per request, not the agent identity. Both surface in the audit row. - Vendor-agnostic IdP. Auth0, Okta, Firebase, Microsoft Entra, custom OIDC — all work the same with ACP. Vertex is built around Google Cloud IAM.
How to compose them — three patterns
Pattern 1 — ADK locally with ACP, ADK deployed with both
Default for ADK-using teams:
- Local dev → governed by ACP only
- Deployed to Agent Engine / Cloud Run / GKE → governed by both
Same code, no code changes between dev and prod, governance scope expands as the agent moves to production. The ergonomically cleanest of the three hyperscaler stories.
Pattern 2 — Vertex agents calling external tools
Your Vertex-deployed agent has a tool that hits a non-Google endpoint — your CRM, a partner API, your internal service on AWS. Vertex governs the call. ACP governs the response. Wrap the handler with @governed; the response gets PII redaction, audit, and policy enforcement before returning.
Pattern 3 — Vertex agents using ACP as MCP backend
Register mcp.agenticcontrolplane.com/mcp as an MCP server in your Vertex Agent Builder configuration. Vertex’s per-agent IAM identity flows in via custom claims; ACP enforces governance on the actual tool dispatch downstream.
The Google-Cloud-deep edge case
If your stack is GCP-everywhere — BigQuery, Vertex AI, GKE, Agent Engine, Gemini-only models, no developer-laptop coding agents in scope, no multi-framework, no multi-cloud — Vertex alone is sufficient. Google has the most portable agent SDK; if you stay in their cloud, they have a coherent story.
For everyone else (multi-cloud, ADK-deployed-locally-and-in-prod, mixed-framework, coding-agent-in-scope), Vertex is one layer in a stack that needs cross-environment unification above it.
The short version
Vertex is the right answer for ADK agents deployed to Agent Engine inside Google Cloud, especially for shops already deep in GCP. ACP is the right answer for ADK code outside Vertex’s runtime, for non-ADK agents (most of your team’s other agents), for cross-environment unified audit, and for per-end-user identity propagation. The clean win is the same-code-everywhere story: write ADK once, deploy anywhere, governance scopes match the deployment.
Detailed install: /integrations/vertex-ai-agent-builder.
Governed Google ADK in 3 minutes → · Reference architecture → · Get started →