# LLM API Key Exposure: The Incident Response Playbook (2026)

> AI provider API keys are now a primary attacker target — the October 2026 Railway incident went after them, and an unverified listing claims to sell an OpenRouter user database and keys. A step-by-step IR playbook for suspected LLM/AI API-key exposure.

Source: https://playciso.com/blog/llm-api-key-exposure-incident-response-playbook · Published: 2026-10-26 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://blog.railway.com/p/preliminary-report-october-security-incident

---

AI and LLM API keys are now a primary attacker target. The confirmed October 2026 **Railway** incident went after AI-provider keys, and an **unverified** underground listing claims to sell an OpenRouter user database and keys. Whether or not that specific claim holds up, the response is the same — so here is a concrete incident-response playbook for suspected LLM/AI API-key exposure. First, the facts, kept honest. ## What's confirmed vs. what's alleged - Confirmed: In the October 21, 2026 Railway security incident, the intruder was attempting to obtain AI-provider API keys — reportedly to run model-distillation attacks — and Railway says it worked with OpenRouter and other providers to revoke potentially compromised keys (The Hacker News). - Alleged / unverified: A threat actor claims to be selling an OpenRouter user database (claimed ~250,000 users) and ~207,000 keys in the sk-or-v1 format, with user and key fields. This claim is not independently verified and has not been confirmed by OpenRouter (coverage). Treat it as an allegation. The point of this piece is not to adjudicate the sale listing. It is that _AI keys are being hunted_ — so if you hold any, assume exposure is a question of when, and be ready. ## Why AI API keys are such a prize They convert straight to money and capability: a stolen key spends your LLM budget and, per the Railway report, can power distillation attacks that clone model behaviour at your expense. They are usually **long-lived and over-permissioned** — no expiry, broad scope — and **scattered** through code, CI logs, images and third-party platforms, so one compromised integration leaks many. It is the [machine-identity problem](/blog/machine-identity-security-a-practical-guide-for-cisos) wearing an AI hat. ## The incident-response playbook Six phases. Containment comes before forensics — a broken integration for ten minutes beats hours of attacker spend. ### 1. Prepare (before anything happens) - Inventory every AI/LLM key, where it lives, and who owns it. - Give each key a hard spend/rate cap and the narrowest scope that works. - Write the rotation runbook now so the response is mechanical under pressure. ### 2. Detect & triage - Confirm the exposure signal: a key in a public repo, a provider/partner breach notice, or anomalous usage. - Pull the provider's per-key usage and billing logs — spend spikes, unfamiliar IPs/regions, unused models, off-hours calls. - Classify blast radius: what can this key reach, and what data flows through it. ### 3. Contain (do this first) - Disable the key immediately — for OpenRouter and similar providers, disable (not delete) so usage history is preserved for the investigation. - Issue a replacement key, scoped and capped, and roll it out to the integration. - Lower or freeze the spend cap on the account while you work. ### 4. Eradicate - Find the root exposure — a leaked secret in code/CI (scan for it), a compromised third-party platform, or an over-shared key — and close it. - Rotate any other secrets that shared the same exposure path (the blast radius from step 2), not just the one key. ### 5. Recover - Verify the new key works and the old one is dead (test a call with the revoked key — it should fail). - Restore normal spend caps once monitoring is clean. - Reconcile the bill: dispute/flag any unauthorized spend with the provider. ### 6. Post-incident - Write it up: timeline, root cause, what the key could reach, what you changed. - Convert the one-off fixes into standing controls (short-lived keys, secrets manager, caps, ownership). - Rehearse it — a key-exposure drill in the IR Playbook Lab turns this page into muscle memory. ## Make the next leak a non-event Short-lived, scoped, capped, owned, and out of code — that is the whole game. Plan rotation with the [Key Rotation Planner](/tools/key-rotation-planner), build the full runbook in the [Incident Response Plan Builder](/tools/incident-response-plan-builder), and when a key does leak, work it through the [Leaked-Credential Response tool →](/tools/leaked-credential-response). A governed key leaking is an inconvenience; an ungoverned one is a headline. ## Frequently asked questions **Was OpenRouter breached?** Not confirmed — the keys-for-sale listing is an unverified threat-actor claim. The confirmed event is the Railway incident, where AI keys were the target. **What do I do now?** Rotate AI keys that could have been exposed (disable-then-recreate for OpenRouter), check usage logs, and set a hard spend cap. **First move in any key-exposure incident?** Contain first — disable/rotate the key before you investigate. **How do I prevent the next one?** Short-lived, scoped, capped, owned keys stored in a secrets manager, never in code or CI logs.