Infisical Agent Vault
Credential Management for Agents That Don’t Know They Have Credentials
The question every enterprise CISO asks and nobody has a good answer for: what happens when a prompt-injected agent tries to call an internal API with stolen credentials?
The credential problem in agent systems is not that agents need secrets. Applications have needed secrets for decades and we solved that with vaults, environment variables, and the occasional embarrassed postmortem. The problem is that agents are the first class of software that can be tricked into revealing their secrets, and the attacker does not even need access to the machine. They only need to get text into the prompt.
Prompt injection turns every credential an agent holds into an exfiltration surface. The agent reads a poisoned document in a RAG pipeline, or visits a webpage via a tool call that contains an injection payload, and suddenly it is forwarding its Anthropic API key to the attacker’s endpoint. The agent does not know it has been compromised. It is doing exactly what it was asked to do. The credential is not stolen through a vulnerability in the vault or the network layer. It is extracted through the interface the agent was designed to expose.
Infisical Agent Vault solves this by ensuring the agent never holds a credential in the first place. It sits between the agent and every API the agent calls, intercepts outbound requests, and injects the real secret at the network layer. The agent sends a request with a placeholder like __anthropic_api_key__ in the authorization header. Agent Vault catches the request, swaps the placeholder for the actual key, and forwards it. The agent never learns the real value. The real value never enters the agent’s memory, never appears in a tool-call log, and cannot be exfiltrated no matter what the prompt injection payload asks for.
This is a fundamentally different security model from traditional secrets management. Traditional vaults return credentials to the application, which then uses them. Agent Vault never returns credentials to the agent. It brokers them at the proxy layer. If you are thinking of this as a secrets manager that agents can query, you are thinking of it wrong. It is a credential proxy. The secrets stay in the vault. The agent stays credential-free. The proxy does the substitution on every outbound request and the agent receives only the response, not the key.
The architecture is a TLS-intercepting forward proxy purpose-built for agent workloads. You install Agent Vault as a Docker container or Go binary, store your credentials in its encrypted local store or in an external Infisical instance, and configure your agent’s environment to route HTTPS traffic through the proxy using the standard HTTPS_PROXY environment variable. Every outbound request, regardless of how the agent initiates it, flows through Agent Vault’s MITM layer. The proxy checks whether the destination matches a configured service, and if it does, it injects the appropriate credential. If the destination does not match any configured service, it forwards the request as plain proxy traffic, unless you have set the vault to strict deny mode, in which case unrecognized destinations get a 403.
The operational model is worth understanding because it imposes constraints that matter in production. Agent Vault performs TLS interception, which means it must present its own certificate to the agent and establish its own TLS session with the outbound API. For this to work, the agent’s runtime must trust Agent Vault’s CA certificate. This is straightforward in Docker or Kubernetes environments where you control the certificate store. It is more involved in managed runtime environments or CI pipelines where the certificate store is not under your control. The HTTPS_PROXY environment variable is a standard that most HTTP clients honor, but it is a convention, not a security guarantee. An agent programmed to ignore proxy settings can bypass the vault entirely. In a production deployment, you lock down the network so that the agent’s outbound traffic has no path to the internet except through Agent Vault. The proxy setting is a convenience for compliant clients. The firewall rule is the enforcement layer.
What Agent Vault does well is narrow but well-executed. It supports a growing list of known agent frameworks: Claude Code, OpenClaw, Hermes, Pi, Devin, Windsurf, Cline, Roo Code, and custom agents. The integration model is agent-agnostic. You do not need LangChain middleware or a custom tool wrapper. You set the proxy, store the credential, and it works. The multi-tenancy model supports multiple vaults per instance, each with its own set of credentials and its own agent roster. A team running three separate agent deployments can isolate their credentials at the vault level, so that the coding agent’s GitHub PAT cannot be used by the support agent, even if both route through the same proxy.
The egress filtering layer adds a dimension that most credential tools lack. You can define which services each vault is allowed to access, down to the API endpoint level. An agent configured to call the Anthropic API can be restricted from calling any other endpoint on api.anthropic.com. An agent that should only push code to a specific GitHub repository can be restricted to api.github.com/repos/my-org/my-repo. The filtering is enforced at the proxy layer, which means it is applied uniformly across all tool calls, MCP servers, and custom integrations that the agent uses. There is no code path that bypasses it because every outbound HTTP request goes through the same proxy.
The request logging is similarly valuable and similarly blunt. Every authenticated request is logged with its destination, status code, latency, and the actor name of the requesting agent. For a security team investigating an incident, this log provides the complete picture of what the agent did and when. For a development team debugging a misbehaving agent, it is the fastest way to identify which tool call failed and why. The logging layer is not an observability platform. It is a raw request log that you pipe into your existing log aggregation stack. It does not provide spans or traces or flame graphs. It provides the one thing that matters most for credential security: an immutable record of every authenticated request.
The gaps are real and they matter for enterprise adoption. Agent Vault v0.39.0 is a young project, approximately 1,900 stars, released in late June 2026, still shipping features at a weekly cadence. The TLS interception model requires certificate management that most teams will need to script. The HTTPS_PROXY convention is not a security boundary, and the firewall enforcement layer that makes it one is your responsibility, not the product’s. The credential substitution model relies on pattern matching in request headers, which works for REST APIs with static authorization patterns but becomes fragile when APIs use dynamic authentication schemes, signed requests, or custom header formats. The project is investing in the known-agents list, which suggests the team understands that integration ergonomics are the adoption bottleneck, but the current integration model still requires per-agent configuration that a platform team must maintain.
The question that matters for an enterprise team evaluating Agent Vault is not whether it solves the credential exfiltration problem. It does, within the constraints described above. The question is whether the operational burden of running a TLS-intercepting proxy with certificate management and firewall enforcement is worth the security gain over the alternative of simply not giving the agent credentials to things it should not access. For many teams, the answer will depend on the blast radius of the agent’s tool access. An agent that can only call a single read-only internal API has a small blast radius and may not need a credential proxy. An agent that can push code to production, modify database records, or authorize financial transactions has a blast radius large enough that not deploying a credential broker is a decision you will eventually have to explain to someone who does not find “the agent would never do that” reassuring.
That is the honest framing. Agent Vault is not a silver bullet. It is a specific, well-designed tool that solves a specific, well-defined problem: preventing credential exfiltration from prompt-injected agents by ensuring the agent never sees the credential. It does this at the network layer, which is the right layer for a security guarantee. It is backed by Infisical, a company that has been shipping enterprise secrets management since 2022 and has the compliance posture to back a security product. It is open source under the MIT license, self-hostable, and built with the agent ecosystem in mind. For a team that is serious about deploying agents with production credentials, it is the best option available. For a team that is not yet serious about deploying agents with production credentials, the question to ask is not whether you need Agent Vault. The question is what happens when the first incident forces you to need it and you do not have it.
If this was useful, forward it to one engineer who needs less noise in their feed.