canonical: https://jentic.com/apis/googleapis.com/kmsinventory

# Google KMS Inventory API

The KMS Inventory API gives Google Cloud security teams an organization-wide view of Cloud KMS crypto keys and the resources protected by them. It exposes operations to list every crypto key inside a project, summarize the resources protected by a specific key, and search across an entire organization for resources covered by customer-managed encryption. The API is read-only and complements the standard Cloud KMS API by providing inventory and audit data.

## For AI agents

Inventory Cloud KMS keys across a project and search for resources protected by customer-managed encryption keys at organization scope. Read-only audit data for security teams.

## Scope

Does not create, rotate, or destroy keys, encrypt data, or manage IAM policies - use only to inventory crypto keys and search for resources they protect.

## Capabilities

- List all Cloud KMS crypto keys inside a Google Cloud project
- Summarize the resources protected by a specific crypto key
- Search an entire organization for resources covered by customer-managed encryption
- Audit which BigQuery, Cloud Storage, and Compute resources rely on a key before rotation
- Identify keys with no protected resources for cost cleanup
- Generate compliance evidence for CMEK coverage across an organization

## Use cases

### Pre-rotation impact assessment

Before rotating or destroying a Cloud KMS key, security teams need to know exactly which resources depend on it. Calling /v1/{+name}/protectedResourcesSummary on the key returns counts grouped by resource type and project, so the agent can confirm the rotation will not orphan production data.

Example prompt: Call GET /v1/projects/{p}/locations/{l}/keyRings/{kr}/cryptoKeys/{k}/protectedResourcesSummary and return the resourceCount grouped by cloudProduct.

### Organization-wide CMEK compliance audit

Compliance teams must demonstrate that regulated workloads use customer-managed encryption keys. The /v1/{+scope}/protectedResources:search endpoint lists every protected resource across an organization, optionally filtered by crypto key, so the agent can produce evidence that BigQuery datasets, Cloud Storage buckets, and Compute disks all sit behind CMEK.

Example prompt: Call protectedResources:search with scope=organizations/{orgId}&cryptoKey={keyName} and return the list of resource names.

### Cleanup of unused crypto keys

Each Cloud KMS key version costs money even when nothing references it. By listing keys with /v1/{+parent}/cryptoKeys then checking protectedResourcesSummary for each, an agent can identify keys with zero protected resources that are safe to schedule for destruction.

Example prompt: List crypto keys in a project then for each key with resourceCount=0, output the key resource name for review.

### Agent-driven CMEK reporting via Jentic

A security agent triggered by a quarterly compliance review can use Jentic to call the three KMS Inventory operations without writing GCP-specific resource path code. Jentic returns the search and summary schemas in a uniform shape so the agent can feed results straight into a compliance report.

Example prompt: Run google_kmsinventory_search_protected_resources for the organization and write the returned resource list to the compliance bucket.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{+parent}/cryptoKeys | List crypto keys inside a project |
| GET | /v1/{+name}/protectedResourcesSummary | Summarize resources protected by a specific crypto key |
| GET | /v1/{+scope}/protectedResources:search | Search organization-wide for protected resources |

## Key resources

- **cryptoKeys** — List all Cloud KMS crypto keys within a project
- **protectedResourcesSummary** — Per-key summary of protected resource counts grouped by product and project
- **protectedResources** — Search across an organization for resources protected by customer-managed encryption

## Why Jentic

- **Setup:** Wiring the KMS Inventory API by hand means configuring service-account OAuth2, narrowing to the cloud-platform scope, refreshing tokens, and learning its scope, parent, and name resource paths yourself. Through Jentic you install once, import the KMS Inventory API from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** Resource names travel in the URL path (/v1/{parent}/cryptoKeys, /v1/{scope}/protectedResources:search), so a rule can pin your agent to one project or organisation scope: it inventories keys and protected resources under that scope and nothing else. Every endpoint here is read-only, so the agent can list and search but never create, rotate, or destroy a key.
- **Credential handling:** Your GCP service-account credential is stored once, encrypted, by your own Jentic One instance and injected at execution time as a short-lived cloud-platform access token. The JSON key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list resources protected by a kms key' or 'find crypto keys in an org', and Jentic returns the matching v1 operation with its input schema so the agent uses the right scope and parent templates without browsing the reference docs.

## Related APIs

- **Cloud Key Management Service API** — Cloud KMS creates, rotates, and uses keys; KMS Inventory reports on what those keys protect
- **Secret Manager API** — Secret Manager stores API keys and credentials; KMS Inventory audits the encryption keys protecting them
- **Cloud Identity API** — Cloud Identity manages users and groups; KMS Inventory tracks the keys encrypting their data

## FAQ

### What authentication does the KMS Inventory API use?

OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope, using a service account that has cloudkms.protectedResourcesSummary.get and cloudkms.protectedResources.search IAM permissions at the organization level. Through Jentic the service account JSON sits in the encrypted vault and only a short-lived access token reaches the agent.

### How is KMS Inventory different from the Cloud KMS API?

The Cloud KMS API manages keys (create, rotate, encrypt, decrypt, destroy). The KMS Inventory API is read-only and answers a different question: which resources are currently protected by a given key, across an entire project or organization.

### What are the rate limits for the KMS Inventory API?

Google enforces a default of 60 read requests per minute per project for inventory operations. The protectedResources:search endpoint also caps page size at 500 resources, so large organizations need to paginate.

### How do I audit CMEK coverage through Jentic?

Run jentic search 'list resources protected by a kms key' to surface protectedResources:search, jentic load to retrieve its parameters, then jentic execute with scope=organizations/{orgId} and an optional cryptoKey filter. Jentic returns the paginated resource list ready for a compliance report.

### Can I find unused crypto keys with this API?

Yes. List crypto keys in a project with GET /v1/{+parent}/cryptoKeys, then call protectedResourcesSummary on each - keys whose resourceCount is zero are unreferenced and candidates for scheduled destruction.

### Is the KMS Inventory API free?

The inventory API itself has no per-call charge; you only pay for the underlying Cloud KMS keys and key versions. Quota is governed by the Cloud KMS API service in the project.

### Can I limit what my agent is allowed to do with the KMS Inventory API?

Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials your agent may use, and every operation here is read-only, so the agent can list crypto keys and search protected resources but can never create, rotate, or destroy a key. Since the project or organization scope travels in the URL path for cryptoKeys, protectedResourcesSummary, and protectedResources:search, a rule can pin the agent to a single project or organization and nothing outside it. Your GCP service-account credential stays with your instance and is injected only at execution time as a short-lived access token.