Policy
On this page
One policy per agent. Each key you make gets its own policy row and its own daily cap and hourly count, so two keys on one account never share a limit. The payee lists are the exception: approving a payee adds it for the whole account. The values below are what a new key starts with. Amounts are decimal strings in the asset's smallest unit, so 100000 is 0.10 USDC. Read the policy behind a key with GET /api/v1/policy.
Who gets paid
A payee on the allowlist is one you have approved, so its payments skip the first-time review. A payee on the denylist is one you have ruled out, so every payment to it is denied whatever the amount. A payee on neither list is a first payment, and a first payment waits for a person unless it is under the auto-allow amount. Approving a review can add the payee to the allowlist in the same click, so the second payment to the same seller goes through. Both lists are edited on the Payees page.
Optional wallet blocklist
This check is separate from your manual denylist and starts off. Turn it on in Policy to screen the payment recipient against verified address records and current USDC restrictions on Base and Solana. A match or an unavailable check denies in enforce mode. Observe mode records what would be denied without blocking it.
An explicit payee allowlist entry on the same network overrides only this optional check. It does not override the manual denylist, spending limits, an injection review or a token issuer's on-chain freeze. A Solana token account can be frozen without every asset held by its owner being restricted.
On Payees, select a network and enter the recipient wallet address to check its USDC restriction state. For Solana, use the wallet owner, not a token-account address. The lookup checks that owner's associated USDC account. The lookup requires sign-in and has a per-account rate limit; there is no bulk list or download. A no-match result means nothing was found within the checked coverage, not that a wallet is safe or legally cleared. Missing or expired data is reported as unavailable, not clear.
What the agent may buy
The resources the agent is meant to pay for, one https URL each, path only. A URL covers itself and anything under it, so https://merchant.example/ covers a whole seller, and a payment's own query string does not change what it is for. A payment for a resource under none of them waits for a person, whatever page or tool talked the agent into it. An empty list allows any resource, which is what a new key starts with.
How much and how often
The per-payment limit and the daily cap are hard: over either one, the payment is denied. The hourly count and the review timeout are softer: over the hourly count a payment goes to a person, and the timeout is how long that person has before the review expires and the payment is refused. Over the hold threshold a payment waits for a person, whatever the payee; it sits under the per-payment limit, and 0 turns it off. The daily cap counts allowed, approved, and waiting payments since midnight UTC, and so does the hourly count, which reads the sixty minutes behind the payment rather than the hour on the clock. A payment waiting for a person reserves its share until it is answered or expires. Both count one key on one network. Each selected network has its own budget: with Base and Solana Mainnet selected, a 1 USDC daily cap permits up to 2 USDC total in enforce mode, 1 USDC on each. Testnet activity is counted separately.
Approving a pending review checks today's reservations against the daily cap saved with that request. Editing the cap applies to new decisions. To use a changed cap, deny the pending request and start a new payment attempt.
Where it runs and what it read
A payment on another chain, or in another token, is denied. So is a contract call that touches a denylisted address or selector, and refusing approve refuses increaseAllowance too. Beyond the denylist, the rule reads six calls: approve, increaseAllowance, setApprovalForAll, transferOwnership, transfer, and transferFrom. A transfer is judged as a payment to its recipient and an approval as a payment to its spender, so the payee and amount rules apply to both. A grant to a spender the allowlist does not name is a first payment to it, so the auto-allow amount applies (the default of 0 sends every first grant to review). The rule itself refuses an approval for an unlimited amount, an approval for every token in a collection, a transfer of contract ownership, and calldata that carries one of these selectors but does not decode. A call with any other selector is not decoded. Its payee is the target contract; the guard cannot check a recipient or token amount hidden in that calldata. Allowlisting the target can let those opaque calls pass, so verify what they do before allowing the contract. Raw calls carrying native currency are refused.
Content settings belong to the deployment's administrators. The check reads the pages fetched through the SDK, the seller's 402 terms through the proxy, or the text passed to the tool, and when it returns a completed block, the payment is denied. An unfinished check needs a person. A clear result cannot rescue a payment the rules denied.
Reading the policy
GET /api/v1/policy returns the whole thing, payee lists included, as the guard will apply it to your next payment. The dashboard shows the same values, and every decision stores a copy of the policy it was judged against, so an old decision still explains itself after you change the policy.
{
"allowedNetworks": ["eip155:84532"],
"allowedAssets": [
{
"network": "eip155:84532",
"address": "0x036CbD53842c5426634e7929541eC2318f3dCF7e"
}
],
"allowedPayees": [
{
"network": "eip155:84532",
"address": "0x1111111111111111111111111111111111111111"
}
],
"deniedPayees": [],
"blocklistEnabled": false,
"allowedResources": [],
"perTxLimitAtomic": "100000",
"dailyCapAtomic": "1000000",
"holdOverAtomic": "0",
"velocityPerHour": 20,
"autoAllowFirstTimeUnderAtomic": "0",
"contractDenylist": {
"selectors": [],
"addresses": []
},
"reviewTimeoutSeconds": 120
}The Policy page in the dashboard edits the per-payment limit, the hold threshold, the daily cap, the auto-allow amount, the payments per hour, the review timeout, what the agent may buy, optional wallet screening, and the contract calls it can refuse outright. A saved change applies to the next decision. Networks are ticked, one or more of Base Sepolia, Base, Solana Devnet, and Solana Mainnet. Saving Base or Solana Mainnet means the agent's payments move real USDC; the guard still holds no funds and signs nothing. Payees are added and removed on the Payees page, and approving a review can add the payee in the same click. What each rule does with these values is on the reason codes page.