# AI API key security checklist: 48 controls to verify

URL: https://infro.io/blog/ai-api-key-security-checklist
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: Checklist

> Secure AI API keys by giving every application, environment, agent and third-party tool its own key, scoped at the provider and capped with a provider spend limit; keeping keys in a secrets manager, never in code, browsers or mobile apps; recording every key in an inventory; watching usage at the provider; rotating on a schedule with an overlap; and rehearsing revocation before you need it.

Key takeaways:
- One key per application, environment, agent and third-party tool, so revoking one never breaks another.
- Scope every key at the provider and cap it with a provider spend limit; that is the only control that still applies to a stolen key.
- Keep an inventory, watch usage at the provider, and rehearse revocation before an incident makes you.

**How do you secure an AI API key?** Give every application, environment, agent and third-party tool its own key; scope each one at the provider and cap it with a provider spend limit; keep keys in a secrets manager and never in code, browsers or mobile apps; record every key in an inventory; watch usage at the provider; rotate with an overlap on a schedule; and rehearse revocation before you need it. The 48 controls below break that down by the moment each applies.

Use this as a review, not a reading list. Each item should end with evidence — a screenshot of a limit, an inventory row, a rotation log — or a recorded decision that it does not apply. Each links to the guide that explains it.

> **Warning: Read this first**
> Gateway budgets, allowlists and monitoring govern only the traffic that passes through them. A provider key used directly against the provider — by an attacker who copied it from anywhere — meets only the provider's own controls: the key's scope, the provider spend limit and revocation. The items marked **(provider)** are the ones that still hold in that case.

## Create

- [ ] One key per application and environment; never one shared key for everything ([secure LLM API keys](https://infro.io/blog/secure-llm-api-keys)).
- [ ] One key per third-party tool, never your production key ([third-party AI tools](https://infro.io/blog/third-party-ai-tools-key-storage)).
- [ ] One key per agent or automated job, not a developer's personal key ([zero trust for AI API access](https://infro.io/blog/zero-trust-ai-api-access)).
- [ ] Every key has a named owner and a written purpose ([AI credential inventory](https://infro.io/blog/ai-credential-inventory)).
- [ ] An expiration date set where the provider supports it; OpenAI strongly recommends one on project keys[1] **(provider)**.
- [ ] Admin and usage-reporting keys kept separate from inference keys ([provider admin key least privilege](https://infro.io/blog/provider-admin-key-least-privilege)).

## Store

- [ ] Keys loaded at runtime from an environment variable or secrets manager, never written in code[2] ([secure LLM API keys](https://infro.io/blog/secure-llm-api-keys)).
- [ ] No key in a repository, including history, notebooks and example configs ([GitHub secret scanning for AI keys](https://infro.io/blog/ai-api-keys-github-secret-scanning)).
- [ ] Secret scanning enabled on every repository and in pre-commit hooks ([GitHub secret scanning for AI keys](https://infro.io/blog/ai-api-keys-github-secret-scanning)).
- [ ] Encryption keys stored apart from the secrets they protect[3] ([BYOK credential architecture](https://infro.io/blog/byok-credential-architecture)).
- [ ] Access to the secrets store limited to the services and people that need it, and logged ([zero trust for AI API access](https://infro.io/blog/zero-trust-ai-api-access)).

## Scope

- [ ] Each key in its own OpenAI project, Anthropic workspace or Google Cloud project serving only its workload[4] **(provider)** ([provider admin key least privilege](https://infro.io/blog/provider-admin-key-least-privilege)).
- [ ] Google keys carry API restrictions, which Google says reduce the impact of a compromised key[5] **(provider)** ([Google API keys and Gemini](https://infro.io/blog/google-api-keys-gemini-exposure)).
- [ ] Models limited per key or project to what the workload needs ([model access governance](https://infro.io/blog/model-access-governance)).
- [ ] Development keys cannot reach production connections, and an unscoped key reaches less, not more ([gateway key controls and environments](https://infro.io/blog/gateway-key-controls-environments)).
- [ ] Server-side keys restricted to known IP ranges where the platform supports it ([gateway key controls and environments](https://infro.io/blog/gateway-key-controls-environments)).

## Use in applications

- [ ] No provider key in a browser, desktop or mobile app; calls go through your server ([AI API keys in frontend and mobile apps](https://infro.io/blog/ai-api-keys-frontend-mobile-apps)).
- [ ] A public AI feature has per-user limits so it cannot be used as a free proxy ([AI feature abuse](https://infro.io/blog/ai-feature-abuse-free-llm-proxy)).
- [ ] Per-customer limits on any feature your customers can trigger ([per-customer AI usage limits](https://infro.io/blog/per-customer-ai-usage-limits)).
- [ ] Keys never logged, echoed in errors or sent to observability tools ([LLM prompt logging policy](https://infro.io/blog/llm-prompt-logging-policy)).
- [ ] Prompts and responses checked for credentials before they leave or return ([LLM guardrails at the gateway](https://infro.io/blog/llm-guardrails-at-the-gateway)).

## Agents and tools

- [ ] Coding agents use a dedicated, limited key, ideally through a gateway rather than a raw provider key ([Claude Code and Codex through a gateway](https://infro.io/blog/claude-code-codex-through-gateway)).
- [ ] Agent runs have a spend or step bound so a loop stops ([bound AI agent loops](https://infro.io/blog/bound-ai-agent-loops)).
- [ ] Agents cannot read `.env` files, key files or secret stores they do not need ([AI coding agents and secrets exposure](https://infro.io/blog/ai-coding-agents-secrets-exposure)).
- [ ] MCP servers inventoried, pinned and reviewed like dependencies; credentials in their configs scoped ([MCP server credential leaks](https://infro.io/blog/mcp-server-credential-leaks)).
- [ ] Assistant settings checked for base URLs, key helpers and MCP servers nobody added ([AI supply chain attacks in 2026](https://infro.io/blog/ai-supply-chain-attacks-2026)).
- [ ] Dependencies pinned by hash; install and build steps run without provider keys ([AI supply chain attacks in 2026](https://infro.io/blog/ai-supply-chain-attacks-2026)).

## Monitor

- [ ] Usage reviewed at the provider by key, not only in your own tools[5] **(provider)** ([signs an AI API key is abused](https://infro.io/blog/signs-ai-api-key-abused)).
- [ ] Alerts on spend or volume that departs from a scope's usual day ([LLM spend anomalies](https://infro.io/blog/llm-spend-anomalies)).
- [ ] Provider usage compared with gateway traffic to find calls that bypassed it ([detect gateway bypass](https://infro.io/blog/detect-gateway-bypass-provider-usage)).
- [ ] Unapproved keys and accounts looked for, not assumed absent ([shadow AI API usage](https://infro.io/blog/shadow-ai-api-usage)).

## Limit spend

- [ ] A hard spend limit on every project or workspace a key lives in; OpenAI's fails requests with a `429` once reached[6] **(provider)** ([provider spend limits compared](https://infro.io/blog/provider-spend-limits-compared)).
- [ ] Spend alerts set below each hard limit; OpenAI notes alerts alone do not cap spend[6] **(provider)**.
- [ ] Per-key and per-project caps enforced before the provider is called ([LLM spend limits compared](https://infro.io/blog/llm-spend-limits-compared)).
- [ ] The worst case for a stolen key worked out and accepted in writing ([cap a stolen AI key's damage](https://infro.io/blog/cap-stolen-ai-key-damage)).

## Rotate

- [ ] A rotation schedule per key, recorded in the inventory ([AI credential inventory](https://infro.io/blog/ai-credential-inventory)).
- [ ] Rotation creates the replacement, deploys it, verifies it, then revokes the old key[1] ([BYOK credential architecture](https://infro.io/blog/byok-credential-architecture)).
- [ ] Short-lived credentials used where the provider offers them[5] ([short-lived credentials for AI APIs](https://infro.io/blog/short-lived-credentials-ai-apis)).
- [ ] Unused keys deleted rather than left idle[5] **(provider)**.

## Revoke

- [ ] Each team knows how to revoke each of its keys in minutes; OpenAI says revocation takes effect within a few seconds[2] **(provider)**.
- [ ] Revocation rehearsed once per key, end to end, including confirming the old key fails ([leaked OpenAI API key](https://infro.io/blog/leaked-openai-api-key)).
- [ ] Replacing a key inside a gateway or tool is followed by revoking it at the provider ([BYOK credential architecture](https://infro.io/blog/byok-credential-architecture)).

## Third parties

- [ ] Each vendor that holds a key has answered where it is stored, under which encryption key, who can read it, and how it is deleted ([third-party AI tools](https://infro.io/blog/third-party-ai-tools-key-storage)).
- [ ] Each vendor's breach-notification commitment is in a contract, with a time limit ([AI vendor security review questions](https://infro.io/blog/ai-vendor-security-review-questions)).
- [ ] The blast radius of each platform holding your keys has been modelled ([BYOK platform breach](https://infro.io/blog/byok-platform-breach-blast-radius)).

## Incident

- [ ] A runbook for a leaked key: revoke, rotate, delete the exposed copy, review usage from the earliest exposure[3] ([leaked Anthropic API key](https://infro.io/blog/leaked-anthropic-api-key)).
- [ ] The evidence your provider will ask for about unexpected charges is known in advance ([AI API key theft and your bill](https://infro.io/blog/ai-api-key-theft-bill-refund)).
- [ ] A postmortem template ready, so each incident improves the controls above ([AI credential incident postmortem](https://infro.io/blog/ai-credential-incident-postmortem-template)).

## How INFRO covers part of this list

INFRO is a gateway in front of the provider accounts you connect, so it covers the items about traffic that passes through it. Provider keys are encrypted with AES-256-GCM under a key held outside the database and never shown again. Applications and coding agents use INFRO gateway keys, stored as a SHA-256 digest, each belonging to one environment, optionally limited to chosen providers or IP ranges (`403 ip_not_allowed` before any provider call), with expiry and rotation with an overlap of none, 1 hour, 24 hours or 7 days ([authentication](https://infro.io/docs/authentication)). [Model allowlists](https://infro.io/docs/org/model-allowlists), hard [budgets](https://infro.io/docs/org/spend-controls) per organization, project, member and key checked before the provider is called, [spend alerts](https://infro.io/docs/observability/alerts) and the [audit log](https://infro.io/docs/org/audit-log) cover the matching items; on the Business plan, [reconciliation](https://infro.io/docs/cost/reconciliation) with usage access reports OpenAI and Anthropic usage on a connected key that did not go through INFRO.

It does not cover the items marked **(provider)**. A provider key stolen from anywhere, INFRO included, can be used directly at the provider, so scope it, cap it and watch it there as well.

## Questions

### What are OpenAI API key best practices?

Keep the key server-side and out of code and repositories, load it from an environment variable or secrets manager, use a separate project key per application and environment with an expiration date, set a hard spend limit on the project, monitor usage, and rotate on a schedule by creating a replacement, deploying it, and revoking the old key.

### How often should I rotate AI API keys?

On a fixed schedule you can sustain, set by the key's exposure and your policy, and immediately on any suspicion of exposure. More important than the interval is that rotation is rehearsed: create the replacement, deploy it, confirm it works, revoke the old key and confirm the old key fails.

### What is the single most important control for an AI API key?

A provider-side spend limit on a dedicated, scoped key. Every other control can be bypassed by someone who has the key and calls the provider directly; the provider's limit and the key's scope still apply.

## Sources

1. Production best practices — OpenAI. https://developers.openai.com/api/docs/guides/production-best-practices (accessed 2026-10-21)
2. API reference: Authentication — OpenAI. https://developers.openai.com/api/reference/overview (accessed 2026-10-21)
3. Secrets Management Cheat Sheet — OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html (accessed 2026-10-21)
4. Creating and managing Workspaces in the Claude Console — Anthropic. https://support.claude.com/en/articles/9796807-creating-and-managing-workspaces-in-the-claude-console (accessed 2026-10-21)
5. Best practices for managing API keys — Google Cloud. https://docs.cloud.google.com/docs/authentication/api-keys-best-practices (accessed 2026-10-21)
6. Spend limits — OpenAI. https://developers.openai.com/api/docs/guides/spend-limits (accessed 2026-10-21)