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 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!
Thank you first of all! ChartDB stands out with its one-query for visualization, AI-powered migration for easy cross-DB transitions, and interactive editing, all free and open-source, combining these features in a user-friendly way.
Thanks for the feedback! We aimed to make database migration easier and found that AI could really enhance this process by handling the complexities of different DB dialects. We'll also explore more deterministic approaches, as you suggested, using a common internal representation. The "Examples" link is being fixed—thanks for catching that!
Thank you!
We use GPT-4o to generate database schema creation scripts for different database dialects.
Basically, we wanted to add the option to export the db schema to any type of database (for easy Migration for example from MySQL to PostgreSQL or from SQLite to MariaDB). First, we tried to implement that logic, after getting into trouble with too many different edge cases and dialect differences between different databases we decided to leverage AI in order to achieve that.