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) pure LLM interception (limited today)

For Agent Runtime specifically, your Python source runs inside Google’s managed runtime. Whether the runtime permits egress to arbitrary non-Google URLs (for a LiteLLM api_base override) is not documented. We’re testing this — will update the post when we have a verified answer.

If egress is open: Path 1 works for Agent Runtime too. If egress is locked: Path 2 (in-framework callback) still works as long as outbound HTTPS to api.agenticcontrolplane.com/govern/tool-use is allowed. If all egress is locked: you get Google’s native Gateway + Identity + Registry surface, no third-party inline governance.

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.