Your AI Agent Has Your Stripe Key. What Could Go Wrong?

Jonathan Fishner — Mon, 16 Mar 2026 12:18:26 +0000

Last month, a developer on our team ran a coding agent to "refactor the billing module." The agent had access to STRIPE_SECRET_KEY through an .env file. It worked perfectly. Until we checked the logs.

The agent had made 14 API calls to Stripe. Twelve were legitimate test calls. Two were live charges.create requests that the agent hallucinated into existence while "testing edge cases."

Total damage: $0 (caught it in sandbox). Total cold sweat: immeasurable.

This is the new reality. AI agents need API access to be useful. But giving them raw keys is playing Russian roulette with your infrastructure.

The Problem Nobody Talks About

Every AI agent framework (OpenClaw, NanoClaw, IronClaw, LangChain, you name it) handles credentials the same way: environment variables or config files.

# The state of AI agent security in 2026
export STRIPE_KEY=sk_live_abc123
export AWS_SECRET_KEY=AKIA...
export OPENAI_KEY=sk-proj-...
export GITHUB_TOKEN=ghp_...

Your agent sees all of these. In plaintext. All the time.

Now consider what happens when:

Prompt injection tricks the agent into exfiltrating keys (proven attack vector, see OWASP Top 10 for LLMs)
Agent hallucination causes it to call the wrong endpoint with the wrong key
A junior dev spins up an agent with production credentials because "it was faster"
You need to revoke access for one agent but the key is hardcoded in 6 places

This isn't theoretical. The 1Password SCAM benchmark showed that AI agents routinely fail basic credential hygiene tests.

The Fix: Never Give Agents Real Keys

We built OneCLI, an open-source credential vault that sits between your agents and the APIs they call.

The idea is stupid simple:

Store real credentials in OneCLI (AES-256-GCM encrypted, decrypted only at request time)
Give agents a proxy URL (HTTPS_PROXY=localhost:10255)
Agents make normal HTTP calls. OneCLI intercepts, matches the destination, injects the real credential, forwards the request

The agent never sees a real key. Ever.

# Before: agent has raw keys
curl -H "Authorization: Bearer sk_live_abc123" https://api.stripe.com/v1/charges

# After: agent talks through OneCLI, real key injected transparently
HTTPS_PROXY=localhost:10255 curl https://api.stripe.com/v1/charges
# OneCLI matches api.stripe.com → injects your Stripe key automatically

What This Actually Looks Like

# 1. Start OneCLI (one command)
docker compose -f docker/docker-compose.yml up

# 2. Add your Stripe key via the dashboard (localhost:10254)
#    Set host pattern: api.stripe.com
#    Set path pattern: /v1/*

# 3. Create an agent access token
#    Scope it to only Stripe endpoints

# 4. Point your agent at the proxy
export HTTPS_PROXY=http://localhost:10255
export HTTP_PROXY=http://localhost:10255

That's it. Your agent makes normal HTTP calls. OneCLI handles the rest.

"But This Isn't New, Just Use a Reverse Proxy"

Fair criticism (we got this on our Hacker News launch). Here's what makes this different from nginx + env vars:

Feature	Reverse Proxy	OneCLI
Per-agent access tokens	No	Yes
Credential never in agent memory	No	Yes
Host+path pattern matching	Manual config	Built-in
Audit log (which agent, which API, when)	DIY	Built-in
Revoke one agent without touching others	Rebuild config	One click
Encrypted at rest, decrypted only at request time	DIY	Built-in

The point isn't that proxying is new. The point is that agent-specific credential management is a distinct problem that deserves purpose-built tooling.

What It Doesn't Do (Honest Limitations)

Let's be real about what OneCLI can't protect against:

If an agent has legitimate access to Stripe, it can still create charges. OneCLI prevents key exfiltration, not API misuse. For that, you need rate limiting and approval workflows (on our roadmap).
Network-level attacks that bypass the proxy. You still need proper network isolation.
Magic. If your agent is fully compromised, no tool saves you. Defense in depth matters.

We wrote a longer piece on what a credential vault can and can't do for agent security.

Getting Started (2 Minutes)

# Clone and run
git clone https://github.com/onecli/onecli.git
cd onecli
docker compose -f docker/docker-compose.yml up

Or install the CLI:

curl -fsSL onecli.sh/install | sh

Dashboard at localhost:10254. Gateway at localhost:10255.

The Numbers

We launched on Hacker News 4 days ago and hit the front page:

680+ GitHub stars in the first week
160+ HN points, 50+ comments
Used in production by teams running OpenClaw and NanoClaw agents

The repo is fully open source (Apache 2.0), written in Rust (gateway) + TypeScript (dashboard), and deploys with a single Docker command.

Star us on GitHub if this is a problem you've hit. We're actively building based on community feedback.

What's your current approach to managing credentials across AI agents? Drop a comment, genuinely curious how others are solving this.

DEV Community: OneCLI