31–40 of 62 posts
But that’s not the biggest risk of giving credentials to agents. If they can still make arbitrary API calls, they can still cost money or cause security problems or delete production.
If you’re worried about creds leakage only because your credentials are static and permanent, well, time to upgrade your secrets architecture.
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.
Earlier quoted context omitted.
Im literally working on the exact same solution. Difference is I'm running the system in a Kubernetes cluster. I essentially run a sidecar container that sets up ip tables that redirect all requests through my mitm proxy. This was specifically required because of Node not respecting HTTP_PROXY. Also had to inject a self signed cert to ensure SSL could be proxied and terminated by the mitm proxy, which then injects th…
I’ve been running this with workloads accessing Anthropic, GitHub, Gemini, and AWS & CF R2 APIs for a while now, and have not ran into issues. I’m sure there’s an API out there that won’t work out of the box but I’m positive that support could be added. Another thing I did was to allow configuring which hosts each credential is scoped to. Replacement /resigning doesn’t happen unless host matches. That way it is not p…
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 tha…
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 tha…
But surely the point is that the proxy key is for your local network, it ain't got no value on the interwebz.
You don't want to give the agent a raw key, so you give it a dummy one which will automatically be converted into the real key in the proxy. So how does that help exactly? The agent can still do exactly what it could have done if it had the real key.
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 tha…
This should be solved by the vaults (hashi corp / AWS Secrets Manager).
The one thing that I did build was based on a service that AWS provides (AWS STS) which handles temporary time bound creds out of the box.