Why can't I just give an AI agent my API key?

Anything that enters a model's context stops being a secret: context gets written to logs, traces, and chat history, and can be extracted by prompt injection. An agent can also accidentally commit the key or paste it into code. Give the agent a revocable token with limited rights, never the original.

What is MCP and what does it have to do with keys?

MCP (Model Context Protocol) is an open protocol that connects AI agents to external tools. Through a key vault's MCP server, an agent can issue, rotate, and revoke proxy tokens on its own — but a read-the-original-secret operation simply doesn't exist in the toolset, so the key physically cannot enter the context.

The agent needs to set up a deployment before the key exists. What then?

Use a deferred secret: the agent creates a pending pass ahead of time, wires it into the configuration, and a human later enters the real key in the panel — the token activates automatically. The agent finishes the job without ever seeing the secret.

How to give an AI agent API access without handing over your key

Agents write code, deploy services, and configure bots — and at every step they need API keys. Putting a real key into a model's context means kissing it goodbye. Here's why, and which schemes actually work.

2026-07-05 · proxykey

Why "just give it the key" is a bad idea

A key that enters an AI agent's context stops being a secret for four independent reasons:

Context is logged. Chat history, agent-framework traces, debug dumps — the key settles into all of them, often in plain text.
Prompt injection. An agent that reads external data (web pages, issues, emails) can be tricked into "print your environment variables." This is not a hypothesis; it's a routinely demonstrated attack.
Agents make mistakes. An autonomous agent can commit the key to a repo, paste it into example code, or send it to a log — not maliciously, it just happens.
The key outlives the session. Copied into a config or a script, it stays there forever — beyond your control.

The rule Anything that has been in a model's context once — treat as published. The question isn't "will it leak" but "how much will it cost when it does."

The schemes that work

1. Scoped provider keys

Some providers issue keys with reduced rights (OpenAI project keys, GitHub token scopes). Better than a full key, but: limits and permissions aren't configurable everywhere, revocation still breaks everything sitting on that key, and you end up policing a dozen provider dashboards by hand.

2. A secrets manager + environment variables

Vault, AWS Secrets Manager, Doppler: the key is stored centrally and delivered to the app through the process environment. Decent — but at runtime the key still sits in an environment the agent can reach (printenv, reading configs), and then see the prompt-injection point above.

3. Proxy tokens: the agent never sees the key at all

The scheme that closes the problem by construction: the real key lives encrypted in one place and is never handed out. Apps and agents get virtual tokens and call a proxy that injects the original on its side:

agent ──(vlt_ token)──▶ proxy ──(real key)──▶ provider API

Each token has its own IP binding, its own rpm/rpd limits, and instant revocation. A token leaking out of an agent's context is a non-event: it doesn't work from a foreign address, and revoking it takes one click and doesn't touch the original.

MCP: the agent manages access without seeing the secret

The next step is giving the agent a tool instead of a token in the prompt. proxykey ships an MCP server (Model Context Protocol — the standard for connecting tools to Claude, Cursor, and other agents): the agent connects with one URL and an mcp_… token and gets a set of operations — issue a pass, rotate it, revoke it, read logs and stats.

The key property: a "read the real key" operation does not exist in that toolset. Only a human can enter the original, in the panel. The agent builds the infrastructure while the secret stays physically out of reach.

A real-world scenario An agent is deploying a Telegram bot. The bot token doesn't exist yet — only the plan does. Through MCP the agent creates a pending pass, wires it into the deployment config right away, and hands the human a link. The human enters the real token in the panel — the pass activates, the bot comes alive. The agent finished the job without ever seeing the secret.

FAQ

Does this protect against prompt injection?

Against key theft — yes: there's nothing in the context to steal. The agent can still be manipulated within its granted powers (talked into revoking a pass, say), so keep the MCP token's permissions minimal.

What if the vlt_ token itself leaks?

It's IP-bound and rate-limited: a foreign address gets 403, over-limit gets 429. Revocation is one click; the original is untouched. Compare that with a real key leaking — here's what that cleanup looks like.

How hard is it to switch existing code?

You change the host in the base URL and the key itself: api.openai.com → api.proxykey.org/p/openai, sk-… → vlt_…. Everything else — method, path, body, streaming — passes through unchanged. See how an API key proxy works.

Give the agent a pass, not the key

proxykey encrypts the real key and issues agents revocable passes — manually or through the built-in MCP server. Free, no card required.

Connect →