Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Agent Vault – Open-source credential proxy and vault for agents

github.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#51

Post by mooreds »

gregw2 wrote: post #16

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?)

Well, there's the token exchange RFC, which defines on-behalf-of/delegation and impersonation semantics.

https://datatracker.ietf.org/doc/html/rfc8693 has all the details, but here's an example:

   {
      "aud":"https://consumer.example.com",
      "iss":"https://issuer.example.com",
      "exp":1443904177,
      "nbf":1443904077,
      "sub":"user@example.com",
      "act":
      {
        "sub":"admin@example.com"
      }
   }
In this case, the user is user@example.com, but the actor is admin@example.com. (In the agentic case, the actor would be the AI agent.)

Is this kinda what you are looking for?

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#53

Post by Jonathanfishner »

10keane wrote: post #39

been thinking about this exact problem for a while. my own setup uses OS keyring with a token substitution pattern — the agent requests a credential by name, the substitution happens at execution time, the LLM never sees the raw value in context or logs. works reasonably well. but the problem with that model is it's static protection. if the agent process itself becomes hostile or gets prompt-injected, keyring doesn'…

[dead]

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#54

Post by dbuxton »

From the comments looks like lots of people looking at this problem from different angles.

We (harriethq.com) also have a somewhat similar insight, which is that setting up connectors is a drag for non-technical users, and a lot of systems don't support per-user connectivity so need an API shim.

The thing I like about this (Agent Vault) approach is that it's more extensible than what we're offering, which is a full managed service. But we've found that some features (e.g. ephemeral sandboxes to execute arbitrary e.g. uvx/npx based mcps) are just a big pain to self-deploy so it's easier for us to provide a service that just works out of the box.

Kudos to the team, this looks great and I'm looking forward to playing with it

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#55

Post by znnajdla »

hanyiwang wrote: post #2

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?

This doesn’t solve hostile agents. This solves hostile or compromised inference providers. You really don’t want your secrets in the logs of a random AI provider through OpenRouter or even in Anthropic logs.

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#57

Post by dangtony98 »

wfinigan wrote: post #50

Love this. Our team has been frustrated that nothing like this exists. You run into this problem as soon as you start thinking seriously about capable cloud agents, but there was no generic solution. Existing options are either tied to a specific cloud vendor or protocol, like git or MCP. We had a design on the whiteboard for something like this when this release dropped in our laps--with lots of thoughtful choices w…

Yup it turns out many teams building their own custom agents end up stitching together their own solutions for this problem.

What we thought was basically: If everyone is making some version of this egress proxy, maybe we're actually missing a new infrastructure component that does not yet exist in a mainstream way for this use case. The form factor of this was very important in the design of it since it needed to fit in with the tools and workflows that agents are already using today.

Definitely regarding the domain-based allowlist and this is part of how it currently works. As an egress proxy it basically functions as a firewall and we intend to extend it with more capabilities that'll make it more useful.

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#58

Post by dangtony98 »

dbuxton wrote: post #54

From the comments looks like lots of people looking at this problem from different angles. We (harriethq.com) also have a somewhat similar insight, which is that setting up connectors is a drag for non-technical users, and a lot of systems don't support per-user connectivity so need an API shim. The thing I like about this (Agent Vault) approach is that it's more extensible than what we're offering, which is a full m…

Hey! Yeah I think there's overlapping functionality for sure, and you're spot on on people looking at it from different angles.

The "connectors angle" is something we thought about as well and we built a whole product line around that called Agent Sentinel (I'll link that below). We weren't convinced, however, that enterprises were ready for this and instead took it back to our infra roots (Infisical is a security infra platform) and started simple with the problem: credential exfiltration. This thinking does lead to two different kinds of products though with one naturally becoming an infrastructure component; this makes much more sense for us at Infisical to work on.

https://infisical.com/docs/documentation/platform/agent-sent...

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#59

Post by dangtony98 »

sandeepkd wrote: post #38

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 en…

Thanks for this feedback! Will keep in mind all of these points as we iterate on Agent Vault.

We're pretty swarmed on requests at the moment but I've noted these down as improvements to AV; it's a work in progress, we'll be molding it into the right shape over the next few months.

A few thoughts for each of the above:

1. AV doesn't consider OAuth2 tokens atm but this is definitely a next step.

2. Agree which is why there is a "passthrough" mode; for each endpoint, you need to explicitly specify what credential is used for it.

3. That's correct. This is a MITM architecture with credential brokering capabilities added on top.

4. Agree. The idea here is that AV can function both as a proxy and vault but in a true production setting, it should pull credentials from a secure secrets store like Infisical. This way credentials cached in memory in AV can even be made ephemeral.

Great observations all around and we have plans for them :)

Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents

#60

Post by dangtony98 »

mike-cardwell wrote: post #48

Does it work for websockets too, where the authentication is done in a websocket frame? Like for Home Assistant? Also, if the LLM manages to do something to reflect the authentication token back in a response, do you detect it and strip it out as an extra layer of protection?

Not yet for both but this would definitely be on the roadmap; especially the credential stripping portion.

For AV to be really useful, it'd have to support more protocols but we think this first implementation makes a move in the right direction.

Post reply on HN