gcloud MCP

The server runs every gcloud command with whatever account is active in the user's local gcloud installation, passing its full environment to the gcloud process, and nothing in the server narrows that authority. The model can also switch identity per call with global flags such as --impersonate-service-account or --account, and nothing stops it from changing IAM policy, including the policy that governs its own account. The README tells operators to impersonate a limited service account, but that is manual hardening outside the code.

The server exposes one tool, run_gcloud_command, that covers every read and every write in Google Cloud, with no risk annotations, no dry-run, and no read-only mode, so the host gets no signal to separate a harmless list from a project deletion. There is no server-side confirmation step. A wrongly approved or unapproved call can delete resources, change IAM, or deploy code, much of it irreversibly.

The tool takes an argument array and runs gcloud without a shell, which rules out shell injection, and it parses each command with gcloud's own linter before checking it against a short default denylist of interactive commands (SSH, serial port, `interactive`, `meta`). Everything else, including IAM, secrets, deletes, deployments and local file copies, is allowed by default. Neither the denylist nor the operator allowlist is a strict boundary. An opt-in allowlist file is available but is off by default.

Model-written arguments are run by the gcloud CLI as a child process of the server, as the same OS user, with the full environment and no sandbox. gcloud is a general tool: through it the model can copy local files anywhere, run scp, install components, and push code that runs remotely (VM startup scripts, Cloud Build, Cloud Run and Functions deploys) with the user's credentials. Nothing in the server isolates or limits any of this.

Whatever gcloud prints, including log entries, resource metadata, labels and object contents that other people can write, goes back to the model as plain text with no marking of where it came from. The tool description itself contains directives to the model, such as preferring this tool over any other. There is no read-only or no-egress mode, so a hijacked model can read sensitive data, send it out (for example by copying it to an external bucket), and delete resources without any human step.

The server keeps no memory and reads no files from the workspace; its only configuration is an absolute-path file chosen by the operator. However, the model can persistently rewrite the user's own gcloud configuration through `gcloud config set`, for example redirecting API endpoints, switching the account, or setting service-account impersonation. Those changes survive the session and silently change every later gcloud call, by the agent and by the human. The only trace is the argument line in the server's stderr log.

The server itself loads no plugins or remote code. But because it exposes the whole gcloud CLI and does not restrict the `components` group, the model can add a component repository at an arbitrary URL and install components from it, which gcloud then runs with the user's credentials. Nothing asks the user, pins versions, or confines what is installed. On package-manager installs of gcloud, the component manager may be disabled.

The server holds no keys of its own and leaves credentials in gcloud's credential store, which is a good start. But nothing keeps credentials or secret values out of the model's context: `gcloud auth print-access-token`, `secrets versions access` and similar commands return their output verbatim, and local credential files can be copied out with `gcloud storage cp`. There is no redaction anywhere; the server logs every command's arguments to stderr, but not outputs, and sends no telemetry.

Each tool call writes a timestamped line to stderr with the full argument list before gcloud runs, and errors are logged. The record lacks the exit code or result, and denied commands are not logged at all. The logs go wherever the host stores the server's stderr, outside the server's control, and the agent's own gcloud access could in principle overwrite local files. There is no actor attribution beyond the tool name.

The server puts no bounds on its own work: gcloud processes run without a timeout or output-size cap, and calls are not rate- or concurrency-limited. The only limits are gcloud flags like --limit, which the model may choose to use. Streaming commands can run indefinitely, and on shutdown the server closes and exits without killing a running gcloud child.