Coming soon · Private pre-release
Give the agent a stand-in key. Keep the real one encrypted.
Slifer Key Locker is a local-first API key broker for developers and agentic workflows.
Your provider key goes into an encrypted vault on your machine. Everything that makes API calls gets a Locker token instead: a credential that looks like a key, is used like a key, and is worth nothing anywhere else. The broker attaches the real key only after the request passes policy, and only for that one request.
It runs on your machine and listens only on loopback. Today the brokered path covers OpenAI.
Not for production secrets yet. The application is still in development. There is no public installable release.
How it works
One request. Four checks before the key exists in cleartext.
Slifer changes what the less-trusted side of your machine holds. Your app or agent holds a Locker token that only works against a broker on 127.0.0.1. The broker holds the real key, decrypts it after the request passes policy, and attaches it on the way out.
-
Put the provider key in the local vault.
The upstream credential is stored as encrypted vault data instead of living in a
.envfile, a shell profile, or anything an agent can read. Unlocking it takes two factors you hold: a passphrase and a generated Vault Secret Key that is not stored in the vault file. -
Issue a Locker token and pin it.
The client gets
skl_tok_v1_…instead of the provider key. The token is pinned to one provider, a named secret, a list of HTTP methods, an explicit list of path prefixes, an egress host, a source that must be loopback, a rate ceiling, a concurrency cap, and an expiry. Everything is deny-by-default: an empty list means none, not all. -
Send the request to the broker, not the provider.
The broker checks the peer is on loopback, refuses a browser origin, strips every header that is not on a short allow list, validates the token, and evaluates the policy. Only after all of that does it decrypt the upstream key. A request that fails an earlier check never causes a decryption.
-
Let the broker make the upstream call.
The broker opens its own TLS connection to the provider and attaches the real credential there. The client's Locker token is never forwarded, and the client's own auth headers are never passed through.
Changed your mind? A Locker token can be revoked or rotated through the daemon's control API, and future validation fails closed. That is not the same as rotating the provider key upstream, which Slifer does not do for you.
What a token can be pinned to
- Provider
- One upstream provider, matched exactly.
- Secret alias
- The named vault entry this token may cause to be decrypted.
- HTTP methods
- An explicit set. Anything unlisted is denied.
- Paths
- Exact paths or prefixes. The shipped agent policy allows five and nothing else.
- Headers
- An allow list and a deny list, applied to what the client may send through.
- Source address
- Source CIDR ranges, or loopback-only.
- Time window
- A wall-clock window outside which the token does not validate.
- Expiry
- An absolute timestamp. Tokens an agent mints for itself are capped at five minutes.
- Egress
- Allowed hosts, schemes, and ports for the outbound call. Non-HTTPS is refused.
- Rate
- A per-token limit and a per-provider limit, both over a rolling window.
- Concurrency
- A ceiling on requests in flight at once for that token.
A denial comes back to the client as a flat policy_denied. Locally you get the specific rule that stopped it, out of nineteen stable outcome codes, so you can tell a rate limit from a path mismatch.
Trust boundary
The key exists. Just not where the agent can read it.
Slifer does not promise the upstream credential never exists in cleartext. It narrows where it exists, for how long, and what has to be true first. Everything on the left is assumed to be one bad prompt away from leaking. Everything on the right is the process you already trust with your unlocked vault.
App or agent
- Holds a Locker token, not a provider key
- Talks to 127.0.0.1 over plain HTTP, which never leaves the machine
- Needs a session secret from a private directory as well as the token
- Can spend only the scope it was granted, and only until it expires
Trusted local process
- Validates the token and evaluates policy before decrypting anything
- Handles the provider key transiently, for one approved request
- Opens its own TLS connection and attaches the key there
- Forwards neither the Locker token nor the client's auth headers
Current status
Foundation work, shown plainly.
Slifer is being built in private. The security model is concrete; distribution and external hardening are not finished.
- Exists now
- Encrypted vault with two-factor unlock, the
lockerbinary, a brokering daemon with a deny-by-default policy kernel, an MCP server for coding agents, and build gates that plant a fake credential and fail on any leak. - Not shipped
- No public release artifact and no external security review. The brokered path covers one provider. Budgets are request rates, not spend, and proxied requests are not written to the persisted activity log.
- Target boundary
- macOS and Linux first, with loopback-only local mode by default and no hosted control plane dependency.
- Residual risk
- Same-user malware can still act while the vault is unlocked, and a compromised client can spend its granted Locker-token scope.
FAQ
The useful objections.
The model
What does Slifer Key Locker do?
Slifer is a local-first API key broker. It stores upstream provider keys in an encrypted vault on your machine, hands out scoped Locker tokens to the apps and agents that make API calls, and lets a trusted local process attach the real credential only after a request passes policy. Today the brokered path covers OpenAI.
Why not keep provider keys in an .env file?
An environment variable is a bearer credential with no scope, no expiry, and no revocation. Whatever process holds it can call any endpoint, at any rate, forever, from anywhere, and you usually find out from your invoice. A Locker token is pinned to one provider, one secret, a fixed list of methods and path prefixes, an egress host, a loopback-only source, a rate ceiling, and an expiry, and it can be revoked without touching the provider.
What exactly can I pin a token to?
Provider, secret alias, HTTP method, exact path or prefix, allowed and denied headers, source CIDR or loopback-only, a wall-clock time window, an expiry, egress host and scheme and port, per-token and per-provider rate limits, and a concurrency cap. Every one of those is deny-by-default, so an empty list means nothing is allowed rather than everything.
Does the upstream key never exist outside the vault?
No, and any tool that tells you otherwise is overselling. The trusted local process decrypts the upstream key when an approved request needs it, and holds it for that request. What the boundary does is keep it out of client apps, source control, routine logs, and agent context.
Can an AI agent read one of my secrets?
No tool on the agent interface returns a secret value. Listing shows aliases and providers, token creation returns a fingerprint and an expiry rather than a usable credential, and the break-glass request is refused twice before it could reach the vault. An agent gets a secret into a program by running that program through Slifer, never by reading the value itself.
What happens if a Locker token leaks?
Less than you would fear. The token only validates against a broker listening on loopback, so it is not usable from another machine, and the broker also requires a session secret from a directory only your user can read. Revoke it through the control interface and future validation fails closed. Rotating the upstream provider key is a separate decision and is still yours to make.
The cryptography
Why Argon2id, and why those parameters?
The vault stretches your passphrase with Argon2id at 64 MiB of memory, three passes, and four lanes, which is exactly the second recommended option in RFC 9106. Memory hardness is what makes GPU-based guessing expensive, so the memory floor cannot be traded away against iteration count: configurations below it are refused rather than accepted with a warning. This is heavier than the OWASP Password Storage minimum, which goes as low as 7 MiB.
Why XChaCha20-Poly1305 instead of AES-GCM?
The extended-nonce variant takes a 192-bit nonce, which is large enough that generating one at random is safe without tracking a counter across restarts. AES-GCM's 96-bit nonce is not, and nonce reuse there is catastrophic rather than merely bad. Choosing the construction that removes an entire class of implementation mistake is worth more than matching the more familiar name. Note that this variant is not the one specified in RFC 8439; it comes from an expired IRTF draft standardized in practice by libsodium.
What is the Vault Secret Key, and what if I lose it?
It is a 256-bit key generated when you create the vault, written to an Emergency Kit file, and deliberately not stored inside the vault itself. Unlocking needs it plus your passphrase, so a stolen vault file cannot be attacked by guessing the passphrase alone. If you lose both the kit and your record of it, the vault cannot be recovered. That is the design working, not failing.
Scope and status
Is Slifer ready for production secrets?
No. Slifer is private pre-release foundation work. There is no installable public release, everything builds from source, and it should not be holding a secret you would mind losing.
Why does the brokered path only cover OpenAI?
The adapter layer supports other authentication shapes, but exactly one adapter is registered in the daemon today and any other provider segment is rejected outright. Shipping one provider that is genuinely enforced is more useful than a provider list where most entries are untested paths.
What is not protected?
An unlocked vault on a compromised machine is an unlocked vault; Slifer defends the credential at rest and on the way to the provider, not against someone who already has your user session. Running a program with a secret in its environment leaves that value in ordinary process memory that Slifer cannot zeroize. The locked vault file still reveals aliases, provider labels, and timestamps. Proxied requests are not written to the persisted activity log, and the code has not had an external audit.
Does Slifer rotate provider keys automatically?
No. Locker tokens can be revoked or rotated, but upstream provider-key rotation is separate and is not automatic.
What does early access cost?
Nothing at this stage. Slifer is a private pre-release with no accounts, payments, subscription, download, or public release. Emailing does not create a purchase or guarantee access.
Where does my data go?
The site sets no cookies, runs no analytics, and stores no visitor data. If you use the early-access mail link, your message goes from your mail app to a human-managed inbox; nothing is submitted through this page.
How do I ask for an early-access email to be deleted?
Email tailorcorp@icloud.com with Slifer privacy request in the subject and ask for deletion. The message will be removed from the working inbox along with any manually kept early-access notes; reply stop to end updates.
How do I get support?
Email tailorcorp@icloud.com. Slifer is a private pre-release, so support is handled by a human on a best-effort basis rather than through an account or ticket portal.
Private early access
Help shape the boundary before the release.
If you run coding agents against provider APIs, send a note about the workflow you want to protect. Build updates can stay in the same thread.
Pre-release: do not use Slifer for production secrets yet.