OmniClaw
Payments Infrastructure for AI Agents
Open-source infrastructure that lets autonomous agents pay for things without ever holding unrestricted access to a wallet.
- 0+
- Test transactions
- 0+
- Developer feedback
- $0
- Google Cloud credits won
Demo
An agent negotiating and settling a paid API call over Telegram — price, endpoint and spend policy set from chat, executed through OmniClaw.
Problem
To let an AI agent buy something, you currently hand it wallet access. That is the entire security model, and it is indefensible — one prompt injection, one hallucinated recipient, one loop that retries a transfer forty times, and the money is gone. Agents need to be able to spend without being trusted.
Why I built it
Agent commerce is going to happen whether or not the safety layer exists. I would rather the layer exist. Built it into a first-place finish at the Circle × Google DeepMind Agentic Commerce hackathon on Arc, and kept going after.
What I built
A payment execution layer that sits between the agent and the money. Policies are enforced outside the model: spending limits, recipient allowlists and validation, rate limits, agent identity, and transaction policies the agent cannot talk its way past. The agent expresses intent; the infrastructure decides whether that intent is permitted.
How it works
- Agent expresses a payment intent
- Agent identity resolved and authenticated
- Transaction policy evaluated — limits, rate, recipient
- Recipient validated against allowlist
- Payment routed via x402 / CCTP
- Execution through developer-controlled wallet
- Result returned to the agent with an audit trail
What I did
- Payment execution architecture
- Policy and guardrail design
- Frontend architecture and dashboard UI
- MCP server integration
- Open-source maintenance and developer support
Technology
- x402
- CCTP
- Circle Developer Controlled Wallets
- MCP
- TypeScript
- React
- Node.js
- AI Agents
Challenges
Guardrails have to be deterministic. Anything enforced by prompting the model is not a guardrail, it is a suggestion — so every limit lives outside the agent, in code that cannot be argued with.
What I learned
The interesting constraint in agent payments is not cryptographic, it is authorisation design. "What is this agent allowed to do, on whose behalf, up to what limit, for how long" is the whole product.