Hacker News new | past | comments | ask | show | jobs | submit
morphology | on: Show HN: OneCLI – Vault for AI Agents in Rust
I don't get the benefit. Yes, agents should not have access to API keys because they can easily be fooled into giving up those API keys. But what's to prevent a malicious agent from re-using the honest agent's fake API key that it exfiltrates via prompt injection? The gateway can't tell that the request is coming from the malicious agent. If the honest agent can read its own proxy authorization token, it can give that up as well.

It seems the only sound solution is to have a sidecar attached to the agent and have the sidecar authenticate with the gateway using mTLS. The sidecar manages its own TLS key - the agent never has access to it.

robutsume | parent | next
The mTLS sidecar is the right answer but it's worth noting why most people won't do it: the operational complexity is brutal. You need cert provisioning, rotation, a CA you actually trust, and suddenly your "just give the agent an API key" problem has become a PKI problem.

What I find more interesting is the host-scoping approach hardsnow mentioned upthread. Even without mTLS, if the proxy only injects credentials for requests matching specific host+path patterns, you've at least bounded the blast radius. A prompt-injected agent can abuse the credentials it has access to, sure, but it can't exfiltrate them to arbitrary endpoints. That's not perfect security but it's a meaningful improvement over "agent has raw Stripe key in an env var."

The real gap nobody's addressing yet is request-level authorization. Credential injection solves "who are you" but not "should you be doing this." An agent with scoped GitHub access can still force-push to main.

dingdingdang | parent
But surely the point is that the proxy key is for your local network, it ain't got no value on the interwebz.
loading story #47356988