Agent spend oversight on Arc
Circle built the payment rail. We show you what’s actually happening on it.
Spendlens screens every micropayment your AI agents make on Arc through a policy filter before it settles, logs the decision, and checks the quality of what came back against on-chain reconciliation.
- 0.000001 USDC
- smallest supported payment
- 3 classes
- of reconciliation mismatch
- 5 components
- interception to reconciliation
- MIT
- license
The infrastructure that guarantees a payment went through doesn’t measure whether it went to the right place for the right value.
“You give your kid a debit card and tell the bank ‘never let a single withdrawal exceed $50.’ If the kid withdraws $49, two hundred times, the limit is never breached — but the account still empties out.”
A static, per-transaction limit can’t solve a behavioral problem. Nanopayments generate thousands of authorizations per minute — at that volume, what matters isn’t the size of any single transaction, it’s the pattern.
Prompt injection
A research agent crawls a page carrying a hidden instruction. It redirects the agent to an address the attacker controls; since no single call exceeds the per-call limit, nothing ever raises an alarm.
Undetectable with existing tools
Silent quality degradation
The agent's data provider breaks and starts returning empty response bodies. Because the HTTP status is still successful, payment keeps flowing uninterrupted — the agent keeps paying for data it can't use.
Undetectable with existing tools
Key leakage
The signing key leaks. The attacker signs authorizations that stay within the existing policy's limits. Wallet policy is never violated, so nobody notices.
Undetectable with existing tools
Sample dashboard
Four numbers. Then quiet.
The screen below is rendered with the dashboard’s real components on a sample dataset — not a static image.
Recent decisions
| Time | Resource | Amount (USDC) | Decision | Note |
|---|---|---|---|---|
| 23:58:20 | api.example.io/v1/data | 0.003000 | allowed | quality: empty |
| 23:58:20 | feed.newsource.io/v1/records | 0.001200 | held · approved | counterparties.first_seen.action |
| 23:58:19 | 0x8f3a…7f80 | 0.004500 | blocked | per_call.max_usdc |
| 23:58:19 | api.example.io/v1/data | 0.003000 | allowed | — |
| 23:57:19 | docs.docservice.io/v1/data | 0.009857 | allowed | — |
| 23:37:57 | api.example.io/v1/status | 0.001866 | allowed | — |
How it works
Five components, one interception point.
Integration is one line: pay.fetch(url, init) and your existing agent is under guard.
- 1
Interception layer
A thin library that wraps the agent's HTTP client. When a 402 response comes back, it hands control to the policy engine before the payment authorization is signed.
- 2
Declarative policy engine
Rules aren't hardcoded; they live in a separate YAML file. Budgets, call limits, counterparty controls, anomaly thresholds.
- 3
Append-only event ledger
Every authorization is logged — allowed and blocked alike. Records are immutable; only new rows get added.
- 4
Quality and waste analysis
Every payment record is matched against the quality of the response it paid for: status code, body, schema conformance, latency.
- 5
Arc reconciliation audit
On-chain settlement records are compared against the local ledger. A mismatch is an early signal of key leakage or a rounding error.