Skip to content
Agentic Control Plane

Governance for Google Agents CLI

Google announced the Agents CLI on April 22, 2026 — a Python CLI (uvx google-agents-cli) that scaffolds, evaluates, deploys, and publishes Agent Development Kit (ADK) agents. Code on GitHub.

Three deployment targets:

  • Agent Runtime — Google’s managed runtime (no container, no Dockerfile; your source is packaged as a tarball and deployed to Vertex AI reasoning engines)
  • Cloud Run — your container, your infrastructure
  • GKE Autopilot — your container on Google’s managed Kubernetes

Plus agents-cli publish for registering agents in Gemini Enterprise.

This page is the honest read: what governance Google ships natively, what’s documented for third-party integration, and where ACP plugs in for each deployment target.

TL;DR. ADK agents use Google’s GenAI/Vertex SDK by default, but the framework ships LiteLLM as a first-class escape hatch — LiteLlm(model="openai/gpt-4o"), anthropic/claude-sonnet-4, ollama_chat/llama3. That’s our integration surface. For Cloud Run and GKE deploys, ACP plugs in at the LLM boundary with no code change beyond a LiteLlm api_base. For Agent Runtime (the managed target), Google has shipped their own interception layer — Agent Gateway + Model Armor — which today enforces Google policies, not customer-pluggable webhooks. MCP support is first-class in ADK; ACP can run as the MCP backend for custom tools.

What ships natively

Quoting Google’s docs:

Agent Gateway (runtime-enforced, Google-native)

“Agent Gateway acts as the air traffic control for your agent ecosystem… enforcing consistent security policies and Model Armor protections to safeguard against prompt injection and data leakage.” — Introducing Gemini Enterprise Agent Platform

“It acts as the runtime enforcement point, intercepting calls to tools or other agents to enforce access control policies and support Model Armor inspection of tool calls and responses.” — Agents overview

This is meaningful governance — a real inline interception point. What’s not documented is a customer-pluggable webhook at the Gateway layer. Today Gateway enforces Google’s own policies (IAM + Model Armor), not arbitrary third-party ones.

Agent Identity

“Agent Identity… ensures every agent receives a unique cryptographic ID. This creates a clear, auditable trail for every action an agent takes, mapped back to defined authorization policies.”

Agent Registry

“It captures critical metadata, including versions, frameworks (like ADK), and capabilities such as MCP tool names and annotations.”

Audit logging

Agent Runtime emits to Cloud Logging, resource type aiplatform.googleapis.com/ReasoningEngine. Schema is developer-defined (you log what you log). A built-in Logging/user/tool_calling_count metric exists, but per-call structured audit with principal attribution is not documented as an out-of-the-box schema.

ADK’s in-framework governance hooks

Separate from the managed runtime, the ADK framework itself ships in-process callbacks on every Agent:

from google.adk.agents import Agent

agent = Agent(
    model="gemini-2.5-pro",
    tools=[...],
    before_model_callback=check_model_inputs,
    after_model_callback=scan_model_outputs,
    before_tool_callback=approve_tool_call,   # ← policy gate
    after_tool_callback=scan_tool_output,
    before_agent_callback=...,
    after_agent_callback=...,
)

Plus FunctionTool(..., require_confirmation=True) for human-in-the-loop gates, and a conditional form require_confirmation=needs_approval that can make the decision programmatically.

These are developer-side, in-process — not a runtime-enforced admin plane. Good for application-level controls; insufficient on their own for cross-agent audit or cross-workspace policy. That’s where ACP complements them.

Where ACP fits — three paths

Path 1 — Cloud Run / GKE deploys + LiteLLM proxy (works today, zero new code)

Scaffolded Cloud Run and GKE projects include your own Dockerfile. You own egress. Configure ADK’s LiteLlm wrapper with a custom api_base:

from google.adk.agents import Agent
from google.adk.models.lite_llm import LiteLlm

agent = Agent(
    name="triage_agent",
    model=LiteLlm(
        model="openai/gpt-4o",
        api_base="https://api.agenticcontrolplane.com/v1",
        api_key=os.environ["ACP_API_KEY"],
    ),
    tools=[...],
)

Every LLM round-trip now flows through ACP — full governance pipeline, per-user identity attribution via x-acp-user-id, rate limit and cost caps, PII scanning on tool outputs, structured audit. Scored 45/48 on AgentGovBench under the Proxy pattern.

This is the path we recommend for Cloud Run and GKE targets. The tradeoff: you’re routing Google’s default Gemini models through LiteLLM instead of Vertex AI — so you pay per-token, not via Google’s native Gemini billing. For OpenAI/Anthropic/Ollama models (which ADK already routes via LiteLLM by design), there’s no tradeoff.

Path 2 — ADK before_tool_callback → ACP (works today, 5 lines of code)

For applications where you want to keep Gemini via Vertex AI but still gate tool calls through ACP, use the in-framework callback:

import requests, os

def acp_gate(tool, args, context):
    r = requests.post(
        "https://api.agenticcontrolplane.com/govern/tool-use",
        json={"tool_name": tool.name, "tool_input": args},
        headers={"Authorization": f"Bearer {os.environ['ACP_API_KEY']}"},
        timeout=4,
    )
    data = r.json()
    if data.get("decision") == "deny":
        raise PermissionError(f"[ACP] {data.get('reason', 'denied by policy')}")

agent = Agent(
    model="gemini-2.5-pro",
    tools=[...],
    before_tool_callback=acp_gate,
)

This doesn’t capture LLM round-trips (so no content scanning on model inputs/outputs), but gates every tool call against ACP policy with structured audit. Equivalent in shape to the Claude Code PreToolUse hook.

Path 3 — MCP-backed custom tools (works today)

ADK consumes MCP servers as tools:

from google.adk.tools.mcp_tool import McpToolset, SseConnectionParams

tools = [
    McpToolset(
        connection_params=SseConnectionParams(
            url="https://mcp.agenticcontrolplane.com/sse",
        ),
    ),
]

ACP can run as the MCP backend — same governance pattern as Cursor. Works with any of the three deployment targets.

Path 4 — Agent Runtime (managed) — same paths, one network caveat

Agent Runtime runs your Python source in Google’s managed runtime. Per Google’s docs, a standard deploy has public internet access by default — “Agent Engine has public internet access by default.” That means Path 1 (LiteLLM api_base) and Path 2 (before_tool_callback → /govern/tool-use) both work on Agent Runtime with no extra configuration.

The one case to know: if you deploy inside a VPC Service Controls perimeter, egress is blocked by default and you have to route outbound traffic through your own proxy + Cloud NAT. In that scenario, your VPC’s egress rules need to allowlist api.agenticcontrolplane.com (for the proxy and hook paths) and mcp.agenticcontrolplane.com (for MCP). Same shape as any other enterprise VPC-SC integration.

Same true of Cloud Run and GKE when deployed with VPC-SC — a VPC-egress question, not an ACP question.

What we’re watching

  • Customer-pluggable webhooks at Agent Gateway. If Google exposes a pre-tool-use webhook analogous to Claude Code’s PreToolUse, ACP will support it out of the box. Today Gateway is Google-policy-only.
  • A2A mode publishing to Gemini Enterprise. agents-cli publish gemini-enterprise --type a2a registers agents for discovery; governance at the publish boundary is IAM-based today.
  • uvx google-agents-cli on macOS/Linux is the fastest way to try the CLI end-to-end. Pairs with curl -sf https://agenticcontrolplane.com/install.sh | bash if you want ACP set up for local ADK iteration before deploying.

Install

# Set up ACP
curl -sf https://agenticcontrolplane.com/install.sh | bash

# Set up google-agents-cli
uvx google-agents-cli

Windows:

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

Running ADK in production with governance requirements spanning Agent Runtime + Cloud Run + Gemini Enterprise distribution? Say hi.