Cooperative clients use placeholders
Dummy valuesA client configured to use Airlock receives dummy values like __OPENAI_KEY__ instead of a real credential, so a real key is never placed in prompts, configuration, or ordinary logs.
Credential Airlock.
A self-hosted credential firewall for AI agents. Your agent works with placeholder keys; a deny-by-default local proxy swaps in the real ones, only for hosts you have allow-listed, and every request it handles is logged.
Built into REX, ClassEve’s coding agent, to keep your keys out of the AI’s reach.
Windows-first, Node / TypeScript. Free. Get it from GitHub:
The question everybody asks first
If the agent needs the key, what did you gain? It never gets the key.
The agent is handed a placeholder and its traffic is routed through the proxy. The proxy holds the real credential and swaps it in on the way out, for hosts you allow-listed. So the thing worth counting is how many places a real key exists at all.
6places on this machine hold a copy of your real key
- agent.config.jsonIts configuration file
"apiKey": "sk-live-7f3a91c0d84e"your real key - prompt → modelWhatever it pastes into context
Authorization: Bearer sk-live-7f3a91c0d84eyour real key - agent.logOrdinary logging
POST /v1/messages auth=sk-live-7f3a91c0d84eyour real key - crash dumpThe environment at the moment it died
OPENAI_API_KEY=sk-live-7f3a91c0d84eyour real key - shell historyHow it got set in the first place
export OPENAI_API_KEY=sk-live-7f3a91c0d84eyour real key - the vaultSealed by the OS, never sent to ClassEve
sk-live-7f3a91c0d84ewhere it belongs
Every line above is an accident — a value that ended up somewhere nobody meant to put it. That is the class of problem Airlock removes. A process running as your own OS account that means you harm is a different problem, handled by OS isolation; the ledger below draws the line.
What the airlock does with one request
The agent never holds the key. The chamber does, and only after the check.
The agent is configured with __OPENAI_KEY__. Airlock swaps in the real credential inside the chamber, for hosts you have allow-listed, and writes down every request either way.
Request
Audit log
- Nothing yet.
Day one, start to finish
Five steps, once. Then the agent never sees a real key again.
What you are configuring is the machine at the top of this page. The panel fills in as each step lands.
- 01Initialize the vaultInstall, run the setup, and add your real keys once. They are sealed to your machine and OS account on the spot.
- 02Hand your agent placeholdersWherever the agent's config wants an API key, give it the placeholder instead of the real value.
- 03Route traffic through the proxyPoint the agent's outbound HTTP at the local Airlock proxy, following the setup guide in the repo.
- 04Allow-list per keyDeclare which hosts each credential may reach. Everything not on the list is denied by default.
- 05Read the audit logEvery request — allowed or denied — is recorded once it reaches the proxy, so you can inspect the traffic Airlock handled.
The parts, and what each covers
The proxy is a policy layer
Deny by defaultRequests routed through the loopback proxy are checked before credential injection and logged. It is a policy layer, not an operating-system sandbox: a hard boundary against untrusted local code also needs a separate OS identity, file ACLs, and OS-enforced egress controls.
The vault seals at rest
DPAPI on WindowsDPAPI on Windows seals the vault against offline disk theft and other OS accounts; it is unsealed only for your own Windows user.
What the boundary actually is
Six ways a key leaks by accident. All six closed.
The left column is accidents — a real key ending up somewhere nobody meant to put it. The right column is an attacker who already holds your OS account. Airlock is a policy layer, and this is where that stops being a phrase and starts being a list.
- Your key sitting in the agent's configThe value there is a placeholder. There is nothing to copy.
- Your key pasted into a prompt or contextThe agent can only paste what it holds, and it holds the placeholder.
- Your key landing in ordinary logs and error tracesSame reason. What gets logged is the dummy value.
- A request to a host you never allow-listedChecked at the proxy before any credential is injected. Deny is the default.
- A request that leaves no traceEvery request that reaches the proxy is recorded, allowed or denied.
- The vault read off a stolen disk, or by another OS accountDPAPI seals it to this machine and this Windows account.
- Code already running as your own OS account reading the vaultIt has the same DPAPI access you do. Sealing at rest is not process isolation.
- That same code taking Airlock's admin tokenThe launcher runs same-user. File ACLs are a separate requirement.
- A process that opens its own socketAirlock configures cooperative HTTP clients. It is not an OS-enforced egress boundary.
- A hijacked agent calling a host you did allow-listAn allow-list is a list of hosts, not a list of intentions. That request gets signed.
The right column closes only when the broker and the agent run under separate restricted OS identities, the vault and admin channel are ACL-isolated, direct network bypass is contained, and DNS answers are pinned to the connections they authorize.
- ClassEve receives
- Nothing
- Fully self-hosted. Your keys do not reach us.
- Sealed by
- The OS-native root of trust
- DPAPI on Windows, on by default.
- Upgrade path
- Hardware TPM
- Documented, not required.
- What that covers
- Data at rest
- Process isolation is a separate requirement.
Common questions
What is Credential Airlock?
A self-hosted credential proxy for AI agents. Your agent is configured with a placeholder instead of a real key; a local deny-by-default proxy swaps in the real credential for hosts you have allow-listed, and the vault stays sealed by the OS at rest.
How does it stop an AI agent from leaking my API keys?
The agent never holds the key. Its configuration carries a placeholder, so the real value cannot reach a prompt, an ordinary log, or a crash dump — there is nothing there to copy. The proxy holds the credential and injects it on the way out, only for hosts on that key's allow-list.
Which platforms does it run on?
Windows. Secrets are sealed at rest with the Windows Data Protection API (DPAPI). It is self-hosted, so your keys never reach ClassEve.
Does Credential Airlock make a hijacked agent safe?
It caps what a hijacked agent can steal: the agent never holds a real key, and hosts off the allow-list get nothing. For hostile code running under your own account, add separate OS identities and egress controls on top.
How is it different from a secrets manager or vault?
A vault stores secrets and hands them to your application, so the application ends up holding one. Airlock keeps the secret inside a local proxy and never hands it over — the application only ever holds a placeholder.
Is Credential Airlock free?
Yes. It is self-hosted, and ClassEve never receives your keys. Get it at github.com/Classevelabs/credential-airlock.