When a host gets breached, every key on it has to go.

On October 21, 2026, that was every Railway customer. Kip has a plan for the next one.

Keyhouse isn't built yet. Join the waitlist and we'll email you when the hosted beta opens.

That signup didn't go through. Check the address and try again, or wait a minute if you sent several.

What happened on October 21

Kip the hermit crab, leaping for golden keys that are floating out of reach

On October 21, it happened twice in one day.

A breach at Railway and a poisoned LiteLLM release, hours apart, and both reached developers' keys.

A host drawn as a small server house, its roof popped open

RailwayOct 21 · 07:24 UTC
Railway starts investigating. By 09:28, builds are paused in every region.
LiteLLMOct 21 · 11:39 UTC
A poisoned LiteLLM 1.107.0 goes up on PyPI and, for about two hours, steals credentials from every machine that installs it.
RailwayOct 21 · 21:59 UTC
Railway warns that an intruder may have read customers' encrypted environment variables and asks everyone to revoke every variable.
RailwayOct 22 · 04:17 UTC
Railway invalidates every API token.

Different attacks, same instruction. Rotate everything.

Sources: Railway's disclosure, LiteLLM's write-up, and the full timeline on our blog.

Then you rotate every key by hand, one dashboard at a time.

Every key the host held is now suspect, and each one lives at a different provider.

Find every key, on every service, in every environment
Open each provider's dashboard and create a new key
Paste it into the host and redeploy
Revoke the old key and check its usage for strangers
Repeat for the next provider, and the next
Hope you didn't miss one

Every key is a separate dashboard, a separate redeploy and a separate chance to miss one. If you're doing this now, the free Exposure Check makes the list for you.

Kip at a small desk late at night, tired, typing on a laptop while a long checklist unrolls onto the floor

And you have more keys than ever, because you ship faster than ever.

With AI coding agents, one developer can put a new app online in an afternoon, and every app needs its own keys.

Each app takes a handful (OpenAI, Anthropic, Stripe, Resend, a database), and each environment takes them again. More apps means more keys, and every one is a key to rotate after a breach.

Kip standing on top of a mountain of golden keys

Every one of them sits on the host, where the attacker gets in.

Anyone who can read your host's variables holds your real keys.

Most secrets managers still copy the real value into those variables when you deploy, so a breached host leaks it anyway.

api · production · Variables

OPENAI_API_KEY: sk-proj-…; real key
STRIPE_SECRET_KEY: sk_live_…; real key
DATABASE_URL: postgres://…; real password

So what if your host held nothing worth stealing?

Then a breach would cost you a few copies, and not one real key.

Meet Kip. He keeps the real keys and hands your apps copies.

Keyhouse stores each real provider key once. Every app, environment and agent gets its own copy, and a stolen copy is useless anywhere but Keyhouse. Most SDKs only need a new base URL.

On your host today

OPENAI_API_KEY=sk-proj-…
# the real key

With Keyhouse

OPENAI_BASE_URL=https://gw.keyhouse.dev/openai/v1
OPENAI_API_KEY=kh_live_8f2c…
# a copy, refused anywhere but Keyhouse

Keyhouse is in development. This is the planned setup, and the gateway address is illustrative.

api · production
worker · staging
coding agent · 15 min

Next breach, you swap the copies. The real keys never move.

Keyhouse replaces every copy the host held and rewrites the host's variables for you.

Nothing changes at OpenAI or Stripe. The attacker leaves with copies that already stopped working.

A host leaks: Keyhouse replaces every copy on that host.
One app leaks: Only that app's copies change.
A real key leaks: You rotate it once at the provider. Your apps keep their copies.

There's a catch. Keyhouse becomes the one place worth attacking.

A broker with every real key is a bigger target, so the code will be open source and self-hostable. The proxy will never log request bodies, and no endpoint will export a real key.

Your AI agents get copies too, and only when you approve.

An agent sees key names and where they're placed, never values.

To use, create or rotate keys, it asks for a grant scoped to specific keys and actions, for up to 24 hours. Nothing happens until you approve the grant. The MCP server and the dashboard run the same operations.

The next breach ends with 0 real keys lost.

Every rotation will end with a report by app, every use of the old keys in the last 48 hours, and a receipt you can post.

Sample. Keyhouse hasn't rotated anyone's keys yet.

Every claim on this page has a source on the blog.

All posts

October 22, 2026
How API keys leaked in 2026, and the habits that limit the damage
What went wrong at Vercel, OpenCode, Railway and LiteLLM, and ten habits that limit the damage when an API key leaks.
October 22, 2026
Introducing Keyhouse: proxy keys for your apps and your AI agents
Keyhouse gives your hosts and AI agents proxy keys instead of real API keys, so a host breach leaks nothing you'd rotate at OpenAI or Stripe.
October 22, 2026
How Keyhouse will work: proxy keys, a broker and scoped agent access
The planned design behind Keyhouse: proxy keys, the broker, envelope encryption, short-lived tokens, Cloudflare Workers and time-limited agent grants.

Keyhouse isn't built yet. Join the waitlist to get it first.

One email when the hosted beta opens, and a short note now and then on how the build is going.

No tracking. Reply to any email to leave the list.