ProxyKey has launched an MCP server that lets AI agents such as Claude Code and Cursor control access to third-party APIs without ever receiving the actual credential. The project builds on the earlier observation that any credential visible inside an agent’s context must be treated as compromised because model outputs are logged, traced, and potentially exfiltrated through prompt injection.
The architecture separates three roles. The real provider key (secret) is submitted once through a web panel and stored encrypted with AES-256-GCM envelope encryption. A virtual token called a pass (prefixed vlt_) is bound to that secret and carries its own IP restrictions, rate limits, TTL, and request log. The proxy itself accepts the pass, decrypts the secret only for the duration of a single outbound request, and forwards the call transparently.
API calls change only the host and authorization header; path, body, and streaming behavior remain identical. Example:
- Original: curl https://api.openai.com/v1/chat/completions -H "Authorization: Bearer sk-…"
- Proxied: curl https://api.proxykey.org/p/openai/v1/chat/completions -H "Authorization: Bearer vlt_openai_…"
Telegram bots keep their familiar URL format: /p/telegram-bot/<pass>/getMe.
Agents connect to the MCP server over Streamable HTTP using a separate mcp_ token. Thirteen tools are exposed, none of which accept or return secret values. The catalog tools list providers and stored secrets (metadata only). Pass-management tools create, rotate, update, revoke, and monitor passes. Observability tools return request logs and statistics without exposing authorization headers or keys.
A key use case is the pending-secret flow. An agent can call create_pending_pass to obtain a pass immediately, embed it in configuration, and later hand a setup link to a human. Once the real token is entered through the web panel, the pass activates automatically without any further agent action. Throughout the entire lifecycle the secret never enters the model’s context.
The hosted proxy cannot be zero-knowledge because it must decrypt the secret in memory to forward the request. ProxyKey publishes its crypto module (proxykey-crypto) with tests and design notes covering nonce handling and key-wrapping choices. The service is positioned for environments where agents autonomously deploy services and bots; it is not intended for single, fully controlled keys or for workloads with strict sub-millisecond latency requirements.
