This is a pretty interesting idea @Grégoire Clermont. Just so I'm understanding correctly: • The current friction point you're raising is that you need to manually go in and add which domains are allowed; this means by default, if an operator were to start using Agent Vault without any additional configuration it would start failing. Also worth noting that the operator may not be aware of what hostname is being called right off the bat, making it more cumbersome to configure the existing service "allowlist" configuration. • The proposal is a per-vault opt-in setting that changes unmatched-host behavior from deny to passthrough, with deny remaining the default.

There are currently two ways of using Agent Vault right now - one through MITM transparent proxy (primary) and a second through the explicit proxy endpoint. Currently weighing whether or not the explicit proxy endpoint should be removed as it is additional surface area to have to support and we intend most clients to use the MITM transparent proxy approach. Feel free to drop your thoughts

FYI this PR will introduce a new default behavior adjustment to Agent Vault having to do with passing through all requests by default whereas with the current you have to specify specific services upfront to be allowlisted: https://github.com/Infisical/agent-vault/pull/146 This removes significant friction as @Grégoire Clermont suggested above and how most MITM proxies work by default; the previous behavior of restricting access to specific hosts will still be configurable in vault settings; this change will let more people get up and running with AV quicker.

Also thinking to put more emphasis on the Passthrough auth method in AV with substitutions; this feels like an easier way to offload users' effort in figuring out what auth method they need for a specific service.

Thinking about how AV could support this use case • Teams can share credentials across team members and agents for shared resources • Individual developers can give their agents access to personal resources without sharing with the team For example this would let you share development creds but individual devs could connect to MCP servers that are often user-scoped

Hey there, really enjoying Agent Vault so far. One use case it doesn't seem to cover is short-lived credentials. For example, we'd like to be able to use short-lived tokens for a GitHub app. It would be nice if we could give the app token to AV and have it auto-refresh our auth tokens under the hood. Is that on the roadmap, or something you'd take a contribution for?

Hey @Tony I am a Go fullstack developer and I wanted to contribute to agent vault , I really liked what you are building here. I found that in agent vault while configuring the place holder with credentials as shown in image below , it doesn't provide any suggestions or completion for the name of credentials that we can use and there can be mistakes while typing it and giving completion tab with all the available credentials that we are allowed to use will improve user experience. I want to work on this or if u have some other exciting issue I'd love to work on that too .

Hey @Saif Rahman I visited the Infisical booth today at the AWS DC Summit, and then checked out the AgentVault. I really liked it, and will start working on it and going deep into it as I use it more. Thanks.

@Vlad (Infisical) how can we get started with contributing in infisical agent vault

👋 I've been using agent-vault for an event-driven agent platform and it's been a really great fit for my use case. I opened an issue around allowing Services to restrict by HTTP verb, as well as a draft PR with a first attempt at implementing. Would love to discuss and get feedback on the idea. Love the project!

Hey team 👋 I've been contributing to

agent-vault

and wanted to flag three open PRs in case anyone has a chance to take a look — happy to make any changes needed. 1. Outbound webhook notifications for pending proposals Issue: github.com/Infisical/agent-vault/issues/328 PR: #331 Adds Slack/Discord/generic webhook notifications when a proposal is created, alongside the existing email notifications — with SSRF protection on the webhook client. 2. Prometheus

/metrics

endpoint Issue: github.com/Infisical/agent-vault/issues/329 PR: #332 Opt-in

GET /metrics

endpoint exposing proxy request counts/latency and live proposal backlog by status, for alerting and dashboards. 3. Credential version history and rollback Issue: github.com/Infisical/agent-vault/issues/330 PR: #333 Archives the previous value of a built-in credential on every overwrite (direct set or proposal apply), with `vault credential history`/`rollback` CLI + API to inspect and safely restore prior versions. All three have tests, docs, and addressed review feedback (Greptile) already. Would love a review when you get a chance — thanks! 🙏

Congrats on the launch! 🚀

is there any way to create content around agent vault by some creator program or so? ( i have 6k X followers and 10k for linkedin)

Hi team! I opened PR #375 (github.com/Infisical/agent-vault/pull/375) to fix #305. I’ve signed the CLA, but the check still shows as pending/failed. Could someone please help verify it? Thanks! @Saif Rahman

Read the Agent Vault launch blog post really interesting project. The approach to credential brokering and TLS termination is particularly impressive.

Hello Team, As a current customer I would like to offer a PR to fix the issue with IPv6. Here's the PR: github.com/Infisical/agent-vault/pull/374