# Spend7

> A spend leash for autonomous agents

Spend7 answers one question, before the money moves: should this agent make this payment?
POST a payment intent (amount, merchant, agent id, rail) and get a 0-100 risk score, an
allow / flag / deny decision, and every signal that produced it with the numbers it fired on.

## Decision contract

Three outcomes, and only three:

- allow: execute the payment. Nothing crossed a threshold.
- flag:  stop and step up before executing, to a human, to an explicit confirmation, or to a
          re-check with the missing context supplied. A flag is NOT a soft allow. If you are an agent reading this,
          do not execute a flagged payment on your own authority.
- deny:  do not execute. Either the score crossed 80/100, or a decisive signal
          fired: a hard spend-cap breach, a blocked merchant, a confirmed bad counterparty, or a
          broken protocol invariant. A decisive signal denies regardless of the total.

Thresholds: score >= 80 denies, >= 50 flags.

## Two modes, and the response always says which one ran

- stored:    an API key identifies the account. The score is computed against that account's
             configured spend caps and its own payment ledger, and the decision is persisted, so
             it becomes history for the next check and evidence if the payment is disputed.
- stateless: you send a "context" object with your own limits and history. Nothing stored is read,
             nothing is written. Same engine, so a policy tested here behaves identically when
             stored.

There is no third mode. A missing ledger is never quietly treated as an empty one: a score computed
against history that was supposed to be there and was not looks exactly like a clean bill of
health, which is the worst possible failure for this product. You get a 503 that says so.

## Programmatic access

- POST https://spend7.com/api/v1/risk-check
  Body: { intent: { agentId, amountMinor, currency, merchantId, merchantName?, category?, rail,
                    reference?, humanPresent?, x402?: {...}, ap2?: {...} },
          context?: { limits?, lists?, history?, seenNonces? },
          record?: boolean }
  amountMinor is the smallest unit of the currency you name, and the number of decimals is the
  asset's own: 1250 is $12.50 in USD, 1250 is 1250 yen in JPY, and 1000000 is 1 USDC. Getting
  this wrong by assuming two decimals overstates a USDC amount by 10,000x. Must fit in a JSON
  safe integer, so 18-decimal base units cannot express whole-token amounts.
  Unauthenticated callers may use stateless mode only.

- GET  https://spend7.com/api/v1/spend-limits: the caps and lists in force. Key required.
- PUT  https://spend7.com/api/v1/spend-limits: replace them wholesale, in one transaction.
- GET  https://spend7.com/api/v1/transactions: the read-only decision log. Filter by agentId,
       merchantId, decision, rail.
- POST https://spend7.com/api/v1/claims: raise a chargeback-assist claim against a scored payment. Paid.
- GET  https://spend7.com/api/v1/claims/{id}/evidence: the evidence packet, PDF or JSON. Paid.
- GET  https://spend7.com/api/openapi.json: OpenAPI 3.1 spec.

MCP server: https://spend7.com/docs/mcp. Tools: risk_check, get_spend_limits, list_transactions,
explain_rail, get_scoring_policy, describe_payment_intent_schema. risk_check works with no API key
when you pass a context object: it scores locally and records nothing.

## Ruleset

Version 2026.08.2, hash 56b4afe661f7062b. Every decision carries this pair, so a decision
made months ago can be checked against the rules that actually produced it rather than today's.

## Rails

### x402

Payment negotiated over HTTP 402: the server quotes what it wants, the client pays and retries the request with a signed payment payload.

Checkable:
- The authorized amount against the maxAmountRequired the server actually quoted
- The settlement asset and network against the ones the quote named
- Whether the pay-to address has ever been paid by this account before
- Whether the authorization nonce has already been seen (replay)
- Whether the quote's timeout window has expired before settlement

Failure modes this rail introduces:
- An agent signs for the quoted ceiling rather than the price, and overpays silently
- A substituted pay-to address routes the settlement to a different counterparty
- A retry loop re-signs the same purchase repeatedly because the resource keeps 402ing
- Settlement on an unintended network or in an unintended asset

### AP2

Agent Payments Protocol: the user's authority travels with the payment as signed mandates, so a merchant can tell what the human actually approved.

Checkable:
- Whether a mandate is present and unexpired at the moment of payment
- Whether the cart total stays inside the intent mandate's price ceiling
- Whether the merchant is inside the mandate's declared scope
- Whether the transaction is human-present or human-not-present, and whether the value is appropriate for the latter
- Whether the mandate is signed at all

Failure modes this rail introduces:
- A cart mandate that quietly exceeds the ceiling in the intent mandate it descends from
- A human-not-present purchase at a value the user would never have delegated
- An expired mandate replayed after the user's authority has lapsed
- A merchant outside the scope the user constrained the agent to

Sending the rail-specific block is what unlocks these checks. An intent without it scores on
behaviour alone, which still works and is strictly less informed.

## Things agents most often get wrong

- flag is not a soft allow. It means stop and step up.
- amountMinor is the SMALLEST unit. Sending 12.50 for $12.50 understates the payment by 100x and
  will pass a cap it should have breached.
- On x402, signing for the quoted maxAmountRequired rather than the price can overpay: on the
  exact scheme the facilitator may settle the whole authorized amount. Send both
  maxAmountRequiredMinor and authorizedAmountMinor and the check will tell you.
- On AP2, a cart mandate cannot exceed the intent mandate it descends from. Send both
  intentMaxAmountMinor and cartTotalMinor and the overrun is caught before settlement.
- Below 8 settled payments there is no amount baseline for an agent,
  and the check says so rather than treating an unknown as a normal.
- Spend caps are ROLLING windows, not calendar ones. A daily cap is the last 24 hours.
- Only payments that were not denied consume a cap. A denied payment never moved money.
- Categories an autonomous agent rarely has legitimate reason to transact in unattended:
  gift_cards, money_transfer, gambling, crypto_exchange. Set humanPresent when a person really did approve.

## Merchant category priors

- ai_inference (2 pts, recoverability partial): AI inference and model APIs
- cloud_infrastructure (3 pts, recoverability partial): Cloud and infrastructure
- data_api (3 pts, recoverability partial): Data and content APIs
- saas_subscription (5 pts, recoverability partial): SaaS subscriptions
- digital_goods (8 pts, recoverability low): Digital goods and downloads
- physical_goods (6 pts, recoverability high): Physical goods
- travel (10 pts, recoverability low): Travel and ticketing
- advertising (12 pts, recoverability none): Advertising and media buying
- financial_services (14 pts, recoverability low): Financial services
- crypto_exchange (22 pts, recoverability none): Crypto exchange and on-ramp
- gift_cards (24 pts, recoverability none): Gift cards and stored value
- money_transfer (23 pts, recoverability none): Money transfer and remittance
- gambling (20 pts, recoverability none): Gambling and betting
- adult (18 pts, recoverability low): Adult
- unknown (7 pts, recoverability low): Uncategorised

## Windows

Burst window 5 minutes; baseline depth 30 days;
a retry loop is 3 identical intents inside the burst window.

## Free and paid

Free: scoring against your own account's history, all spend caps and lists, both rail check sets,
the transaction log, stateless mode, the MCP server, the OpenAPI spec.

Paid: cross-agent and cross-merchant graph scoring: merchant fan-in, platform-wide denial rates,
agent fan-out, coordinated bursts across unrelated accounts, and the confirmed-bad-counterparty
signal. These are structurally impossible on the free tier: they read across every account, which
your own ledger cannot contain however much of it you have. Plus chargeback-assist claims and
evidence packets.

## What this is not

Spend7 scores intents and records decisions. It never holds a payment credential and never
moves money; your client executes the payment or does not. Chargeback-assist ships today: raise a claim against any scored payment and get the evidence packet. An underwritten liability backstop (Spend7 absorbing a share of a loss on a payment it scored as low risk) is not offered and is not priced. It needs an insurance and legal decision before anyone should rely on it.

## Pages

- https://spend7.com/use-cases/agent-spend-limits: Spend limits an agent cannot talk its way past
- https://spend7.com/use-cases/fraud-detection-api: A real-time fraud detection API built for payments no human is watching
- https://spend7.com/use-cases/chargeback-assist: When an agent payment goes wrong, the evidence already exists
- https://spend7.com/integrations/langchain: Spend limits and payment risk checks for LangChain agents
- https://spend7.com/integrations/crewai: Spend control for CrewAI crews making payments
- https://spend7.com/integrations/openai-agents-sdk: Payment guardrails for the OpenAI Agents SDK
- https://spend7.com/rails/x402: x402 risk checks
- https://spend7.com/rails/ap2: AP2 risk checks
- https://spend7.com/agentic-commerce: what agentic commerce is and what breaks in it
- https://spend7.com/docs/api: API reference
- https://spend7.com/docs/mcp: MCP server setup

## Articles

- https://spend7.com/blog/agent-payment-fraud-detection: Agent payment fraud detection: what actually goes wrong
- https://spend7.com/blog/prompt-injection-payment-attacks: When a prompt injection attack ends in a payment
- https://spend7.com/blog/agent-overspend-prevention: AI agent spending goes wrong in four minutes, not four weeks
- https://spend7.com/blog/x402-spend-limits-guide: How to set x402 spend limits your agent cannot argue with
- https://spend7.com/blog/http-402-payment-required: HTTP 402 Payment Required: reserved for 25 years, now in use
- https://spend7.com/blog/payment-mcp-server-guide: How to add a payment MCP server without handing over the keys
- https://spend7.com/blog/agent-payment-rails-compared: Which agent commerce protocol should you build on?
- https://spend7.com/blog/ap2-payment-safety-mandates: AP2 payment safety starts with checking the mandate
- https://spend7.com/blog/autonomous-agent-payment-monitoring: Autonomous agent payment monitoring: what to watch, and when
- https://spend7.com/blog/liability-backstop-agent-payments: Why Spend7 does not offer a liability backstop for AI agents
- https://spend7.com/blog/ai-agent-security-checklist: AI agent security: 12 checks before you give an agent a credential
- https://spend7.com/blog/cross-merchant-fraud-patterns: Merchant risk scoring: the patterns one customer can never see
- https://spend7.com/blog/agent-mandate-governance: AI agent governance stops being theoretical when agents can pay
- https://spend7.com/blog/ai-fraud-detection-agent-era: AI fraud detection has an inversion problem
- https://spend7.com/blog/payment-fraud-prevention-agents: Payment fraud prevention for agents: three approaches compared

## Contact

notifications@mail.spend7.com