Introducing Keyhouse: proxy keys for your apps and your AI agents

Most of my projects start the same way. I create an app, a coding agent helps me write it, and within the first hour I’ve pasted an OpenAI key into the host’s environment variables. Then a Stripe key. Then Resend, Apify and a database URL. Multiply that by every app and every environment, and I end up with dozens of real keys spread across hosting dashboards, .env files, CI secrets and whatever my agent happened to read that day.

That holds up until a host has a bad day. On October 21, 2026, Railway asked all of its users to rotate every environment variable they store there, after an intruder may have read encrypted variables and decrypted some of them (Railway’s disclosure). In April, Vercel told affected customers to rotate their non-sensitive environment variables after an attacker decrypted them (Vercel’s bulletin). Each time, the cleanup is the same. You open thirty provider dashboards one at a time, create new keys, paste them back, redeploy, and hope you didn’t miss one.

I’m building Keyhouse so the next cleanup takes minutes instead of a weekend.

What is Keyhouse?

Keyhouse is an open-source credential and subscription center for developers and their AI agents. The core idea is that your hosts and your agents should only hold keys that are useless anywhere else.

Keyhouse is not built yet. It’s in planning, with a waitlist. This post describes what I’m building and why. One small piece is already available, the Exposure Check, covered further down.

How proxy keys work

You store each real provider key once, in Keyhouse. Every app, environment and agent gets its own proxy key instead. A proxy key looks like kh_live_.... It only works through the Keyhouse broker, only for one provider, and, once you turn on caller binding, only from the app it was issued to.

For most apps the change is two environment variables:

OPENAI_BASE_URL=https://openai.<your-keyhouse-gateway>/v1
OPENAI_API_KEY=kh_live_...

The official OpenAI SDK reads both. Your app sends its request to the broker. The broker checks the proxy key, swaps in the real key and forwards the request to OpenAI. Your code stays the same. Anthropic, Resend and many other SDKs accept a base URL the same way.

The closest comparison I’ve found is a hotel key card. When a guest loses a card, the front desk reprograms the cards and nobody changes the locks. In Keyhouse, your host holds the cards. The locks are OpenAI, Stripe and every other provider you use.

What changes when a host is breached

Say a host you use announces that someone read its customers’ environment variables. With Keyhouse, what that person got is a set of proxy keys.

• You rotate every proxy key placed on that host in one operation, from the dashboard or by asking your agent. Keyhouse writes the new keys back to the host and triggers the redeploys.
• Nothing changes at OpenAI or Stripe, because the real keys never left Keyhouse.
• You get a list of every use of the old keys in the last 48 hours, so you can see what was actually touched.

Proxy keys aren’t magic. A stolen proxy key without caller binding still works through the broker until you rotate it. What you gain is one place to stop it, spend caps on each key, a usage log, and an incident checklist with no provider dashboards in it.

Your agents never hold a real key

Coding agents read .env files. They print variables while debugging and copy keys into config files. I’ve stopped pretending mine don’t.

An agent connected to Keyhouse sees only the catalogue by default: provider names, app names, key labels and where each key is placed. To do anything more, it has to ask. A request reads like “use Apify for lead-scraper for 15 minutes, to set up the scraper”, and you approve it, narrow it or reject it on Keyhouse’s own approval page. A grant lasts 24 hours at most. If the agent needs to call a provider itself while it builds and tests, it gets a session proxy key that stops working when the grant ends.

An agent can’t approve, widen or extend its own access. Revoking a key or ending its own grant never needs approval, because reducing access shouldn’t wait during an incident.

What comes after keys

Proxy keys, usage tracking and one-click rotation come first. Later phases in the plan cover rotating the real keys at providers through their own APIs, a virtual card per vendor so you can see and freeze subscriptions, and agent access to website logins through 1Password instead of yet another password store. Those later phases will change as I learn what people actually need.

Open source and self-hostable

Keyhouse will be open source, and you’ll be able to run all of it yourself from one Docker Compose file or use a hosted version. The current plan is AGPL-3.0 for the server, dashboard and proxy, and Apache-2.0 for the CLI and the provider catalogue so other projects can embed them. When a product holds every key you own, being able to read every line of it matters.

What Keyhouse can see

A broker that holds every real key is a bigger target than any single host. I’d rather say that at the start than in a footnote.

The proxy has to decrypt your real keys to send them, so Keyhouse is not end-to-end encrypted. Whoever operates a proxy could, by changing its code, read keys passing through it. The design narrows that risk. Only the proxy can decrypt. The dashboard and the database can’t. Nothing logs request bodies. And you can run the proxy yourself if you’d rather not trust mine. The architecture post has the details.

Available today: Keyhouse Exposure Check

Keyhouse Exposure Check is a free, MIT-licensed CLI that lists the credentials in your Railway projects or in a local .env file, grouped by provider, with a rotation checklist for each one.

npx keyhouse-check railway
npx keyhouse-check env .env

It runs on your machine. Secret values stay in memory and are never uploaded, logged or written to the report. The CLI never contacts Keyhouse or the credential providers, and env mode makes no network calls at all. Railway mode sends only read queries to Railway’s API, using a token you create for the scan. Railway invalidated all older API tokens on October 22, so you’ll need a new one, and you should revoke it when you’re done.

It’s an inventory. It doesn’t prove a key was stolen or that it still works, and it can miss secrets in unusual formats. The source is on GitHub and the package is keyhouse-check on npm.

Join the waitlist

If you ship apps with AI agents and keep your keys in host environment variables, I’d like to hear how you handle it today. Join the waitlist and I’ll write here as the broker comes together, including the parts that don’t work yet.

Quentin