AI provider API keys have become a currency: they buy compute, model access and sometimes data, so attackers now hunt them deliberately and resell what they find. The breaches behind this are not one technique but six repeating patterns, from keys committed to public code to platforms that store thousands of customers' keys in one place. This guide maps those patterns across eleven incidents from the NHI Mgmt Group breach database, shows which control breaks each one, and sets out a rollout order and the measures that prove it is working. It is for platform, AI engineering and security teams who issue or hold keys for OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock and similar services. Prevention basics are in the LLMjacking Guide and incident steps are in the LLMjacking Response Playbook; this page does not repeat them.
Key takeaways
- Keys are central to AI breaches. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) counts API keys among the identities abused in 26 of its 64 AI-related breaches, and finds that 79% of 2026 AI-related breaches also abused a key, token or credential (26 of 33).
- Six patterns cover almost every case. Public leaks, harvesting from compromised hosts, custodian breaches, malicious tools, silent scope expansion and agents using keys they find.
- Revocation must happen at the provider. Deleting a key in a gateway, plugin or middleman console does not stop it working upstream, as the OpenCode Console breach showed.
- Spend limits are a security control. Hard caps per key or project bound the damage of every pattern; alerts alone do not block traffic.
- Ownership is the first step. The report's 30-day plan says to find every AI agent, MCP server and AI API key and give each an owner, because no other control works on a key nobody knows exists.
What the breach data shows
The report records API keys as an abused identity type in 57 breaches overall, and "leaked secret with API key" as one of the most common route and identity combinations (21 breaches). Within AI-related breaches, leaked secrets were one of the three most common routes (13, level with vulnerability exploits and supply chain). The direction of travel is the point: AI-related breaches rose from 7 of 38 in 2024 to 33 of 53 in 2026 so far, and most of the 2026 cases still rest on a credential. The report's label for the economic side of this, LLMjacking, covers stolen cloud credentials and API keys turned into free AI for attackers.
Six breach patterns
| Pattern | Incidents | What went wrong | Control that breaks it |
|---|---|---|---|
| 1. Key leaked in public code or content | xAI, Sourcegraph | xAI: a key in an .env file on public GitHub stayed valid about 59 days; the scanner's email went only to the developer. Sourcegraph: a token committed to public code was abused 47 days later to build a free LLM proxy | Push protection and scanning that routes alerts to an owned security queue with revocation, not a notice |
| 2. Keys harvested from compromised hosts or cloud accounts | LLMjacking, Carbonato botnet | Cloud credentials from a vulnerable Laravel server enabled Bedrock use; an AI agent on exposed Docker hosts (port 2375) hunted AI keys first to feed the operators' own gateway | Workload identity instead of static keys; deny model access by default; spend caps |
| 3. Custodian breach: a platform holding many customers' keys | OpenCode Console, Railway, Moltbook | OpenCode: stored OpenAI, Anthropic and Google keys stolen from a legacy system. Railway: CI credentials decrypted customer variables, with AI keys the stated target. Moltbook: an open Supabase database exposed about 1.5 million agent keys | Per-tool keys with caps; ask vendors how keys are stored; hash agent keys; bulk revocation |
| 4. Malicious tools that collect keys | JetBrains AI plugins | 15 working AI assistant plugins (about 70,000 installs) forwarded the key the moment a user clicked Apply | Plugin allow-lists; a register of where each key was entered; developer keys with low caps |
| 5. Silent scope expansion | Google API keys and Gemini | Public Maps and Firebase keys gained Gemini access when the API was enabled on the same project; Truffle Security found 2,863 live keys with Gemini access | API and application restrictions on every key; separate projects for public and AI workloads |
| 6. Agents and resellers using keys they find | OpenAI agents and Census keys, Storm-2139 | Agents used Census API keys others had posted on GitHub; Storm-2139 used exposed Azure OpenAI customer keys to bypass guardrails and resell access | Treat even read-only keys as identities; restrict by network and deployment; prefer keyless auth |
Cross-breach lessons
Detection by notification is not revocation
In the xAI case automated scanning found the key on the day of the commit and emailed the developer, yet the key stayed live for about two months. Sourcegraph's token sat in public code for 47 days. The fix is organisational: secret scanning findings for AI keys go to a monitored queue with a named owner and a revocation deadline in hours. See the Developer Secret Scanning Triage guide.
Every middleman is a key custodian
OpenCode, Railway, Moltbook and the JetBrains plugins all held keys on behalf of users. The lesson drawn on the OpenCode breach page applies to all of them: a service holding many customers' keys becomes a single high-value target, and its budget controls do not cap use of a stolen key outside its own gateway. Give each tool its own key, with its own cap, so one custodian breach is one revocation and one bounded bill.
The bill is the first alarm
Sourcegraph found its attacker through a spike in API usage. Users of OpenCode Console noticed unauthorised charges on their own provider accounts. Google suspended projects for "abusive activity consistent with hijacked resources". OWASP's LLM10:2025 Unbounded Consumption names this Denial of Wallet. OpenAI's own guidance is to set monthly spend limits with hard enforcement, because alerts alone do not stop traffic.
Keys change meaning without changing value
The Google case is the clearest warning: a key that was safe to publish for Maps became a secret when someone enabled Gemini on the project. Google Cloud's documentation says unrestricted API keys are insecure and recommends both API and application restrictions. Treat enabling a new AI API as a change to every credential in that project.
Agents make leaked keys routine
The OpenAI Census case shows that agents with internet access will find and use leaked credentials as an ordinary step towards a task, and that logs then point to the key owner, not the agent operator. A leaked key is now likely to be used even when no human attacker is looking for it.
Controls mapped to the patterns
| Control | Patterns it breaks | How to apply it |
|---|---|---|
| Keyless or federated authentication | 1, 2, 6 | Use cloud roles and workload identity for Bedrock, Vertex AI and Azure OpenAI; disable key-based auth where the service allows. See the Workload Identity Federation Guide. |
| One key per application, tool and environment | 3, 4 | Never share a key across tools; OpenAI recommends a unique key per team member. Record where each key is entered. |
| Hard spend caps and quotas per key or project | All | Set hard monthly limits at the provider and per-key quotas; alert at a fraction of the cap. |
| API and application restrictions | 5, 6 | Restrict each Google key to named APIs and to referrers, IPs or app signatures; use Cloud Asset Inventory to find unrestricted keys. |
| Central gateway with logging | 2, 3, 4 | Route model calls through an internal gateway that holds provider keys server-side. See the AI Gateway and LLM Gateway Guide. |
| Expiring keys and rehearsed rotation | 1, 3 | Use keys with expiry dates where offered; create the replacement, update applications, then revoke at the provider. |
| Secret scanning with push protection | 1, 6 | Block AI key formats at commit; scan public sources for your own keys, not just your repositories. |
| Tool and plugin allow-lists | 4 | Approve IDE plugins, MCP servers and agent skills before use; alert on plaintext HTTP from IDE processes. |
Provider-specific settings are covered in the OpenAI API Keys Security Guide, the Anthropic API Keys Security Guide, the Google API Keys Security Guide and the Azure OpenAI and Azure AI Foundry Security Guide.
Implementation: a phased approach
- Inventory (week 1): list every AI provider account, project and key, and every tool, plugin, gateway or platform that holds one. Assign an owner to each key; keys with no owner after a week are revoked.
- Cap the damage (week 1 to 2): set hard spend limits and per-key quotas on every provider account before changing anything else. This is cheap and breaks no workloads.
- Find exposed keys (weeks 1 to 3): scan repositories, CI logs, container images, tickets, chat and public code for AI key formats. Rotate anything found at the provider, not only in the tool.
- Restrict and split (weeks 3 to 6): apply API and application restrictions; split shared keys into one per application and environment; move public and AI workloads into separate projects.
- Move to keyless (weeks 6 to 12): pilot workload identity for one cloud-hosted model service, keep the old key available for rollback for one release cycle, then disable it.
- Turn on logging and alerting (in parallel): enable model invocation logging where it is off by default (AWS Bedrock is disabled by default) and alert on the signals below.
- Rehearse response: run the LLMjacking Response Playbook as a tabletop against one custodian breach scenario.
Decision guidance
- Direct keys or a gateway: small teams with one or two applications can hold provider keys directly in a secrets manager with caps. Once several teams or tools use models, a central gateway reduces the number of keys in circulation and gives one place to log and cap.
- Hosted model service or direct provider: cloud-hosted services such as Bedrock, Vertex AI and Azure OpenAI can use cloud identities instead of static keys; direct provider APIs usually need a key, so rely on caps, scoping and rotation.
- Third-party tools that ask for your key: prefer tools that call your gateway rather than store your provider key. If a tool must hold a key, give it a dedicated low-cap key and record it.
- Agent platforms: where agents authenticate with their own API key, as on Moltbook, the key is the agent's identity; store only hashes, set expiry and support bulk revocation.
Detection and measurement
Signals that have preceded or revealed abuse in these incidents: sudden usage or spend spikes per key; first use of a model or region; calls from new IP ranges or ASNs; on AWS, GetModelInvocationLoggingConfiguration calls, model access requests such as PutUseCaseForModelAccess, and test InvokeModel calls with invalid parameters, as described on the LLMjacking breach page; changes to logging configuration; and provider notices of suspended projects or blocked keys. Bedrock invocation logs include the caller's identity.arn, model ID and token counts, which makes per-identity baselines possible.
| Metric | Target direction |
|---|---|
| AI keys with a named owner | 100% |
| Provider accounts and projects with a hard spend cap | 100% |
| Median time from leaked AI key detection to provider revocation | Hours, not days |
| Keys shared across more than one tool or environment | Falling to zero |
| Model calls made through keyless identities or the gateway | Rising |
| Unrestricted Google API keys | Zero |
Common failure patterns
- Alerting the developer instead of revoking: the xAI key stayed live for about two months after detection.
- Deleting the key in the tool, not at the provider: custodian breaches such as OpenCode need upstream revocation.
- One key for everything: a shared key turns one leak into an outage when it is rotated, so teams delay rotation.
- Logging left at default: without invocation logs there is no way to see what a stolen key was used for.
- Assuming public keys stay harmless: the Gemini case turned published keys into secrets overnight.
- Legacy systems keeping secret access: OpenCode's breach came through a legacy system that still held keys.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1496.004 Cloud Service Hijacking; T1552.001 Credentials In Files; T1078.004 Cloud Accounts | Resource abuse with stolen keys; keys in files; stolen cloud credentials |
| MITRE ATLAS | AML.T0012 Valid Accounts | Use of valid credentials against AI services |
| OWASP Top 10 for LLM Applications 2025 | LLM10:2025 Unbounded Consumption | Denial of Wallet and unauthorised usage |
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management; AC-6 Least Privilege; AU-12 Audit Record Generation; SI-4 System Monitoring | Key lifecycle, scoping, logging, usage monitoring |
| NIST CSF 2.0 | PR.AA-01; PR.AA-05; DE.CM-03 | Credential management, permissions, usage monitoring |
Practitioner checklist
- Inventory every AI provider key and every tool or platform that holds one, each with an owner.
- Set hard spend caps and per-key quotas on every provider account and project.
- Issue one key per application, tool and environment; never share keys across tools.
- Route leaked-key alerts to an owned queue and revoke at the provider within hours.
- Restrict Google API keys by API and application; separate public and AI projects.
- Prefer workload identity for cloud-hosted model services and disable key auth where possible.
- Enable model invocation logging and alert on spend spikes, first-time model use and logging changes.
- Allow-list IDE plugins, MCP servers and agent skills that handle keys.
- Ask every vendor that stores your AI keys how they are encrypted, who can decrypt them and how fast they revoke.
Standards and references
- OWASP: Top 10 for LLM Applications 2025 (LLM10 Unbounded Consumption)
- OpenAI: Best practices for API key safety
- Google Cloud: Manage API keys
- AWS: Amazon Bedrock model invocation logging
- MITRE ATT&CK: T1496.004 Cloud Service Hijacking
- MITRE ATLAS: Valid Accounts
- NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
Related NHI Mgmt Group resources: LLMjacking Guide · LLMjacking Response Playbook · API Key Management Guide · AI Gateway and LLM Gateway Guide