Skip to main content

Google Cloud API Keys MCP Server: The Permission Boundary Around Secret Keys

4 min read

Google Cloud's preview MCP server can inspect, create, change and retrieve API keys. Separate metadata from secrets and require approval for sensitive calls.

Google Cloud API Keys MCP Server: The Permission Boundary Around Secret Keys

An AI agent that can inspect an API key is useful. An agent that can retrieve the secret string, change its restrictions, or delete it has crossed into credential administration. GoogleCloud’ss new MCP endpoint exposes both kinds of action.

Google Cloud has added a remote Model Context Protocol server for the API Keys API in preview. The endpoint is https://apikeys.googleapis.com/mcp. Its reference lists tools to find, create, update, delete, and restore project API keys. Crucially, apikeys_get_key_string can return the actual secret value, while apikeys_get_key returns metadata without the secret. An administrator must enable the MCP server and set up authentication before use.

What the server exposes

The documented tools have different security consequences.
Tool groupDocumented actionOperational concern
List and inspectList project keys or fetch key metadata and restrictions.Inventory can still reveal project structure and access patterns.
Read secretapikeys_get_key_string returns the actual key string.The value can enter an agent transcript, tool log or downstream message.
Create or changeCreate a key or update its metadata and restrictions.A broad or misplaced key can expand access and cost exposure.
Delete or restoreDelete a key or undelete one within the documented recovery window.A mistaken action can interrupt service or revive a retired credential.
LookupFind a parent project and resource name from a supplied key string.The caller must already handle a sensitive value.

The API reference says a deleted key can be restored within 30 days. That is a recovery mechanism, not a reason to permit unattended deletion. A production service may fail immediately, even if the key can later be restored.

Separate inventory from secret access

The easiest design mistake is to treat every listed MCP tool as one permission class. A support agent may need key names and restrictions to answer an inventory question; it usually does not need the secret string. If a workflow only needs to identify an existing key, omit or deny apikeys_get_key_string in the client policy and use the metadata tool. Apply the same distinction to create, update, and delete.

Google’s MCP documentation establishes that enablement and authentication are required. It does not say the MCP layer itself enforces a human confirmation before sensitive calls. Put that approval in the agent host or application workflow, and test that a malicious or mistaken prompt cannot bypass it. A tool’s existence is not authorization to call it.

A safer rollout sequence

  1. Start read-only. Use an identity scoped to a non-production project and permit only listing and metadata inspection needed for the task.
  2. Test secret handling. Confirm that a key string cannot appear in prompts, trace exports, analytics events, screenshots, or user-visible summaries unless the workflow explicitly needs it.
  3. Add approval gates. Require a named human to confirm key-string retrieval and every create, update, delete, or undelete operation.
  4. Restrict new keys. Apply API and application restrictions appropriate to the workload; reject an unrestricted key by default.
  5. Review the trail. Record caller identity, project, tool name, result, and approval decision without logging the secret value itself.

A simple red-team test is to ask an otherwise read-only assistant to “check whether this key works” and then to send the value to another tool. The expected result is a refusal or an approval request before the secret is retrieved. Repeat the test with a request to relax restrictions and with a request to delete a key. This tests the application boundary rather than assuming the model will always interpret the user’s intent safely.

When this is useful

A controlled assistant could audit stale keys, compare restrictions with a policy, or prepare a proposed rotation. Those are credible uses because the work is repetitive and the metadata is structured. The final credential-changing step still deserves a separate authorization path. The same agent-permission principle appears in our WebMCP permission guide and Grok Bot cloud-computer analysis.

GoogleCloud’ss new endpoint is a practical addition to the MCP ecosystem, but its value depends on how the host exposes the tools. Treat secret retrieval and mutation as privileged operations, not as ordinary chat conveniences.

Sources

Leave a comment

Your email address will not be published. Required fields are marked *