dangtony98

Yeah this should work in an interface agnostic way so be it that the agent invokes CLI, MCP, SDK, or makes an API call, all traffic is routed through the proxy.

That said, there are many DX improvements to be made such as making it easier to load in credentials into AV and more thinking more around how to optimally handle token refreshes. Part of the questioning there is how much work should be delegated to AV and how much should be to the underlying secrets manager (if connected).

The sandboxed agent and AV should ideally not run on the same host because if it did then you're right that a sufficiently sophisticated agent like Mythos could try to reverse engineer and like find kernel exploits to gain access AV credentials.

For this reason, you'd want to keep the two separate; we have some ideas in the works for that atm but largely still experimental.

This would be deployed separately but in close proximity to your sandboxes. You'd want to add network restrictions around sandboxes to only allow outbound requests to AV.

You'd add HTTPS_PROXY to your sandbox environment and pre-configure it to trust the AV CA.

What attack vector are you thinking? Could you elaborate more.

Would love to explore this train of thought and what we can do about it.

Yup! I think the terminologies we're going to be seeing more and more of are "credential exfiltration" and conversely "credential brokering" as a solution to that.

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.

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

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.

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.

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.