AI Startup API Key Security: Lessons From Anthropic, METR and Railway

Attackers in 2026 went after the provider keys AI products keep: an eval sandbox, an exposed agent dashboard, hosting platforms and a hijacked LiteLLM release. What those incidents teach founders about spend caps, key separation, scanning and rotation.

On October 21, the hosting platform Railway told customers it believes a breach of its systems “is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.” If your product sits on top of OpenAI, Anthropic or OpenRouter, that sentence describes your company’s most valuable secret. AI startup API key security is no longer a hygiene item on a seed-stage checklist; the keys are what attackers are hunting.

Where it stands: Railway says an unauthorized party “may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents,” and that it asked the upstream providers to revoke keys. Railway’s notice leaves three gaps: the entry point, the number of affected accounts, and the identity of the other platform companies. The same day, a hijacked LiteLLM release on PyPI was found stealing the provider keys stored by LiteLLM proxies.

What a stolen AI key is worth to someone else

A database password gets an attacker your data. An inference key gets them something they can spend. Anthropic’s September 2026 threat intelligence report breaks the appeal into three words:

  • “Loot : Stolen keys and accounts have resale value in established markets;”
  • “Compute : Having the credentials means that their attack workloads can run at someone else’s expense;”
  • “Cover : The activity is attributed to the credential’s legitimate owner.”

That last one matters for a founder. When a stolen key is used for abuse, the provider’s logs point at your account first. Anthropic’s report adds that “the integrations customers build around AI such as sandboxes, proxies, and resellers are part of the attack surface.” For many AI-wrapper startups, those integrations are the product.

Five ways keys walked out the door in 2026

These incidents are different cases with different victims. No public source ties them to one attacker, and Railway’s “series” remark names no other company. Set side by side, though, they show where provider keys tend to leak.

Incident Where the keys sat The founder lesson
GTG-50020 (Anthropic report) An AI vendor’s automated evaluation sandbox Anything a model can read, a prompt can try to extract
LiteLLM wrapper services (Anthropic report) Cloud containers behind a LiteLLM gateway Gateways concentrate keys from every provider
METR, March 2026 An agent dashboard exposed to the internet Side projects carry production keys too
Railway and Zeabur, October 2026 Hosting platforms’ stored environment variables Your platform’s breach becomes your rotation day
LiteLLM 1.107.0, October 2026 The proxy’s own database, read by a tampered package Dependencies can read whatever your app can

The GTG-50020 case is the one AI founders should read in full. Anthropic says a financially motivated actor got an AI vendor’s evaluation sandbox “to hand over the credentials it held—including the production AI API keys from multiple providers belonging to that vendor.” Then, per the report, “A follow-on campaign run from the same infrastructure attacked roughly thirty AI companies in about four days with similar techniques.” The attacker found one working path “and repeated it against all thirty targets.” The prize the actor was after, according to Anthropic, was a pre-release Claude model: “The actor never gained access; every attempted path failed.” Along the way, the report says, “when they obtained the target’s API keys, they automatically switched to using the victim’s keys instead of their own.”

Separately, the report says several actors compromised “AI wrapper services’ implementation of LiteLLM,” tricking those gateways with injected prompts until they gave up the keys held in their cloud containers. That is a different problem from the October 21 package hijack, where SafeDep found the malicious code “dumps the LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable tables, which hold the LLM provider API keys of a LiteLLM proxy.” Two routes, one destination.

METR’s bill shows why caps come first

METR, an organization that evaluates AI models, published an unusually candid account. A researcher’s vibe-coded app had a bug that “silently disabled authentication,” leaving it reachable from the internet for several days. The attacker “prompted an agent directly to reveal its model provider API key” and used the key for three weeks.

METR says the credits consumed “would have been worth approximately $600,000,” though the model developer had granted them for free. The detail that should stop a founder cold is this one: “there was no natural token spend ceiling, and as of the incident there was no way to put a spending limit on keys like this one.” Afterwards, METR “Added spend alerts to keys where possible.”

For a startup paying for its own tokens, a missing ceiling turns a leak straight into a cash problem. Zeabur, the Taiwan-based hosting platform breached in mid-October, described the attacker’s intent in plain terms in its own report: they were “mainly looking for API keys they could use directly, especially keys for AI services.” Zeabur has since announced it will shut down; we covered what that means for teams on the platform in our Zeabur migration guide.

AI startup API key security: controls the incidents point to

None of these steps is exotic. Each one maps to something that went wrong above, and each is backed by the provider’s own documentation.

Put a ceiling on every key

OpenRouter’s documentation is blunt: “We recommend setting a credit limit on every key.” Its reasoning: “A key with no limit lets a leaked key or a runaway agent spend your entire balance, including any auto top-ups.” Anthropic’s help center describes spend limits and workspace rate limits the same way, saying “These limits act as a safeguard against unexpected usage due to leaked keys or errant scripts.” Where a provider only offers alerts, set them, as METR did.

One key per environment and per use case

Anthropic advises using “different API keys for development, testing, and production environments.” The payoff comes during an incident: “If your API Key is compromised, this allows you to quickly disable just that use case and limit any potential damage.” A shared key across staging, production and an internal agent means one leak takes all three offline at once.

Keep keys out of reach of models and agents

Both the GTG-50020 sandbox and METR’s dashboard leaked because a model or agent could see a live key and was talked into revealing it. Anthropic’s report says organizations “should treat AI keys and agent integrations with the same level of seriousness as they do production credentials.” In practice, that means the key lives in a server-side secret store, the model only ever sees a placeholder, and the evaluation sandbox gets its own low-limit key.

Scan before you push

GitHub now blocks new Anthropic key types with push protection by default, according to its October 13 changelog. That helps with public repos, but private repos, logs and Docker images still need your own scanning. Our earlier piece on startup secrets management after Railway covers tooling choices.

Know who else holds your keys

Anthropic’s key guidance spells out the trade-off of every hosting platform and CI tool: “you are giving the developer of that tool access to your Claude Console account.” Zeabur traced its October breach to its own setup: “long-lived admin credentials were stored in plaintext and could be used from the public internet.” You cannot audit a vendor’s internals, but you can limit what each one holds. Our platform risk breakdown looks at that dependency from the business side.

Write the rotation runbook before the email arrives

When Railway’s disclosure landed, every customer had the same job: find every key, replace it, and kill the old one. A workable runbook has four parts.

  1. An inventory. Every provider key, where it is stored, which service uses it, and who can create a replacement.
  2. The order of operations. Google Cloud’s guidance is a sound default: “generate a new credential, deploy it to all services and users that need it, and then revoke the old credential.” If a key is already suspected stolen, Anthropic’s help center goes further: “If you suspect that your API key may be compromised, we recommend revoking the key immediately.”
  3. Revocation at the source. Fireworks AI warned its customers that “Removing a stored secret alone does not invalidate the underlying credential.” Deleting a variable from your host does nothing to a copy an attacker already holds.
  4. A schedule. Anthropic suggests rotating “on a consistent schedule (for example, every 90 days).” Practising rotation on a calm day is what makes it fast on a bad one.

Railway did one part of this on its customers’ behalf: it says it “notified these upstream providers to revoke all keys proactively.” Railway has not said which providers it contacted.

Frequently Asked Questions

Why do attackers target AI startups for API keys?

Anthropic’s September 2026 threat report lists three payoffs: a stolen key has resale value, it pays for an attacker’s own jobs, and the activity looks like it came from the key’s real owner. A startup that stores keys for several providers offers all three at once.

Does deleting an API key from my hosting platform revoke it?

No. Fireworks AI warned its customers that removing a stored secret does not invalidate the credential, and that third-party keys have to be revoked with the provider that issued them. Revoke at the provider, then remove the old value.

Should each environment have its own AI API key?

Anthropic’s help center recommends separate keys for development, testing and production where possible, so a leaked key can be disabled for one use case without taking everything down.

How often should an AI startup rotate its API keys?

Anthropic gives every 90 days as an example of a regular schedule. Rotate at once, outside that schedule, whenever a platform, gateway or package you rely on reports a breach.

Can a spend limit stop a stolen AI key from being abused?

It caps the damage rather than preventing use. OpenRouter recommends a credit limit on every key because a key without one can spend the whole balance. METR has said its stolen key had no spending ceiling at all.

Sources

This article is general information for founders, not legal or security-consulting advice. Incident details are as reported by the sources cited on the dates shown and can change; for breach-notification duties, talk to counsel.