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 is audited.
Built natively into REX, ClassEve’s desktop AI, as a routed-credential policy layer. It is a credential boundary, not an operating-system sandbox.
Windows-first, Node / TypeScript, Apache-2.0. Open source — clone it or browse the repo:
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, and the ledger below says exactly how much of it Airlock does not solve.
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 their limits
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 things it stops. Four it does not.
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 today. File ACLs would be needed, and are not there yet.
- 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 authorise.
- 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, and it is not met yet.
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. It is built for cooperative agents; it is not an OS-level sandbox.
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 today. Secrets are sealed with DPAPI, the Windows Data Protection API, with a documented hardware-TPM upgrade path. It is self-hosted, so your keys never reach ClassEve.
Does Credential Airlock make a hijacked agent safe?
No. The current launcher runs the agent as your own OS user, so a malicious or fully compromised child process can read Airlock's files or take its admin token, and a process that opens its own socket goes around the proxy entirely. Airlock reduces accidental exposure; it does not contain hostile code.
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 and open source?
Yes. Apache-2.0, self-hosted, and ClassEve does not receive your keys. The source is at github.com/Classevelabs/credential-airlock.