You’ve built an AI agent. You’ve given it API keys. And now you’re lying awake at night wondering if it’s going to be tricked into leaking your entire database.
You should be scared. Because the dirty secret of the agentic AI revolution is this: every AI agent you deploy is a ticking security bomb.
We saw it firsthand. Jonathan and I were building ChartDB, an open-source database tool. When the agent hype hit, we started using OpenClaw to orchestrate agents on top of our product. Within days, we hit a wall. The agents needed credentials to do real work—read emails, update CRM records, modify code. But every time we handed over a secret, we lost control. The agent kept it in memory, wrote it to local files, dumped it into session logs. And worst of all? Anyone could trick the agent into giving those keys away with a simple prompt injection.
This isn’t a bug. It’s a fundamental design flaw in how we think about AI security.
We’ve been told that alignment will save us. That if we train the model well enough, it will behave. That’s a lie. Alignment is a false god when it comes to security. You cannot train a model to resist prompt injection any more than you can train a toddler to resist a shiny object. The model doesn’t have judgment. It has pattern matching. And pattern matching can be exploited.
So we built something that doesn’t rely on trust. OneCLI is a network gateway that sits between your AI agents and the services they call. It intercepts every request, verifies the agent has permission for that specific host and path, then swaps a placeholder for the real credential—without ever exposing the secret to the agent. The agent never sees the key. It can’t leak what it doesn’t have.
This is the only logical approach. If you give an AI agent a credential, you’ve already lost. The genuine solution is to strip the agent of credential custody entirely. Enforce access at the network layer, where deterministic rules—not probabilistic models—make the call.
We use it ourselves. My OpenClaw agent runs my day across Attio, Gmail, and my calendar. But it can’t send a sensitive email without my approval—enforced at the network layer, not by the agent’s “good behavior.” Guy uses it to review PRs, but he can’t merge without explicit approval. The policy holds whether the agent is calling via MCP, CLI, curl, or code it wrote on the fly.
Companies are already using it for coding agents, which are notorious for getting creative about elevating their permissions. With OneCLI, it doesn’t matter what the agent finds. If the request isn’t in policy, it doesn’t go through. Period.
Your AI agent will never be “aligned enough” to be trusted with secrets. Stop pretending it will. Build deterministic guardrails instead.
The proxy is written in Rust, the dashboard in Next.js, secrets encrypted with AES-256-GCM at rest. It runs in Docker. It works with any agent framework—Claude Code, Codex, Cursor, OpenClaw, Hermes—anything that can set an HTTPS_PROXY. It won’t stop an agent from misusing access it legitimately has, so scope your policies tightly. But it will stop the nightmare scenario: a prompt injection that turns your helpful assistant into a data exfiltration tool.
We believe the future of AI agents isn’t about making models more trustworthy. It’s about building infrastructure that doesn’t require trust. That’s the only path to safe autonomous agents. And we’re not waiting for the alignment researchers to figure it out.
FAQ
Q: Can't I just train my AI agent to be secure and avoid prompt injection?
A: No. Prompt injection is a fundamental vulnerability of language models. You can reduce the risk, but you cannot eliminate it through training alone. Deterministic infrastructure controls are the only reliable safeguard.
Q: Does this mean I shouldn't use AI agents for anything important?
A: Not at all. Use agents, but never give them direct access to credentials. Use a gateway like OneCLI that enforces policies at the network layer. That way your agent can be powerful without being dangerous.
Q: Isn't this overkill? My agent is just reading my email, not doing anything risky.
A: Even a read-only agent can be tricked into forwarding your emails to an attacker. If the agent has access to a service, a prompt injection can weaponize that access. The only safe approach is to never give the agent the keys in the first place.