# Governance for Google Agents CLI — ADK agents from create to production

Google shipped the Agents CLI for ADK — deploys to Agent Runtime, Cloud Run, and GKE. Where ACP plugs in via LiteLLM, MCP, and ADK's before_tool_callback.

# Governance for Google Agents CLI

Google [announced the Agents CLI](https://developers.googleblog.com/agents-cli-in-agent-platform-create-to-production-in-one-cli/) on April 22, 2026 — a Python CLI (`uvx google-agents-cli`) that scaffolds, evaluates, deploys, and publishes [Agent Development Kit (ADK)](https://google.github.io/adk-docs/) agents. Code on [GitHub](https://github.com/google/agents-cli).

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](https://cloud.google.com/blog/products/ai-machine-learning/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](https://docs.cloud.google.com/gemini-enterprise-agent-platform/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`:

```python
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`:

```python
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](/blog/architecture-is-governance#pattern-3-proxy--captures-everything-llm-reaches-for), 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](/benchmark) 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:

```python
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:

```python
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](/blog/architecture-is-governance#pattern-4-mcp--routing-determines-coverage). 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](https://docs.cloud.google.com/agent-builder/agent-engine/private-service-connect-interface), **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

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

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

Windows:

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

## Read next

- [Architecture is governance](/blog/architecture-is-governance) — the four-pattern taxonomy (Decorator / Hook / Proxy / MCP), all four relevant here.
- [OpenAI Agents SDK guide](/integrations/openai-agents-sdk) — the LiteLLM `api_base` pattern applied to a similar SDK.
- [AgentGovBench scenarios](/benchmark/scenarios) — what the 45/48 score tests.

Running ADK in production with governance requirements spanning Agent Runtime + Cloud Run + Gemini Enterprise distribution? [Say hi](mailto:hello@agenticcontrolplane.com).