AI API key inventory: track every AI credential you hold

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"¹. 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:

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 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¹. 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"². Admin keys are listed by GET /v1/organization/admin_api_keys, with redacted_value, created_at, expires_at, last_used_at and owner³. 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)⁴. 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⁵.

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⁶. 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⁷. 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⁸. Record each key's restrictions: Google calls unrestricted keys insecure and recommends both API and application restrictions⁸. 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⁹. 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

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.

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 shows the comparison.

When something does go wrong, the inventory feeds the timeline and blast-radius sections of the incident postmortem.

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. 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, and the management API exposes gateway keys as a gateway_keys resource, so discovery can be automated with a management token.

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.