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?
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.
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."
Really interesting to see this built on Google Apps Script such an underrated gem for quick, reliable automations! Cal.com is already out there and doing great, but it’s still cool to see this lightweight approach. Sometimes simpler is just better, especially for folks who don’t need a full setup and just want a scheduling tool that ties right into Gmail.
It may be early, but great job putting it out there! Appreciate seeing alternatives that keep things lean and accessible-nice work!
Thank you for the kind words! I'm glad you're enjoying ChartDB. We appreciate your feedback about handling large tables with 100+ columns. Improving that experience is definitely on our radar! It would be great if you could open an issue on our GitHub repo with more details, that way, we can ensure it gets the attention it deserves and make it even better for your use case. Looking forward to your input!
Thanks for catching that! I’ve fixed it for you here: https://dbfiddle.uk/F2vuGKVS. I also tested the export script with a table name like "table", and it worked. If you don’t mind, could you open an issue in our repo? I’ll work on pushing a full fix today.
Thanks for giving it a try! I just tested it on an RDS PostgreSQL 15.4 instance, and it worked on my end. Would you mind opening a GitHub issue so we can dig into this further and help resolve it? Your input will be really helpful in fixing the issue.
Thanks for pointing that out! Just to clarify, we provide a single, hardcoded query that fetches metadata, with no option for user input. The user only needs to take the generated JSON and use it in a React app that they can also run locally. Since there's no user input involved, SQL injection shouldn't be a concern here. If you see any specific risks, though, I’d love to hear more!
Thank you for catching that issue with the STRING_AGG limit! I just pushed a fix that now supports nvarchar(max) to avoid truncation. This should resolve the issue with large outputs in MSSQL. If you still encounter any problems, please let me know. I'd love for you to give it another try and see if everything works as expected now. Your feedback is invaluable!
Thanks for the feedback! The emphasis on a single query highlights how easy it is to import your database schema: just run the query, get the JSON output, and start editing your diagram in ChartDB. Plus, there’s no need to sign in or set your database credentials. It’s all about simplifying the process and saving time so you can get started quickly. Speed is a bonus, but the main value is the simplicity and ease of use. Glad you're giving it a try!