This problem+solution, like many others in the agentic-space, have nothing agent-specific. Giving a "box" API keys was always considered a risk, and auth-proxying has existed as a solution forever. See tokenizer[0] by the fly.io team, which makes it a stateless service for eg - no database or dashboard. Or the buzzfeed SSO proxy, which lets you do the same via an OAuth2-dance at the frontend, and a upstream config at the backend which injects secrets: https://github.com/buzzfeed/sso/blob/549155a64d6c5f8916ed909....
Just because it's been done before for a different use-case doesn't mean that building exclusively for this use-case doesn't remove friction.
But it hasn't been built exclusively for that use case. It's literally the same.
It's not the same. The core overlap is that agents shouldn't be holding raw credentials, that part isn't new, agreed. But the problem space goes further when you're building for agents specifically:
- Requiring human approval before sensitive actions go through (as @guyb3 mentioned in the post)
- Managing short-lived JWT tokens (refresh/access) with tight TTLs.
- Scoping permissions per-session rather than per-service
Auth-proxying solves the "don't give the box your API key" part. But the approval layer and token lifecycle management are what make this agent-specific, not just "SSO proxy repackaged."
I think you have a point. The credential part feels like a solved problem — auth-proxying has been around for a while. What seems genuinely new to me is the approval layer, the idea that a human should confirm before a sensitive action actually executes. I'm not sure that's covered by tokenizer or SSO proxy, but I could be wrong. Is that the real differentiator here, or am I missing something?