Posted by dangtony98 1 day ago
We built Agent Vault in response to a question that been plaguing the industry: How do we give agents secure access to services without them reading any secrets?
Most teams building agents have run into this exact problem: They build an agent or agentic system and come to realize at some point that it needs credentials in order to access any services. The issue is that agents, unlike traditional workloads, are non-deterministic, highly-prone to prompt injection, and thus can easily be manipulated to leaking the credentials that they need to operate. This is the problem of credential exfiltration (not to be confused with data exfiltration).
In response to this, some teams we've seen have implemented basic guardrails and security controls to mitigate this risk in their agentic environments including using short-lived access tokens. The more advanced teams have started to converge toward a pattern: credential brokering, the idea being to separate agents from their credentials through some form of egress proxy. In this model, the agent makes a request to a proxy that attaches a credential onto it and brokers it through to the target service. This proxy approach is actually used in Anthropic's Managed Agents architecture blog with it being that "the harness is never made aware of the credentials." We've seen similar credential brokering schemes come out from Vercel and in Cloudflare's latest Outbound Workers.
Seeing all this made us think: What if we could create a portable credential brokering service plugged seamlessly into agents' existing workflows in an interface agnostic way, meaning that agents could continue to work with APIs, CLIs, SDKs, MCPs without interference and get the security of credential brokering.
This led to Agent Vault - an open source HTTP credential proxy and vault that we're building for AI agents. You can deploy this as a dedicated service and set up your agent's environment to proxy requests through it. Note that in a full deployment, you do need to lock down the network so that all outbound traffic is forced through Agent Vault
The Agent Vault (AV) implementation has a few interesting design decisions:
- Local Forward Proxy: AV chooses an interface agnostic approach to credential brokering by following a MITM architecture using HTTPS_PROXY as an environment variable set in the agent's environment to redirect traffic through it; this also means that it runs its own CA whose certificate must be configured on the client's trust store.
- MITM architecture: Since AV terminates TLS in order to do credential brokering its able to inspect traffic and apply rules to it before establishing a new TLS connection upstream. This makes it a great to be able to extend AV to incorporate firewall-like features to be applied at this proxy layer.
- Portable: AV itself is a single Go binary that bundles a server and the CLI; it can be deployed as a Docker container as well. In practice, this means that you can self-host AV on your own infrastructure and it should work more universally than provider specific approaches like that of Vercel and Cloudflare.
While the preliminary design of Agent Vault is a bit clunky to work with and we’d wished to have more time to smoothen the developer experience around it, particularly around the configuration setup for agents to start proxying requests through it, we figured it would be best to open source the technology and work with the community to make gradual improvements for it to work seamlessly across all agentic use cases since each has its own nuances.
All in all, we believe credential brokering is the right next step for how secrets management should be done for agents and would love to hear your views, questions, feedback!
This is something that we're going to be improving significantly in the next week including the ergonomics of it since the current state of this feature does not yet make it practical enough to be used by developers in a mainstream kind of way; the ergonomics are so important for a devtool.
But yes credential brokering is what the industry seems to be converging on as a solution for how we might prevent credential exfiltration; the egress proxy is increasingly becoming a common pattern in the agent stack based on some of the conversations we've had with AI-forward companies.
Since the project is in active development, the form factor including API is unstable but I think it gives a good first glance into how we're thinking about secrets management for AI agents; we made some interesting architectural decisions along the way to get here, and I think this is generally on the right track with how the industry is thinking about solving credential exfiltration: thru credential brokering.
We'd appreciate any feedback; feel free also to raise issues, and contribute - this is very much welcome :)
From what I'm seeing, executor.sh is an integration and execution layer for agents. Where Agent Vault shines is that it fits right into the tools and workflows that your agents are already using in an interface-agnostic way: API, CLI, SDK, MCP.
Put differently, the MITM architecture of Agent Vault (operates more at the network‑layer) allows the sandboxed agent can do whatever it would've done normally, just all routed through AV - the agent is basically proxy unaware.
The current modal assumes that you have a trusted entity whose able to save credentials to Agent Vault; that entity is likely not the agent itself because that would mean that the agent would have access to credentials. The agent is then simply configured to proxy requests through AV which attaches credentials at this proxy layer. Here are two examples:
Example 1:
- You have a backend that saves an API Key to AV for a specific vault and defines the service rules for how that credential can be used. - That same backend mints a session-scoped token to AV and invokes the creation of a pre-configured sandbox, passing that token into it. - The agent in the sandbox does what it needs to do, requests fully proxied through AV.
Example 2: - A human operator manually goes into AV and adds an API Key. - The human operator spins up an agent (could be an OpenClaw, Claude Code, etc.) in a pre-configured environment to route requests through AV. This can be done using non-cooperative sandbox mode with the AV CLI or through more manual configuration. - The agent does what it needs to do, requests fully proxied through AV.
We're still working on smoothening it out but perhaps this gives you a better idea of how this might work.
AV does have a permission system that supports agents being able to save credentials to it and then subsequently using the proxy (maybe this is what you're targeting) but this isn't the use case that I've personally explored at much; definitely worth looking into tho.
Since we are in the beginnings of Agent Vault (AV), I wouldn't be surprised if there were many similarities. That said, AV likely takes a different approach with how its core primitives behave (e.g. define specific services along with how their auth schemes work) and is specifically designed in an infra-forward way that also considers agents as first class citizens.
When designing AV, we think a lot about the workflows that you might encounter, for instance, if you're designing a custom sandboxed agent; maybe you have a trusted orchestrator that needs to update credentials in AV and authenticate with it using workload identity in order to mint a short-lived token to be passed into a sandbox for an agent - this is possible. I suspect that how we think about the logical design starting from an infra standpoint will over time create two different experiences for a proxy.
If I understand correctly regarding credential stripping then yes. The idea is that you set the credentials in Agent Vault and define which services should be allowed through it, including the authentication method (e.g. Bearer token) to be used together with which credential.
We don't have plans yet to integrate with Bitwarden at this time but this could be something worth looking into at some point. We definitely would like to give Agent Vault first-class support for Infisical as a storage for credentials (this way you'd get all the benefits of secrets rotation, dynamic secrets, point in time recovery, secret versioning, etc. that already come with it).
See my other comment regarding an example of this.
The way we see it is that you'd still need to centrally store/manage secrets from a vault; this part isn't going anywhere and should still deliver secrets to the rest of your workloads.
The part that's new is Agent Vault which is really a delivery mechanism to help agents use secrets in a way that they don't get leaked. So, it would be natural to integrate the two.
This is definitely on the roadmap!
You're right that if an attacker can access the proxy vault then by definition they'd similarly be able to proxy requests through it to get data back but at least AV prevents them from gaining direct access to begin with (the key to access the proxy vault itself can also be made ephemeral, scoped to a particular agent run). I'd also note that you'd want to lockdown the networking around AV so it isn't just exposed to the public internet.
The general idea is that we're converging as an industry on credential brokering as one type of layered defense mechanism for agents: https://infisical.com/blog/agent-vault-the-open-source-crede...
I use containers to isolate agents to just the data I intend for them to read and modify. If I have a data exfiltration event, it'll be limited to what I put into the container plus whatever code run inside the container can reach.
I have limited data in reach of the agent, limited network access for it, and was missing exactly this Vault. I'm relieved not to need to invent (vibe code) it.
The identity piece would be the next logical step at some point likely after we figure out the optimal ergonomics for deploying and integrating AV into different infrastructure / agent use cases first.
We actually work a lot with identity at Infisical (anything from workload identity to X.509 certificates) and had considered tackling the identity problem for agents as well but it felt like it required an ecosystem-wide change with many more considerations to it including protocols like A2A. The most immediate problem being credential exfiltration seemed like the right place to start since we have a lot of experience with secrets management.
As far as I can tell the parent post is talking about discovery for agent-to-agent communications, which is not something I have much interest in myself: it feels very "OpenClaw" to replace stable, deterministic APIs with LLMs.