What Happened
Google Cloud has introduced a remote CLI MCP server in public preview. MCP-compatible agents can invoke hundreds of gcloud and bq commands through two tools: run_gcloud_command and run_bq_command. Local CLI binaries are not required. Supported tasks include infrastructure management, BigQuery execution-plan analysis, reservation management, and table-permission changes. [1]
The managed, network-isolated server supports Agent Identity or OAuth 2.0 authentication, IAM and organization-policy enforcement, Model Armor screening, and configurable Audit Logs. Setup requires enabling cloudcli.googleapis.com, granting roles/mcp.toolUser, and connecting a compatible client to cloudcli.googleapis.com/mcp. There is no additional server charge during preview, but resource and applicable data-transfer costs still apply. [1]
Why It Matters to Businesses
This reduces the integration work needed to connect AI assistants to cloud operations. A platform team can explore agents that investigate BigQuery performance or inspect infrastructure without maintaining CLI installations inside each agent runtime. The capability is operational tooling, not a replacement for an LLM deployment platform or MLOps pipeline. [1]
The central architecture decision is how much operational authority to expose. An agent that explains a query plan has a different risk profile from one that changes permissions or reservations. Giving both access through the same broad command interface does not make their consequences equivalent.
Remote execution also changes the cost calculation. Avoiding local CLI maintenance can reduce engineering overhead, but repeated queries, unintended resource creation, or inefficient investigations can still generate cloud charges. A free preview endpoint is not a free operating model. [1]
Kimbodo Engineering Perspective
We would treat the remote MCP server as an execution interface behind enterprise controls—not as the complete control plane. IAM determines what an identity may do; the application must also determine which actions an agent should attempt, for which user, and under what approval conditions.
- Start with inspection: Limit initial workflows to resource inventory, configuration review, and bounded diagnostics.
- Separate diagnosis from mutation: Let the model propose a change, then have a controlled workflow validate and execute it after approval.
- Keep deployment authority narrow: Application releases and infrastructure changes should continue through reviewed delivery pipelines rather than unrestricted agent-issued commands.
- Use narrow tools where consequences are high: A purpose-built operation with typed inputs is easier to validate than a general command interface.
The trade-off is flexibility versus assurance. Broad CLI access accelerates experimentation; constrained workflows make authorization, testing, and incident investigation more predictable.
How We Would Implement It
Place a Policy Layer Between the Agent and Execution
Our proposed architecture is: authenticated user, agent orchestrator, policy gateway, remote MCP server, and authorized Google Cloud resources. The gateway would validate commands structurally, enforce project and operation allowlists, and reject unsupported arguments before execution. Prompt instructions alone would not enforce these boundaries.
Roll Out in Controlled Stages
- Establish identity: Configure the documented API, endpoint, and tool-user role. Separately scope resource permissions to the required projects and operations; do not treat tool access as sufficient resource authorization. [1]
- Constrain workload: Set limits on tool calls, concurrency, execution time, and query consumption where supported. Stop investigations that exceed their budget.
- Gate mutations: Require approval tied to the exact target and proposed action. Revalidate the request immediately before execution.
- Record execution: Enable relevant Audit Logs and correlate them with application records for the user, agent run, command, approval, and result. [1]
- Test failure paths: Evaluate wrong-project selection, misleading tool output, permission failures, retries, and partial execution before expanding access.
Risks, Costs and Security
Prompt injection remains a design concern. Agents may encounter untrusted instructions in queried data or operational output. Model Armor screening is a useful available control, but should not replace least privilege, command validation, and approval gates. [1]
Retries need particular care: an ambiguous response does not prove that a mutation failed. Before retrying, verify resource state or use an operation-specific idempotency strategy. Limit sensitive information passed to the model, and redact credentials and unnecessary business data from application traces.
Budget for model inference, orchestration, logging, engineering maintenance, and cloud activity—not just MCP access. Because the service is in public preview, verify current capabilities, support terms, and limits before making it a critical dependency. [1] Retain a human-operated path for recovery and a fast way to disable agent execution.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice, or Estimate My Infrastructure.
