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

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...

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.

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.

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.

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.

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

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.

Thank you! Me too - very excited to see where this goes :)

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

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!

It prevents a compromised agent from seeing the secret. There are two different but related problems here: credential exfiltration and data exfiltration.

The problem that Agent Vault (AV) solves is the former while the latter requires more guardrails beyond the scope of AV.

In the event that an agent is compromised, are you are at least able to revoke its access since request/data flow runs through AV; the malicious actor does not get any credentials.

Now if the attacker was to obtain credentials in the first place, you'd be stuck chasing down hundreds, if not thousands, of secrets especially if the agent was part of a multi-tenant system doing things on behalf of users.

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.

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...

This was indeed sarcasm haha

Hey HN! Infisical SSH, an extension of the open source Infisical platform [1], gives you a solution to centralize SSH access for your team and infrastructure.

Infisical SSH eliminates the need for you to manage SSH keys in favor of short-lived SSH certificates issued on demand. From one dashboard, you can define which users should have access to which machines and let Infisical facilitate connections using SSH certificate-based authentication under the hood.

With just a few clicks, you can bootstrap the same secure, scalable SSH certificate-based authentication scheme that companies like Meta, Uber, and Google use to scale SSH access across their infrastructure.

[1] Infisical - https://github.com/Infisical/infisical

Great pros and cons analysis honestly; I would say though that this is isn't buying into the model of Infisical SSH specifically as much as it is just changing the overall approach from SSH public key authentication to SSH certificate-based authentication which has been available for years; Infisical SSH is more-so there to provide the tooling to more easily implement this approach.

Regarding the point on users generating their own keys, I'd say this would still be possible — You can have an SSH CA sign/issue a certificate for an existing key pair.

Definitely some overlap there for sure but with different architecture — this is also an extension of the broader Infisical platform that a lot of companies use for secrets management.

That's correct — The user obtains a short-lived SSH certificate (signed/issued by a CA).

Co-founder of Infisical here!

You're right in noticing that we're moving beyond secrets management into adjacent related verticals as well, specifically branching out more into the larger identity and access management space; secrets management continues to be the bread and butter of Infisical but the way we see it, it would be super nice in the long run to have one unified control plane over all related aspects spanning secrets management to certificate management, SSH access, and more.

One of the core product philosophies of Infisical has always been to abstract away complexity as much as possible while still giving users the ability to customize the tool.

Whereas Vault might, for example, have you explicitly create SSH certificate authorities and require 12+ steps to configure a working SSH certificate-based authentication model, Infisical SSH makes it so you only have to care about users and hosts that is who has access to what with something like 4 steps and if you want more power out of Infisical then that is always possible to build atop.

Good to know regarding Tailscale SSH!

Hey! Co-founder of Infisical here.

I'd say SSH certificate-based authentication is implemented widely at big tech and larger enterprises (tons of sources on it) but hasn't received the same mainstream adoption as SSH public key authentication because the administrative experience to set it up can be quite cumbersome despite how much benefit it provides. Put differently, there's always been a tradeoff in terms of configuration effort and benefits reaped.

With Infisical SSH, we've tried to abstract away as much complexity as possible and give folks the ability to implement a SSH certificate-based access scheme across infrastructure with minimal administrative overhead.

Hey totally agree with the open source aspect here in order for SSH certificates to reach broader adoption (coupled with seamless admin and user experience).

Infisical SSH is actually an extension of the Infisical platform which is open source and used by a ton of companies for secrets management.

It’s a valid question though; I’m also curious what the motivation was here given Cal.com is also open source hmmm