> For the complete documentation index, see [llms.txt](https://docs.useshadowpay.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useshadowpay.com/agents-and-automation/spend-policies.md).

# Spend Policies

A spend policy is the set of rules a parent account defines for an agent it controls. It's the mechanism that lets you give an agent real spending power without giving up control over what it can do with it.

***

## What a spend policy defines

| Rule                        | Description                                                                                   |
| --------------------------- | --------------------------------------------------------------------------------------------- |
| Daily limit                 | Maximum total USDC the agent can spend in a rolling 24-hour window                            |
| Per-transaction limit       | Maximum amount for any single transfer                                                        |
| Allowed recipients          | An allowlist of addresses, handles, or domains (for x402 payments) the agent can pay          |
| Asset restrictions          | Which assets the agent is permitted to spend (USDC only, by default)                          |
| Time windows                | Hours or days during which the agent is permitted to transact at all                          |
| Human-in-the-loop threshold | A dollar amount above which a transaction requires explicit human approval before it executes |

***

## Setting a policy

Spend policies are configured from the parent account's dashboard under **Agents → \[agent name] → Spend Policy**, or programmatically via the API. See [Agents & Spend Policies](/api-reference/agents-and-spend-policies.md).

Policies can be updated at any time. Changes apply to new transactions going forward and do not retroactively affect anything already settled.

***

## Enforcement

Policy checks happen before a transaction is signed, not as a post-hoc review. The agent's signing flow evaluates the proposed transaction against its current policy locally; if it fails any check, the transaction is never constructed or submitted. There's no path for an agent to attempt a transaction outside its policy and have it silently blocked on-chain instead. It simply doesn't get signed.

***

## Human-in-the-loop approval

For transactions above the configured threshold, the agent constructs and holds the transaction, then triggers a push notification to the parent account. The human reviews the amount, recipient, and any attached context, then approves or rejects.

* Approved transactions are signed and submitted immediately
* Rejected transactions are discarded. Nothing is submitted, and no funds move
* Unactioned requests expire after a configurable window (default 24 hours) and are automatically rejected

This gives you a dial between full autonomy and full oversight. Set the threshold to zero for an agent you want to review every payment from, or set it high for one you trust to run unattended for routine, low-value transactions.

***

## Example policy

```json
{
  "daily_limit_usdc": 500.00,
  "per_transaction_limit_usdc": 50.00,
  "allowed_recipients": ["api.market", "*.anthropic.com", "@yourname"],
  "assets": ["USDC"],
  "active_hours": "00:00-23:59",
  "hitl_threshold_usdc": 25.00
}
```

Under this policy, the agent can spend freely on calls to `api.market` and `anthropic.com` domains up to $25 per transaction without approval. Anything above $25, or any recipient outside the allowlist, requires a human decision or is rejected outright.

***

## Next

* [x402 Payments](/agents-and-automation/x402-payments.md)
* [Webhooks & Events](/agents-and-automation/webhooks-and-events.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.useshadowpay.com/agents-and-automation/spend-policies.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.