jonathan from OneCLI here, yes - approval binds to the exact req by opening it (method, URL, body) when there’s a matching policy defined. then the gateway holds the call and the card shows the parsed payload.
just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.
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?
Almost every API caller has to add the logic for retries based on the response codes, centralizing it with the gateway optimizes the repetitive code across the clients.
Trip breaker patterns are good for resource usage on both sides (client and server) when you know things are not working. In addition to that it also saves on cost for the clients if every call is billed irrespective of success or failure.
got it. we have not heard that need from users yet, but, can def see it being usefule as a fallback mechanism, since we are already sit at this network proxy layer.
what type of calls are you aiming to? can share example of that "call is billed.." is that specific apps you have in mind?
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.
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."
In games, AIs usually communicate with a blackboard. Grokboard would rhyme but implies xAI associations. Flockboard? Not so nice sounding but accurate.
just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.