Credential proxy
Your agents make API calls.
They should never hold the keys.
Clavitor Proxy sits between your AI agents and the APIs they call. Credentials are injected at the network layer — the agent never sees, stores, or logs the real secret. One binary. One env var. Zero code changes.
The problem you already have
Secrets in env vars
Your agents read OPENAI_API_KEY from the environment. That key is visible in /proc, in crash dumps, in CI logs, in every tool the agent invokes. One leaked log line and the key is public.
Secrets in agent memory
Even if the agent fetches the key at runtime, it holds it in memory for the duration of the process. A compromised skill, a prompt injection, a debug dump — the key is there for the taking.
No audit of what was used
When an API key is shared as a string, there is no record of which agent used it, when, or for what. If the key leaks, you rotate it and hope. There is no forensic trail.
The problems we hope you don't have
API keys in source code
Hardcoded in a config file, committed to git, cloned by every developer and CI runner on the team. One public fork and it's on GitHub's secret scanning dashboard — or worse, it isn't.
Credentials in Slack
"Can you send me the Stripe key?" Pasted in a DM, searchable forever, exported in every compliance archive. Slack is not a vault. Neither is email, Google Docs, or a sticky note on a monitor.
.env files on every laptop
Twelve developers, twelve copies of production credentials in plaintext files that never get rotated. One stolen laptop, one ~/.bash_history leak, one overly helpful backup tool — and you're rotating every key in the company at 2 AM.
Take credentials off the agent entirely.
The proxy sits between the agent and the API. The agent writes a reference — clavitor://OpenAI/key — where the secret should go. The proxy resolves it locally, injects the real credential into the HTTPS request, and forwards it. The agent's logs show the placeholder. The API receives the key. Nothing in between stores it.
No env vars. No secrets in memory. No credentials on the command line. The agent doesn't know the key, can't leak the key, can't be tricked into revealing the key.
$ export HTTPS_PROXY=http://127.0.0.1:1983
$ curl -H "Authorization: Bearer clavitor://OpenAI/key" \
https://api.openai.com/v1/chat/completions
# The proxy resolved the placeholder. The agent never saw sk-proj-abc123.
# Neither did the logs, the crash dump, or the conversation history.Works with any agent that makes HTTPS calls: Claude Code, Codex, OpenClaw, CrewAI, LangChain, custom scripts. Set one env var and the agent's API calls flow through the proxy. No SDK, no plugin, no code changes.
What happens under the hood
Decrypts locally, per request
The proxy fetches the encrypted credential from the vault and decrypts it on-device. The plaintext exists in process memory for one HTTP request, then it's gone. Nothing is cached. Nothing is written to disk. Every request decrypts fresh.
Maps fields to headers
Bearer tokens, API keys, Basic auth — the proxy maps vault field labels to the right HTTP headers automatically. Or the agent picks the exact field with a clavitor:// reference. Either way, the credential lands in the right place without the agent ever seeing it.
Scopes, rate limits, audit
The vault enforces scope boundaries and rate limits. An agent that accesses too many distinct credentials is automatically locked. Every access is logged. Include an agent ID in the placeholder — clavitor://agentid@Entry/field — for per-agent audit trails and rate limits through a shared proxy.
Deployment
One binary. Sidecar to the agent. No network infrastructure changes.
Single-agent host
Download the binary, run clavitor-proxy init with the enrollment token, set HTTPS_PROXY on the agent. Done. The proxy binds to 127.0.0.1:1983 and only serves the local machine.
Multi-agent host
Each agent gets its own copy of the binary with its own sidecar config file. Each copy has its own scope, its own rate limits, its own audit trail. Agent A can't see Agent B's credentials. Isolation by design.
Every credential proxy that runs in the cloud — yours or someone else's — is a target. Breach the proxy, get every customer's credentials. That's not a theoretical risk. It's the business model of every credential-proxy-as-a-service.
Clavitor's proxy runs on your machine. Binds to localhost. Decrypts locally. The credential exists in process memory for the duration of one request. There is no cloud service holding your plaintext keys. There is no API endpoint serving your secrets. There is nothing to breach.
Your agents are already making API calls.\Start protecting them.
Your vault, your scopes, your audit trail. The proxy adds a network-layer enforcement point with zero code changes to the agent.