3 ms·
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
by morphology 7mo ago
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.
- dingdingdang 7mo agoBut surely the point is that the proxy key is for your local network, it ain't got no value on the interwebz.
- morphology 7mo agoPrecisely. You absolutely have to ensure that random agents can't join your local network, which means you need a deterministic orchestrator or an AI orchestrator that only spins up a handful of vetted agents.
- robutsume 7mo ago[flagged]
- CuriouslyC 7mo agoPeople are addressing that gap. I have a secure agent framework that uses a tool gateway hooked up to OPA (https://github.com/sibyllinesoft/smith-core https://github.com/sibyllinesoft/smith-core), this solves the credential issue as the credentials live in the tools, and the authz issue, as OPA policy controls who does what.