# AI API key inventory: track every AI credential you hold

URL: https://infro.io/blog/ai-credential-inventory
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> An AI credential inventory lists every credential that can call or administer an AI provider on your behalf: provider API keys, provider admin keys, cloud roles and keys (Bedrock, Vertex, Azure), gateway keys, management and MCP tokens, and keys you have given to third-party tools such as coding agents and BYOK platforms. For each, record the owner, the holder, the scope, the spend limit, the network restriction, the expiry or rotation date, the revocation path and when it was last used. Build it from the providers' key-listing APIs, cloud IAM reports, your secret managers and secret scanning, and review it monthly.

Key takeaways:
- Inventory every credential that can spend on or administer an AI account, including keys you handed to third-party tools.
- Record owner and holder separately: the person accountable for a key is rarely the system that stores it.
- Every row needs a revocation path someone has tried, not just a rotation date.
- Providers' own listings have gaps: Anthropic's key list has no last-used field, and the AWS credential report omits Bedrock long-term API keys.
- Record each key's provider-side ID when you create it, so usage reports can be mapped back to the row.

**What is an AI API key inventory?** It is a list of every credential that can call or administer an AI provider on your behalf, with, for each one, who is accountable for it, where it is stored, what it can reach, how much it can spend, when it expires or is rotated, how to revoke it and when it was last used. It is the document you need in the first ten minutes of a key leak, and the one most teams discover they do not have.

AI credentials multiply quickly. Each provider adds inference keys per project or workspace and admin keys for reporting. Cloud providers add roles, service accounts and their own API key types. A gateway adds its own keys and tokens. And every tool that "brings your own key", from coding agents to evaluation services to BYOK platforms, holds a copy of something that spends your money. OWASP's guidance is that it "should be immediately apparent to an organization what a secret is used for and where to find it"[1]. This guide is how to make that true for AI.

## What counts as an AI credential

Include anything that can spend on, read from or change an AI account:

| Class | Examples | Why it matters |
| --- | --- | --- |
| Provider inference keys | OpenAI project keys, Anthropic workspace or service account keys, Gemini API keys, Mistral, Groq and other provider keys | Spend money and send data under your account |
| Provider admin keys | OpenAI admin keys, Anthropic Admin API keys | Create keys, change members, read usage and cost; the widest blast radius |
| Cloud roles and keys | IAM roles and Bedrock API keys, Vertex AI service accounts, Azure resource keys and app registrations | Inference plus whatever else the role allows in that cloud |
| Gateway keys | Keys your applications send to your gateway | Spend through the gateway, within its limits |
| Management and MCP tokens | Gateway management API tokens, tokens and OAuth grants that let assistants act on your configuration or tools | Change policy, read history, call tools |
| Keys held by third parties | Keys saved in coding agents, consoles, BYOK platforms, SaaS features, contractors' machines | You do not control how they are stored |
| CI and deployment secrets | Provider keys in CI variables, deployment configs, secret managers | Often the oldest and least-reviewed copies |

The last two rows are the ones inventories miss. A key you gave to a tool is still your key: it spends on your account, and its exposure is your incident. The [OpenCode Console incident](https://infro.io/blog/opencode-console-breach-what-happened) is a recent reminder that keys saved in a third-party workspace can be exposed in that third party's breach.

## The columns that matter

OWASP lists the metadata a secrets system should hold: lifecycle events and who performed them, who to contact, intended consumers and purpose, type, and when rotation is due[1]. For AI credentials, these columns cover it:

- **ID and name.** The provider's identifier for the key (`key_…` at OpenAI, `apikey_…` at Anthropic), and a name that says what it is for. The provider ID is what usage reports use; without it you cannot map usage back to the row.
- **Class and provider.** From the table above.
- **Account scope.** Organization, project, workspace, cloud account or subscription the key belongs to.
- **Owner.** The person accountable for the key: who decides whether it should exist. A team alias is fine if someone answers it.
- **Holder.** Where the key actually lives: a secret manager path, a gateway connection, a vendor's workspace, a CI variable, a laptop. Owner and holder are different questions; a leak investigation needs both.
- **Permissions.** What it can do: inference only, which models, admin scopes, read-only.
- **Spend limit.** The hard limit on its project or workspace at the provider, and any gateway limit on it.
- **Network restriction.** IP allowlist or API key restriction, if any.
- **Created, expires, rotation due.** Dates. Expiry where the provider supports it; a rotation date where it does not.
- **Revocation path.** Exactly where and how the key is killed, and who can do it. "Delete in OpenAI project `eval-prod` → API keys" is a path; "rotate" is not.
- **Last used.** From the provider where it reports it; from usage reports where it does not.
- **Last reviewed.** When someone last confirmed the row is true.

## Where to find each credential

### OpenAI

`GET /v1/organization/projects/{project_id}/api_keys` lists a project's keys with `id`, `name`, `created_at`, `last_used_at` and the owning user or service account. Pass `owner_project_access=any`; without it, the endpoint applies membership-based visibility rules that "may exclude some enabled keys"[2]. Admin keys are listed by `GET /v1/organization/admin_api_keys`, with `redacted_value`, `created_at`, `expires_at`, `last_used_at` and owner[3]. Both need an admin key.

### Anthropic

`GET /v1/organizations/api_keys` lists keys with `id`, `name`, `status` (`active`, `inactive`, `expired`, `archived`), `created_at`, `created_by`, `expires_at`, `partial_key_hint`, the `principal` the key acts as, and its `scope` (one workspace, or the organization for a principal-bound key)[4]. There is no last-used field. To fill that column, group the usage report by `api_key_id`: it shows which keys carried traffic, by day or by hour[5].

### AWS and Amazon Bedrock

The IAM credential report lists users with their access keys' last-rotated and last-used dates, but AWS notes it does not include service-specific credentials "such as … Amazon Bedrock long-term API keys", and covers only the first two access keys per user; AWS points to `ListServiceSpecificCredentials` and `ListAccessKeys` for complete visibility[6]. Bedrock long-term API keys create an IAM user with attached policies, and AWS recommends them only for exploration; short-term keys last up to 12 hours and inherit the permissions of the principal that generated them[7]. Inventory the principals that may generate short-term keys rather than each key.

### Google Cloud and the Gemini API

`gcloud services api-keys list` lists a project's API keys; `--show-deleted` includes deleted ones, and a deleted key can be restored within 30 days[8]. Record each key's restrictions: Google calls unrestricted keys insecure and recommends both API and application restrictions[8]. Do this for every project with the Gemini API or Vertex AI enabled, not only the ones you remember.

### Code, configuration and tools

Secret scanning finds the copies nobody registered. GitHub's supported patterns include OpenAI API keys and Anthropic API, Admin API and service account keys, with push protection; its Google Gemini API key pattern raises user alerts but, on 2026-10-21, not push protection or partner alerts[9]. Scan repositories, CI logs and shared drives, and ask every team which tools they have given a key to. The answers to that question are usually the longest part of the inventory.

## A template to copy

```text
id,name,class,provider,account_scope,owner,holder,permissions,spend_limit,network_restriction,created,expires,rotation_due,revocation_path,last_used,last_reviewed,notes
key_abc123,support-assistant-prod,provider-inference,OpenAI,project support-prod,ai-platform@,gateway connection openai-support-prod,models: chat only,project hard limit,project IP allowlist,2026-09-02,,2026-12-01,"OpenAI > project support-prod > API keys > delete; owner or project owner",2026-10-20,2026-10-21,
apikey_01xyz,eval-nightly,provider-inference,Anthropic,workspace eval,ml-eval@,CI secret ANTHROPIC_EVAL_KEY,workspace eval only,workspace spend limit,none,2026-08-14,2027-02-14,2026-11-14,"Claude Console > API keys > delete; workspace admin",2026-10-21,2026-10-21,usage from usage report
admin-openai-recon,openai-billing-reader,provider-admin,OpenAI,organization,finops@,secret manager path ai/openai-admin,admin endpoints,n/a,n/a,2026-07-01,2027-01-01,2027-01-01,"OpenAI > organization > admin keys > delete; org owner",2026-10-21,2026-10-21,read-only use
vendor-coding-agent,coding-agent-team-a,third-party,Anthropic,workspace coding-agents,eng-tools@,vendor workspace (SaaS),workspace coding-agents,workspace spend limit,none,2026-10-01,,2027-01-01,"Claude Console > API keys > delete, then remove from vendor",2026-10-21,2026-10-21,vendor stores the key
```

The rows are illustrative. Keep the real file where access is controlled; it names where every secret lives, which makes it sensitive even though it holds no secret values. Never put a key's value in the inventory.

> **Example: Filling one row during a review**
> During the monthly review, an engineer finds an Anthropic key named `prototype-rag` with status `active`, no expiry, created by a former contractor, scoped to the Default Workspace. The usage report shows traffic on it every night. The owner column is empty and the holder is unknown. The decision is not "rotate it": it is "who uses this?" The team posts the key's name and hint, finds a cron job on a forgotten VM, moves the job to a gateway key in its own workspace with a spend limit, and revokes the old key. The row ends with a holder, an owner and a status of `revoked`, and the incident that did not happen is recorded in the notes.

## Keeping it true

An inventory that is right once and stale after is a false sense of safety. Four habits keep it current:

1. **Automate discovery.** Run the listing calls above weekly and diff them against the inventory. A key that exists at the provider and not in the inventory is a finding; so is a row whose key no longer exists.
2. **Make creation the entry point.** Whoever creates a key adds the row in the same change, including the provider ID. Gateways and secret managers that log key creation make this checkable.
3. **Tie rows to people.** On a leaver, every row they own or hold is reviewed that day. On a vendor change, every key that vendor holds is revoked or re-issued.
4. **Compare usage against rows.** A key with traffic and no row, or a row marked idle whose key has traffic, is the earliest sign of a leak. [Detecting gateway bypass](https://infro.io/blog/detect-gateway-bypass-provider-usage) shows the comparison.

When something does go wrong, the inventory feeds the timeline and blast-radius sections of the [incident postmortem](https://infro.io/blog/ai-credential-incident-postmortem-template).

## INFRO credentials in your inventory

If you use INFRO, it appears in the inventory in two ways, and both belong there.

- **As a holder of provider keys.** Each provider connection you add holds a provider key. INFRO encrypts it with AES-256-GCM under a key held outside the database, bound to your organization and connection, never shows it again after saving, and shows only the last four characters in the console; see [Connect a provider](https://infro.io/docs/providers). Record each connection as a row with holder "INFRO connection <name>". The revocation path is at the provider: replacing the key in INFRO does not revoke the old one there.
- **As an issuer of its own credentials.** Gateway keys (`sk_infro_`) carry a label, project, environment, optional expiry, spend limit and allowed networks, and can be rotated with an overlap window; management tokens (`mt_infro_`) always expire. Key and token changes are recorded in the [audit log](https://infro.io/docs/org/audit-log), and the management API exposes gateway keys as a `gateway_keys` resource, so discovery can be automated with a [management token](https://infro.io/docs/manage/tokens).

INFRO's controls govern traffic that goes through INFRO. A provider key stolen from anywhere, including from a platform like INFRO that holds customers' provider keys, can be used directly against the provider. That is why each provider-key row still needs its own provider-side spend limit, restriction and revocation path, whoever holds it.

## Inventory checklist

- [ ] Every provider account, project and workspace has been listed, and every key in it has a row.
- [ ] Admin keys are in the inventory, each with a single holder and a read-only use where possible.
- [ ] Cloud principals that can call Bedrock, Vertex AI or Azure AI services are listed, including Bedrock long-term API keys found through `ListServiceSpecificCredentials`.
- [ ] Every key held by a third-party tool or platform has a row, with the vendor as holder.
- [ ] Every row has an owner, a holder and a revocation path someone has tried.
- [ ] Provider-side IDs are recorded so usage reports can be mapped to rows.
- [ ] Discovery runs automatically and differences are reviewed weekly; the full inventory is reviewed monthly.

## Questions

### What should an AI API key inventory include?

Every credential that can call or administer an AI provider for you: provider inference keys, provider admin keys, cloud roles and keys used for Bedrock, Vertex AI or Azure, your gateway's keys, management and MCP tokens, and any key you have given to a third-party tool or platform. For each, record owner, holder, scope, spend limit, network restriction, expiry or rotation date, revocation path and last use.

### How do I find when an OpenAI or Anthropic key was last used?

OpenAI's project API key list returns last_used_at for each key, and its admin key list does too. Anthropic's API key list has no last-used field; group its usage report by api_key_id to see which keys carried traffic and when.

### Does the AWS IAM credential report list Amazon Bedrock API keys?

No. AWS says the credential report does not include service-specific credentials such as Amazon Bedrock long-term API keys. Use the IAM ListServiceSpecificCredentials API to find them.

### How often should the inventory be reviewed?

Monthly for the whole inventory, and on every joiner, leaver, vendor change or incident for the rows it touches. Automate the discovery queries so the review is about decisions, not data collection.

## Sources

1. Secrets Management Cheat Sheet — OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html (accessed 2026-10-21)
2. List project API keys (Admin API reference) — OpenAI. https://developers.openai.com/api/reference/resources/admin/subresources/organization/subresources/projects/subresources/api_keys/methods/list (accessed 2026-10-21)
3. List admin API keys (Admin API reference) — OpenAI. https://developers.openai.com/api/reference/resources/admin/subresources/organization/subresources/admin_api_keys/methods/list (accessed 2026-10-21)
4. List API Keys — Anthropic. https://platform.claude.com/docs/en/api/organization/api_keys/list (accessed 2026-10-21)
5. Usage and Cost API — Anthropic. https://platform.claude.com/docs/en/manage-claude/usage-cost-api (accessed 2026-10-21)
6. Generate credential reports for your AWS account — Amazon Web Services. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html (accessed 2026-10-21)
7. API keys — Amazon Web Services. https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html (accessed 2026-10-21)
8. Manage API keys — Google Cloud. https://docs.cloud.google.com/docs/authentication/api-keys (accessed 2026-10-21)
9. Supported secret scanning patterns — GitHub. https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns (accessed 2026-10-21)