We ran into the same problem from the infrastructure side. When you're running agent workloads on Kubernetes, the blast radius of a leaked credential scales with whatever the pod's ServiceAccount can reach. We ended up combining Cilium FQDN egress policies (agents can only call approved endpoints) with per-workload tool allowlists enforced at the CRD level. The network-level lockdown means even if the agent is prompt-injected, it physically cannot exfiltrate to an unauthorized domain.

Curious: have you tested AV with agents that make tool calls through MCP servers? The proxy would need to handle the MCP server's outbound requests too, not just the agent's direct calls.

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

I’ve always felt a bit uneasy about agents getting direct access to keys. Once they have them, it’s hard to know where those keys might go.

This feels cleaner to me. The agent does not need to see the real secrets. You still have to trust another layer, but that layer feels easier to control and reason about.

Would the proxy as designed double as a domain-based allowlist, separate from the credential brokering?

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

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

but the problem with that model is it's static protection. if the agent process itself becomes hostile or gets prompt-injected, keyring doesn't really help — it can still request the secret and get it, it just doesn't see it in the context window.

the shift i've been landing on and building into Orbital(my own project) is that it's less about blocking credential access and more about supervising it. you want to know exactly when and why the agent is requesting something, and have the ability to approve or deny in the moment. pre-set policies are hard because you genuinely can't anticipate what tools an agent will call before it runs — claude code might use curl, bash, or a completely random command depending on the problem. the approval needs to happen at runtime, not preset.

the proxy model here is interesting because it creates a natural supervision boundary. curious whether you're planning runtime approval flows or if the design stays policy-based.

https://github.com/rmorlok/authproxy

Agents having direct access to credentials always felt a bit scary.

This seems cleaner, even if it just moves the trust somewhere else.