61–70 of 71 posts
I like this direction. Agents having direct access to credentials always felt a bit scary. This seems cleaner, even if it just moves the trust somewhere else.
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.
Would love to explore this train of thought and what we can do about it.
Could this work (or planned) on gVisor-based sandboxes?
You'd add HTTPS_PROXY to your sandbox environment and pre-configure it to trust the AV CA.
It’s an idea that obfuscates keys a bit, but how are you going to prevent the agent from gaining access to the vault and keys itself? I’ve seen it reverse engineer many things to expose the underlying credentials. I can only think running this on a firewall that the agent can’t access to prevent escalation.
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.
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.
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.
The HTTPS_PROXY approach is clever — interface-agnostic credential brokering without modifying the agent itself. 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…
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).
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…