On (1), the agent runs in its own container where OneCLI doesn't exist. It can't spin up OneCLI or access its process because it's completely isolated from it. The agent only ever sees placeholder tokens, the real secrets live in a separate container it has no way to reach.
On (2), we actually address this with OneCLI Rules, deterministic constraints enforced at the proxy level before a request ever hits the API. So the agent doesn't need to "behave", it just can't do what the rules don't allow. Would love to hear more about your signed tokens approach.
Re IronClaw is probably the most hardened open-source implementation I've seen for this, but a sufficiently clever prompt injection against the built-in tools (especially shell) could still reach secrets.
Re TLS: OneCLI itself runs in a separate container, acting as an HTTPS proxy. The SDK auto-configures agent containers with proxy env vars + a local CA cert. When the agent hits an intercepted domain, OneCLI terminates TLS, swaps placeholder tokens for real creds, and forwards upstream. Containers never touch actual keys.
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."