Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Holy mother of whatever this is, everyone got the same idea again and there’s a bunch of implementations people are desperate to promote in the comments.
You’re just trading one key for another, whatever abstraction you chose to trust, at some point credentials will pass to your llm of the week.
- I happen to know a solution where credentials wouldn't get to the agent. It's structurally impossibleby theapiartist
- > at some point credentials will pass to your llm of the week.
How?
by mjg59 - love itby chaandannn
- oauth, saml, oidc accomplish the same thing in a way more mature way, so if you’re already using SSO just do that instead of adding another point of failure..
- No they don't - you're still giving the agent a static token that can be exfiltrated and used elsewhere.by mjg59
- It is hilarious to see most comments are people peddling their own products more or less directly.by stephantul
- This is what happens when building software goes to 0.
"Build it and they will come" now works well for competition:
- If you build it (and it is not useful) they won't come.
- If you build it (and it is useful and successful) they will come and copy you to build their own.
by rvz - What happens if the "fake" key gets compromised?by trallnag
- This is the same old good way from database world. A db client never touches the disk, but sends requests to a server who owns it. Same in your product. Keys are separated from agents and if needed, agents must send request to a proxy who owns them. Old proven design. Good luck.by osinix
- Oo this is interesting, blocking it on the network level is nice
- does the agent control the environment that onecli is running in? (yes)
- yes the agent controls its environment which is exactly why nothing sensitive should live there. The gateway and the real secrets sit outside the sandbox. that said, not holding the secrets doesn't make the agent harmless. It still acts autonomously, and it can use whatever access those credentials grant. do you see the second half as the bigger risk? curious how people are thinking about it.
- MITM is a feature now.by vayup
- How does it compare to agent-vault and clawpatrol?by emilsoman
- It works great for static credentials. As a product I think about adding couple more things that might be helpful here (Btw I am not the client for this, I just happen to know them as practical problems)
1. Support for OAuth Client credentials - Gateway does the OAuth dance to get the access token, this is quite practical and even useful in case of regular services running across clusters and sharing the same clientId-secretId
2. Support for request retries on certain failures and short circuiting in other cases
by sandeepkd - Also it would be nice to support browser cookies and flows too.by Onavo
- thanks, both are useful.
1. we support OAuth apps today, and we're growing the catalog based on demand. we support rotating and refreshing tokens for those.
2. I'd like to understand your case better. sitting in the request path means we could own retry mechanisms, but I'm curious what made you think of it, what kind of use cases did you have in mind?