API key proxy alternatives, compared

"Don't let the app see the real key" is one goal with four quite different solutions behind it. They are not competing implementations of the same idea — they solve different problems, and picking the wrong category costs more than picking the wrong vendor. Here is what each one actually does, written the same way as our threat model: including the cases where the answer is not us.

The four approaches

1. A secrets manager — HashiCorp Vault, Doppler, AWS Secrets Manager, .env

Stores the secret and gives it back to you when asked. That last part is the whole point and the whole problem: from the moment it is handed over, the key lives in process memory, in environment variables, in crash dumps, in whatever your logger decides to serialise, and — if an agent asked for it — in a model's context. A secrets manager protects the key at rest and in transit to you. It cannot protect it after delivery, because delivery is the feature.

Use it when the consumer is your own trusted backend, and you need one place for database passwords, certificates and signing keys as well. It is infrastructure; the categories below are not replacements for it.

2. An LLM gateway with virtual keys — LiteLLM, Portkey

Sits in front of model providers and hands out its own keys instead of the provider's. LiteLLM issues virtual keys with budgets, model restrictions, rate limits and per-key spend tracking; Portkey adds a hosted control plane, a very wide model catalogue and observability. The real provider keys stay inside the gateway. If your problem is LLM traffic, this category is more capable than we are — it understands tokens, cost, model routing, caching and fallbacks, and we deliberately do none of that.

Use it when your traffic is mostly model calls and you want spend governance, routing across providers, or LLM-specific observability.

The limit: it speaks LLM. A gateway built around chat completions is not where you put a Stripe secret key, a Telegram bot token or a GitHub PAT.

3. A local credential proxy with TLS interception — Infisical Agent Vault

Runs on your machine or inside your infrastructure and intercepts the agent's HTTPS traffic: the agent connects through it via HTTPS_PROXY, the proxy terminates TLS using a locally trusted certificate authority, strips whatever placeholder credential the agent attached, injects the real one and opens a properly verified connection upstream. Works with any API, and — the genuinely elegant part — requires no change to the agent's code at all, because the agent still believes it is calling api.stripe.com directly.

Use it when you cannot or will not modify the caller, when the credentials must never leave your own hardware, or when you are wrapping an agent whose HTTP calls you do not control.

The cost: a trusted CA has to be installed in the agent's trust store, and you run and maintain the thing. Intercepting TLS is a powerful capability to hand to a component; that is a deliberate trade, not a flaw, but it is a real one.

4. A hosted credential proxy — proxykey

You store the real key once; it is encrypted with AES-256-GCM and never leaves the server. Callers get a pass (vlt_…) and point at an explicit endpoint: change the host from https://api.openai.com/v1/… to https://api.proxykey.org/p/openai/v1/… and keep everything else. Each pass carries its own IP binding, rpm/rpd limits, expiry and request log, and is revocable on its own without touching the original key. Any API, not just models — 25+ providers including Stripe, Telegram, GitHub, Notion, Airtable, plus generic modes for a custom HTTP API with any auth scheme. There is an MCP server so an agent can issue and revoke its own passes while having no tool that reads a secret.

Use it when the caller is something you don't fully trust — a mobile app, a browser, a contractor's script, an AI agent — the API is not necessarily an LLM, and you would rather not run infrastructure for it.

The cost: you must change the URL in your code, which category 3 does not require. And it is hosted, which means the operator is inside your trust boundary; we state that plainly and in more detail on the threat model page rather than pretending otherwise.

Side by side

On a narrow screen the table scrolls sideways. Compiled from each project's public documentation, linked above, in August 2026. These products move quickly — if something here has gone out of date, tell us and we will correct it.

Choosing in one line

• Consumer is your own backend → secrets manager. Nothing else is needed.
• Traffic is mostly LLM calls and you need budgets, routing or model observability → LLM gateway.
• You cannot modify the caller, or credentials must stay on your own hardware → local proxy with TLS interception.
• The caller is untrusted, the APIs are varied, and you don't want to run anything → a hosted credential proxy. That is us.

When proxykey is the wrong choice

Three cases, stated plainly, because finding out later is worse:

• You cannot touch the calling code. We need the host swapped. If that is impossible, category 3 is built precisely for you.
• Policy forbids a third party in the credential path. A hosted proxy decrypts the key in memory to sign each request. If that is unacceptable — and for some organisations it correctly is — self-host something instead.
• You need LLM spend governance. Per-model budgets, token accounting, semantic caching, fallback chains: we do not do these and are not planning to. LiteLLM and Portkey do them well.