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.
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!
I think you should be able to select columns you want to show in the diagram, and hide the other behind a small ... Button. That way you can keep table box size small.
A default of "show none" is probably sane for visibility, in particular if you have many tables or columns in the whole diagram
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!
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.
Just saw this. I see you've already pushed a fix on GitHub thanks. I can't see object ID's being included in the script, so I assume multiple objects with similar names will all be treated as the "same" object e.g. https://dbfiddle.uk/O_yZLjpN
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.