Rain Agent Control Layer

Rain's Agent Control Layer is a policy layer over its card-issuing and money-movement APIs. A partner sets the rules for each agent before it can spend, and Rain enforces them when it decides whether to approve the transaction.

TL;DR

Rain’s Agent Control Layer is a policy layer over its existing card-issuing and money-movement APIs. A partner sets the rules for each agent before it can spend, and Rain enforces them when it decides whether to approve the transaction. It launched in beta on June 9, 2026.

What it controls: card amount, merchant and category allowlists, spend intervals, and card expiry for each agent. It also caps active cards and total spend for the whole program. For bank and stablecoin transfers, it controls approved counterparties, amount, frequency and timing.
How it enforces: rules are set “at card issuance and transfer initiation.” A transaction outside them “does not proceed.” That means an authorization decline, not a dispute after the fact.
The main building block: a single-use virtual card for one task, funded from the user’s stablecoin balance, used once and then retired. Sponge (YC) runs on exactly this.
Why Rain can do it: Rain is a Visa and Mastercard principal member and makes the approve/decline decision itself, so its rules run on the live authorization path.
What’s missing: the public material doesn’t show task-bound credentials, human-in-the-loop approvals, agent identity (“Know Your Agent”) or dispute handling.

Rain’s developer docs require a login. Everything here comes from public posts, the press release and partner documentation. Mechanics I’ve inferred rather than found in a source are labelled inferred.

Where it sits in Rain’s stack

The Agent Control Layer sits between Rain’s API and its two engines: card authorization and money movement. Every agent card or transfer passes through it, so policy is always checked before money moves.

Architecture: user, partner and agent above the Rain API; the Agent Control Layer's three rule groups feed the card authorization and money-movement engines; Visa/Mastercard, the user's collateral contract and counterparties below

The agent never touches the user’s wider balance. It holds only a card number whose rules are enforced by Rain, which issues the card and decides whether to approve each payment. Collateral stays in the user’s own smart contract, and Rain settles against it after paying the merchant in fiat.

Control primitives

The controls fall into three groups: rules on each agent’s card, rules on the whole program, and rules on money movement. Rain’s own example: an agent given a card for a single booking “can be limited to approved airlines or hotels, capped at a set amount, and restricted to a defined window.”

Group	Control	What it stops	Likely API surface
Agent card	Transaction amount cap	Overspend on a task	`limit.amount` on the card object (confirmed in partner docs)
Agent card	Spend interval	Repeated drains	`limit.frequency` (e.g. `allTime`, confirmed); other values inferred
Agent card	Merchant / category allowlist	Wrong vendor, wrong category	MCC and merchant lists checked at authorization (inferred)
Agent card	Card expiry window	A card outliving its task	Card expiry / status (`active` → cancelled)
Program	Cap on active cards	Runaway card creation by a buggy agent	Program config (inferred)
Program	Aggregate spend limit	Total loss across all agents	Program config, plus “visibility for unusual activity”
Money movement	Approved counterparties	Payouts to unknown wallets or accounts	Allowlist on virtual accounts, onramps, offramps, payments
Money movement	Amount, frequency, timing	Off-schedule or oversized transfers	Checked when a transfer is initiated

The card controls sit on top of Rain’s existing card model. A user (KYC’d) owns a collateral smart contract funded with stablecoins. Rain issues a Visa card against it, with a limit of {frequency, amount}. A balances endpoint reports creditLimit, spendingPower and balanceDue in cents. The Agent Control Layer adds merchant scope, expiry and program-wide caps to that card, plus the same idea on transfers.

The unit of control is the card, not the agent. Each agent or task gets its own card, so revoking access means cancelling a card. Rain doesn’t publicly describe a separate agent identity object.

Transaction lifecycle

A purchase goes through ten steps. Policy is set at step 2, and Rain checks it at step 6 when the network asks it to approve or decline the payment.

Ten-step flow: user guardrails, partner API call, single-use card, agent pays merchant, Visa auth request, five policy checks, approve or decline, settlement from collateral, card retired, webhook and audit log

Steps 1–3, setup: the user’s budget and vendor rules become a card. The policy lives in the POST /cards payload, and the card exists only for this task.
Steps 4–5, spend: the agent checks out like any customer. The merchant and acquirer see an ordinary Visa card.
Step 6, enforcement: Rain compares the payment against the card’s rules, the program caps and the user’s available collateral (spendingPower). Exactly which checks run in real time is inferred from the controls Rain publishes.
Steps 7–10, close out: Rain pays the merchant in fiat and settles from the collateral contract. The card is retired, and the partner gets a webhook it can use for an audit trail.

Transfers follow the same pattern without a card network: the counterparty, amount, frequency and timing are checked when the transfer is initiated.

Developer integration

Rain integrates through a REST API that authenticates with an Api-Key header. A Crossmint wallet guide shows the endpoints for a stablecoin-backed card (staging base api-dev.raincards.xyz/v1):

POST /issuing/applications/user creates the user application with KYC data. The response returns a userId and an applicationStatus.
POST /issuing/users/{userId}/contracts deploys the collateral contract on a chosen chainId and returns a depositAddress.
The user funds that address with stablecoins (USDC, USDT, PYUSD and others, on Ethereum, Base, Polygon, Solana, Avalanche and more).
POST /issuing/users/{userId}/cards issues the virtual card with type, limit {frequency, amount}, displayName and status. For an agent, this is the call that carries the policy.
GET /issuing/users/{userId}/balances reads spendingPower before the agent acts.

Rain publishes an AsyncAPI definition for its webhooks and has an MCP server. Even so, API Evangelist scores its developer ergonomics at 2.9/20 because so little of the docs is public or machine-readable. The public docs don’t cover idempotency, error semantics, sandbox simulation, SDKs, or reference agents.

Inferred: the Agent Control Layer probably extends the card-create payload (merchant/MCC lists, expiry) and adds a program-level config object, rather than introducing a new resource. I couldn’t confirm this because the docs need a login.

Customers and ecosystem

Two customers are public, and they use the layer in different ways: one for single-use cards, one as an operating system for agents across several payment types.

Who	What they build	How they use Rain	Quote
Sponge (YC)	Agents that buy software, compute, travel and data for users	User completes KYC and the agent acts as an extension of the user. Each purchase gets a single-use virtual card against the user’s stablecoin balance, retired afterwards	“The easiest way to set up a card issuance program, especially one backed by stablecoins” (Eric Zhang, co-founder)
Reah	Agentic finance OS	One policy engine across card, account and stablecoin payments, with live balance checks and full audit logs	“Money can move programmatically across rails, with clear guardrails, all in one place” (Jake Margulies, co-founder)

On August 18, 2026 Rain launched the Agentic Payments Alliance with 25 founding members, including Visa, Mastercard, Fiserv, Circle, Solana, Avalanche, Monad, Uniswap Labs, Fireblocks, Turnkey, Crossmint, Lithic and Sardine. Its working groups cover agent identity and authorization standards, regulation, and an Agentic Startup Program. CEO Farooq Malik: “No single company should get to decide how agents transact on someone’s behalf.”

Gaps and what to build next

Today’s beta controls what an agent can spend. It doesn’t yet cover who the agent is, when a human has to approve, or what happens when a payment is disputed.

Sources

Introducing the Agent Control Layer (Rain)
Press release, June 9, 2026 (PR Newswire)
Sponge is betting on agentic commerce (Rain)
Q&A: how Reah is building safer agentic commerce on Rain (Rain)
Rain launches the Agentic Payments Alliance (Rain)
Crossmint guide: Rain card issuance API (endpoints and fields)
Sacra: Rain (collateral model)
API Evangelist: Rain (DX score, webhooks, MCP)