Jonathanfishner

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.

thats cool. n1. spent 15min looking on it rn

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?

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?

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.

Creator of OneCLI here.

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.