What Happened
Google Cloud’s Cloud CLI remote MCP server is in public preview. It gives MCP-compatible agents access to hundreds of gcloud and bq commands without installing CLI binaries in the agent runtime. Its two tools, run_gcloud_command and run_bq_command, support cloud infrastructure management and BigQuery operations, including scheduled queries, job monitoring, execution-plan analysis, reservation management and table-permission updates. [1]
The managed, network-isolated service supports Agent Identity or OAuth 2.0 authentication, enforces IAM and organization policies, and offers Model Armor screening and configurable Audit Logs. Connecting requires enabling the Cloud CLI Execution API, cloudcli.googleapis.com, granting roles/mcp.toolUser and configuring the MCP client to use cloudcli.googleapis.com/mcp. [1]
Why It Matters to Businesses
This reduces tool-integration work, not the need for operational controls. Teams building AI operations assistants can avoid maintaining local CLI installations and custom wrappers for every supported cloud operation. The same interface can support infrastructure investigation and data-platform workflows. [1]
The business trade-off is broader access versus tighter control. An agent that can inspect a BigQuery job may also encounter tools capable of changing reservations or table permissions. Those actions have different financial and security consequences, even when both are technically authorized. [1]
For enterprise AI platforms, this is a cloud-management integration—not an LLM deployment platform or a complete MLOps system. Model serving, evaluation, release management and application observability still require their own architecture. The remote server supplies an execution path for supported cloud commands. [1]
Kimbodo Engineering Perspective
We would treat the agent as a planner and the execution layer as a controlled actuator. IAM authorization is necessary, but it does not establish that a proposed action is appropriate. An authorized command can still target the wrong project, change an unintended resource or generate unnecessary spend.
Our starting point would be narrow, read-only workflows: investigate failed jobs, inspect execution plans and summarize resource state. We would introduce mutations only after testing command selection, target accuracy and failure handling.
A managed MCP service is attractive when it removes undifferentiated integration work. A smaller, purpose-built tool interface remains preferable when a workflow needs strict parameter schemas, predictable behavior or limited privileges. We would not expose the full available command surface merely because the protocol makes it accessible.
How We Would Implement It
Put a policy gate between planning and execution
Our proposed architecture is: authenticated user request, agent planner, application-side policy gate, remote MCP client, then Google Cloud authorization and execution. The policy gate would evaluate structured command arguments and resource targets—not simply trust the model’s explanation.
- Establish identity: Choose Agent Identity or OAuth 2.0 according to the workflow. Scope access to intended projects and resources, and verify both MCP access and the permissions needed for each operation. [1]
- Restrict commands: Allowlist supported workflows and validate projects, datasets, locations and command arguments. Reject unrecognized operations and ambiguous targets.
- Separate action classes: Permit approved inspection tasks automatically; require human approval for permission changes, reservation changes, destructive actions and resource creation.
- Bound execution: Apply timeouts, retry limits and concurrency caps. Do not blindly retry mutations after an uncertain result; inspect resource state first.
- Capture evidence: Record the requester, proposed action, approval, execution result and correlation identifier. Configure Audit Logs and reconcile them with application records. [1]
- Evaluate before expansion: Test wrong-project requests, malicious instructions in retrieved content, denied permissions, partial failures and duplicate execution.
Risks, Costs and Security
The preview has no additional charge, but resources created through it and applicable data transfer are billed normally. [1] That makes execution controls more important than interface pricing: an inexpensive agent interaction can initiate costly cloud work. We would combine application-side limits with cloud budgets and service-specific controls rather than treat billing alerts as spending caps.
Prompt injection, overprivileged identities and unintended permission changes remain central risks. Network isolation and Model Armor screening are useful protections, but neither should replace least privilege, command validation or approval gates. [1] Tool output and retrieved content should be treated as untrusted input, never as authority to expand access.
Because the service is in public preview, we would validate reliability and compatibility before placing it on a critical operational path. [1] Keep a manual runbook and an independent recovery path. Start with bounded workflows where execution can be audited and failures can be contained.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice, or Estimate My Infrastructure.
