This is a good start, it does covers gaps in certain areas. There are few more areas I can think of
1. The end point matters, example if the credential is OAuth2 token and service has a token refresh endpoint then the response would have a new token in the payload reaching directly to the agent
2. Not all the end points are made the same even on the service side, some may not even require credential, the proxy may end up leaking the credential to such endpoints
3. The proxy is essentially doing a MITM at this point, it just increased its scope to do the certificate validation as well, to do it correctly is a hard problem
4. All credentials are stored on a machine, it requires a lot more access & authorization framework in terms of who can access the machine now. One might think that they closed a security gap and soon they realize that they opened up couple more in that attempt
dangtony98 8 hours ago [-]
T from Infisical here - Also forgot to mention that this is a research preview launch for Agent Vault and should be treated as such - experimental <<
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 :)
gregw2 6 hours ago [-]
I have a related question, is anyone developing standards on how agents can proxy the requestor identity to backend database or application layers? (short lived oauth tokens perhaps, not long lived credentials like the ShowHN seems to focus on?)
rmorlok 4 hours ago [-]
I really like the approach you've taken of providing an egress proxy. That let's you do a lot of things that layer around providing gaurdrails and auditing. I've been taking a similar approach on an open source embedded iPaaS project I've been working on where it primarily offers an authenticating egress proxy to whatever business logic needs it (agent, sync engine, etc).
Brokering at the proxy layer instead of handing secrets to the agent is the right mental model. With prompt injection being what it is, "the agent never possesses the credential" is a much stronger property than any amount of scoping. Curious how the non-cooperative container sandbox feels in practice once more agents are supported.
dangtony98 5 hours ago [-]
I'm so glad you mentioned the non-cooperate sandbox! Did you get a chance to try it out?
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.
Jayakumark 7 hours ago [-]
How is it different from Onecli ? And does it do credential stripping ? Will it support access SDK from Bitwarden and integrate with infiscal ?
dangtony98 5 hours ago [-]
To be honest, I haven't used OneCLI personally before so I can't speak to it in detail but Agent Vault does take a similar approach with the MITM architecture and setting HTTPS_PROXY in the agent's environment to route traffic through the proxy; we feel like this is the right approach in terms of interface-agnostic ergonomics given that agents may interact with upstream services thru a number of means: API, CLI, SDK, MCP, etc.
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).
jeremyjh 4 hours ago [-]
NVIDIA's OpenShell also has its own version of this, though its also in very early stages.
hrimfaxi 5 hours ago [-]
It looks a lot like OneCLI too. Curious how it differs.
dangtony98 4 hours ago [-]
We're still in the early innings of credential brokering so there'll be a lot of overlap but I expect the way the tool evolves will start to diverge a lot since we are thinking very infra-workflow first.
See my other comment regarding an example of this.
hanyiwang 2 days ago [-]
This doesn't change the fact that you'd still be able to exfiltrate data like sure they don't get credentials but if they get the proxy auth key then they would also be able to make requests through it no?
dangtony98 2 days ago [-]
Yeah so Agent Vault (AV) solves the credential exfiltration problem which is related to but different from data exfiltration.
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.
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.
zackify 6 hours ago [-]
Completely unaffiliated but I just installed executor.sh today and it looks almost exactly the same
dangtony98 5 hours ago [-]
I haven't used executor.sh but this seems to operate at a different layer from Agent Vault.
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.
dandaka 22 hours ago [-]
Can I use Infisical cloud vaults with Agent Vault? I like the UI of secret management there. I like that I can manage secrets from many environments in a single place.
dangtony98 14 hours ago [-]
We'll be releasing a closer integration between Agent Vault and Infisical in the coming 1-2 weeks!
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!
tuananh 4 hours ago [-]
how do you deal with "access to the proxy"? because one can access maliciously without accessing to the token/secret.
dangtony98 3 hours ago [-]
Agent Vault should remain in close proximity to the sandboxed agent and not be exposed to the public internet; your standard network security controls apply.
The proxy itself currently implements a token-based auth scheme. Depending on your setup, you can have an orchestrator mint an ephemeral token to be passed to a sandboxed agent to authenticate with the proxy.
tuananh 3 hours ago [-]
this feels like vpn all over again. the location shouldn't grant any inherent trust.
dangtony98 3 hours ago [-]
[dead]
8 hours ago [-]
Bnjoroge 8 hours ago [-]
infisical is great so excited to see this
dangtony98 8 hours ago [-]
Thank you! Me too - very excited to see where this goes :)
whattheheckheck 5 hours ago [-]
How do you solve for the agent signing up for a service and needing to save it and guaranteeing the credit wont go to the chat?
dangtony98 5 hours ago [-]
Can you please elaborate on the agent signing up for a service piece? I'm curious to understand the use case more (type of agent, what credit, etc.).
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.
whattheheckheck 4 hours ago [-]
Yeah idk if this is solveable but let's say I have a master agent that I say go sign me up for these services so you can build secure agents to use the keys securely.
It seems like it simply has to stop and tell me to handle the secrets to put them in vault. Because of the data/instructions in same channel problem.
cristianolivera 3 hours ago [-]
yea
foreman_ 1 hours ago [-]
[dead]
yujunjie 3 hours ago [-]
[dead]
Remi_Etien 2 days ago [-]
[dead]
bayff 7 hours ago [-]
Curious how you think about this meeting the agent-identity side. The proxy knows who's calling, but the callee (what agent lives at api.example.com, what auth it expects, what its card looks like) doesn't really have a home. Been poking at that half at agents.ml and it feels like the two pieces want to fit together
dangtony98 6 hours ago [-]
Hey! At the moment Agent Vault doesn't address the identity piece.
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.
sharathr 7 hours ago [-]
From what I can tell, agent-vault does not solve identity, only how its stored. For true agent identity, you should look into: https://github.com/highflame-ai/zeroid (author: full disclosure)
codebje 7 hours ago [-]
ZeroID looks like a good idea to me. Lots there I'll be digging into over time, and related to the use of token exchange for authorising back-end M2M transactions on behalf of a user at the front-end.
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.
bayff 6 hours ago [-]
Yeah I'm leaning deterministic too for most needs, but I do think there's a future for agent to agent communication in more specialized cases. I think an agent having access to proprietary datasets / niche software can produce an interesting output. Say someone wants a drawing in autocad, communicating with a trained agent that has mcp access to these kind of tools seems like it could be beneficial to extend a more generalist agent's capabilities.
Rendered at 06:08:22 GMT+0000 (Coordinated Universal Time) with Vercel.
1. The end point matters, example if the credential is OAuth2 token and service has a token refresh endpoint then the response would have a new token in the payload reaching directly to the agent
2. Not all the end points are made the same even on the service side, some may not even require credential, the proxy may end up leaking the credential to such endpoints
3. The proxy is essentially doing a MITM at this point, it just increased its scope to do the certificate validation as well, to do it correctly is a hard problem
4. All credentials are stored on a machine, it requires a lot more access & authorization framework in terms of who can access the machine now. One might think that they closed a security gap and soon they realize that they opened up couple more in that attempt
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 :)
https://github.com/rmorlok/authproxy
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 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.
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.
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 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!
The proxy itself currently implements a token-based auth scheme. Depending on your setup, you can have an orchestrator mint an ephemeral token to be passed to a sandboxed agent to authenticate with the proxy.
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.
It seems like it simply has to stop and tell me to handle the secrets to put them in vault. Because of the data/instructions in same channel problem.
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.