SpendShield is an open-source authorization and spending policy layer for AI agents — enforcing budgets, transaction limits, approvals and audit rules before money moves.
Can this agent spend $25 right now? Cumulative, atomic, per identity — not just per call.
Is this action actually authorized? Deterministic policy code, not the model's opinion.
What if the request is replayed, malformed, duplicated, or exceeds policy? Signed single-use grants.
SpendShield sits between agent intent and payment execution.
But real systems also hit retries, parallel agents, duplicate requests, transaction splitting and malformed or injected input. So SpendShield isn't just "$100/day" — it's policy + authorization + enforcement + audit.
| Request | Decision | Reason |
|---|---|---|
| $25 breakfast → mcdonalds.com | ALLOW | within policy |
| $75 weekly plan → mcdonalds.com | DENY | exceeds per-transaction limit |
| replayed request (same grant) | DENY | grant already consumed |
| malformed amount / forged signature | DENY | fail-closed |
Add spending controls to MCP-based agents (Claude, etc.).
uvx --from spendshield spendshield-mcp --policy policy.yaml
Claude setup →
Enforce authorization before payment execution on any rail.
spendshield.adapters.x402
x402 guide →
SpendShield decides whether an agent is authorized to spend. Your wallet / payment rail executes the payment.
Working integration example — policy before Coinbase AgentKit payment actions, with counted executions.
example ↗Glama · awesome-x402 · awesome-mcp-servers · Awesome-MCP-ZH · agentic-commerce · AI security tools (PRs open)
AP2 conformance vectors · verb-authority composition · external reviewer reproductions
MIT · Python + MCP · adversarial test suite · failure map · security checklist