Infisical Agent Vault: How a Credential Proxy Keeps API Keys Out of AI Agents

Traditional secrets management returns credentials to the applications and services that use them. Infisical Agent Vault takes a different route. The agent never holds the real credential.

This guide covers how that credential proxy pattern works, where it reduces risk and where it doesn't. It's organized around a three-layer model we call Placeholder / Proxy / Perimeter:

• Placeholder: the agent holds only a stand-in value, never the real key.
• Proxy: a separate broker holds the real credential, applies policy and injects it into approved requests.
• Perimeter: the network forces every outbound call through that broker.

Why handing secrets to AI agents breaks the old model

Classic secrets management rests on a simple contract. An application you wrote and reviewed authenticates to a secrets manager, gets a credential back and uses it.

Agents break that contract. The Agent Vault repository says so directly: traditional secrets management returns credentials to applications and services, and this breaks down with AI agents, which can be tricked via prompt injection into leaking secrets. Infisical CTO Tony Dang made the same argument at launch: secrets management was built for a world where applications fetched credentials and used them, and that assumption no longer holds for AI agents.

The issue isn't malice. Infisical's launch post concedes that even with sufficient guardrails in place, there is no way to guarantee the agent won't be manipulated into leaking its secrets.

Model-level defenses don't close the gap. The OWASP prompt injection cheat sheet cites Hughes et al. (2024), who reported 89% attack success on GPT-4o and 78% on Claude 3.5 Sonnet with up to 10,000 augmented prompts per request. That study measured jailbreak success with Best-of-N style augmented prompts, not how often indirect prompt injection exfiltrates secrets. We read it as a reason not to treat model refusals as a security boundary.

Instead of trusting the agent with a key, you keep the key out of its context entirely. That's the Placeholder layer. The other two exist to keep it intact.

How the Agent Vault credential proxy works

Infisical describes Agent Vault as a TLS-intercepting, credential-injecting forward proxy built for agent workloads. The flow runs like this:

1. The agent gets a placeholder value or session token instead of the real API key.
2. Its HTTP traffic goes through the proxy, usually because the HTTPS_PROXY environment variable is set.
3. The proxy intercepts the TLS connection, checks the destination host against its configured services and inserts the real credential into the outbound request.
4. The request goes upstream with the real credential, and the response comes back to the agent.

In the open-source binary, the server starts an HTTP management API on port 14321 and a transparent HTTP/HTTPS proxy on port 14322.

The upstream API sees a normal authenticated request. The agent, and any inference provider logging its context, sees only the placeholder, which is why the pattern also addresses the provider-log risk discussed in the protection section below.

Certificate trust is a deployment step

We suggest treating certificate trust as an explicit deployment step: with any TLS-intercepting proxy, plan for each agent runtime to trust the certificate authority that signs the proxy's certificates. Install that CA certificate deliberately in each agent image, and follow your edition's documentation for how it's issued. Never turn off certificate verification to make connections work.

Two rules decide whether the guarantee holds

The first is location, which underpins the Proxy layer. According to the repository, Agent Vault is meant to run on a separate machine from your AI agents, so the agents cannot directly access the credentials inside it. If the agent can read the vault's storage, the pattern buys you very little.

The second is enforcement, the Perimeter layer. Setting HTTPS_PROXY alone does not guarantee traffic flows through the proxy, Infisical notes, because the agent can unset it. The variable only guides compliant clients. A full deployment locks the network down so all outbound traffic is forced through Agent Vault.

The control surface: allowlists, deny mode, sessions and audit

A proxy that injects credentials is also a natural place to put policy.

Host matching and deny mode. By default the open-source proxy forwards requests that match no configured service as plain proxy traffic. Switching a vault to strict deny mode (unmatched_host_policy=deny) rejects those requests with HTTP 403.

We'd make deny mode the baseline for every vault. With pass-through on, an agent steered toward an attacker-controlled host can still reach it, just without a brokered credential. Deny mode turns the proxy into an egress allowlist as well as a credential injector. If your edition supports path or HTTP method rules, check the documentation for what granularity is actually enforced.

Time-bound sessions. In the commercial Agent Vault, every agent session expires on a schedule you set, and running agents lose access within 60 seconds of the session ending. Short sessions limit how long a hijacked run can keep using brokered access.

Shared proxies. When several agents share one proxy, they send their session token to it over plain HTTP, a point Infisical's documentation flags as a warning. Keep that setup on a private network that agents and proxy share, such as your own servers, a Kubernetes cluster or self-hosted CI runners.

Audit. All brokered traffic passes one chokepoint, which gives security teams a single place to review what agents call. Before relying on it as evidence, find out what your edition records and how long it keeps that data, then confirm you can export it. If you already trace agent runs with OpenTelemetry GenAI tracing, correlate proxy records with those traces instead of treating either one as complete.

What the pattern protects against, and what it doesn't

Per Infisical's documentation, if a prompt injection tricks the agent into revealing a credential, there is nothing there to reveal. That's a real step up from secrets sitting in environment variables the agent can print.

The Hacker News discussion of the launch offered another angle. One commenter argued that the pattern does not solve hostile agents but rather hostile or compromised inference providers, because you do not want secrets in the logs of an AI provider. Either way, keys that never enter prompts, completions or tool outputs never land in third-party logs, whether or not anyone is attacking you.

Misuse of permitted access. If an agent may call a delete endpoint through the proxy, a manipulated agent can still call it, and the proxy attaches the real credential as usual. Brokering keeps the key secret. It doesn't make the agent's actions safe, and that matters most for event-triggered MCP tools that run without human review.

Credentials in responses. A critic in the same Hacker News thread pointed out that if the credential is an OAuth2 token and the service has a token refresh endpoint, the response would carry a new token straight to the agent. Token-minting, key-creation and secret-read APIs carry the same risk. Brokering protects the request, so you still have to review what comes back.

MCP token handling. The MCP security best practices state that MCP servers must not accept any tokens that were not explicitly issued for the MCP server. A credential proxy doesn't replace correct audience checks inside your MCP servers.

Open source vs commercial Agent Vault: what changed and why it matters

Agent Vault comes from Infisical, which says it processes billions of secrets per month for teams, CI/CD pipelines and servers.

Codeline's independent review at launch noted roughly 800 stars, a Preview label and an API explicitly subject to change. It also described the internals: the master password wraps a random data encryption key through Argon2id with default parameters of 3 iterations, 64 MiB memory and 4 threads. By default the binary keeps all state in a local SQLite database that needs no setup, and PostgreSQL is the option for production.

Within a few months, by Infisical's later count, Agent Vault had crossed 2,000 GitHub stars, with tens of thousands of installations and millions of agent runs. Those are vendor figures and haven't been independently verified.

A note on naming: Infisical calls the paid edition the commercial Agent Vault when describing sessions, and calls its broker component Agent Proxy when describing the redesign. We use both terms the same way here.

The bigger change is architectural. Looking back on the first release, Infisical explained that it had bundled two distinct concepts into one: the secrets store and the secrets broker. In the commercial Agent Vault, Agent Proxy separates them and ships with 30+ presets for common services, including LLM providers such as Anthropic and OpenAI and services like GitHub, Slack and Datadog. As for the open-source repository, the company says it stays up and you can run it, but it is not actively maintained and was never built for a team.

Our sources also describe unmatched-host handling only for the open-source repo and session expiry only for the commercial edition. Check current documentation for the other edition rather than assuming parity.

We suggest treating the open-source repository as a tool for learning and prototyping. For production, we'd look at the commercial edition or an in-house fork you're prepared to maintain. Weigh maintenance burden the same way you would for any production agent component (see our runtime selection checklist for durable AI agents).

Playbook and pre-launch checklist for MCP, CLI and SDK agents

These steps follow the three layers and apply to either edition.

Placeholder layer

1. Inventory credentials. For each agent, list every credential, the host it's used against and the narrowest endpoints and HTTP methods it needs.
2. Swap in placeholders. Replace real keys in agent environment variables and config files with placeholder values or session tokens.

Proxy layer

1. Separate the proxy. Run it on a separate machine or across a network boundary from the agents. The credential store never sits in the agent's runtime.
2. Deny by default. Turn on deny mode for unmatched hosts and add allowlist entries per agent, not per team.
3. Review what comes back. Flag allowlisted endpoints whose responses can return a credential or secret, such as OAuth refresh, token-minting, key-creation and secret-read APIs. Keep them away from the agent unless you can justify the exposure.
4. Scope MCP tokens. Each MCP server's upstream API keys live in the broker, not in its config. Reject client tokens that weren't explicitly issued for the MCP server, and never forward them downstream.

Perimeter layer

1. Force egress. Use firewall rules, Kubernetes network policies or CI runner rules so the proxy is the agent's only route out. Set HTTPS_PROXY afterwards as guidance for compliant clients.
2. Install CA trust. Add the proxy's CA certificate to each agent runtime's trust store, with verification left on.
3. Verify HTTP clients. Not every runtime honours proxy variables. Infisical's documentation notes that Node.js built-in fetch does not read HTTPS_PROXY by default, so you need --use-env-proxy or NODE_USE_ENV_PROXY=1 on Node 24 or later. We suggest confirming flag support for the exact runtime version you deploy before relying on it.

Prove it

1. Test revocation and injection. Set short session lifetimes, end a session mid-run and confirm access stops. Then run a canary prompt-injection test asking the agent to print its keys, and check that only placeholders come out.

CLI agents such as Claude Code

Infisical lists Claude Code among the agents running through Agent Vault. For CLI agents, the dependable setup is a container or VM whose network rules allow outbound connections only to the proxy, with placeholders wherever the agent expects API keys. A CLI agent can run shell commands, so assume it can unset environment variables and let the network enforce the route.

Custom SDK agents

Audit every HTTP client in the dependency tree. A library that ignores proxy settings should fail closed at the network layer, not quietly connect direct.

Read the allowlist as an attacker would

Once keys are out of the agent's context, the allowlist becomes the main thing a successful injection can exploit, so review it from that angle before rollout. For each entry, ask what the worst sequence of allowed calls could do if someone else were choosing them. Delete, transfer, key-creation and token-refresh endpoints should need human approval or stay off the allowlist entirely. The upstream credential behind each entry should carry the narrowest scopes the provider offers, so even an approved call can do as little as possible.

The proxy works alongside your existing prompt-injection controls, such as input filtering, output checks and least-privilege tool design. It doesn't replace any of them.