> For the complete documentation index, see [llms.txt](https://docs.useglade.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useglade.org/agents/spending-rules.md).

# Spending rules

Each agent answers to its parent account through a spend policy. Having a policy is why you can trust software with real money: the agent can genuinely spend, and none of your own authority over the account is given up in the process.

## Rules you can set

| Rule                  | Effect                                                                                                                |
| --------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Daily limit           | The most USDG the agent may spend in any rolling 24-hour window.                                                      |
| Per-transaction limit | The largest amount allowed in one payment.                                                                            |
| Allowed recipients    | The addresses, handles or domains (for x402) the agent may pay. Anything else is off limits.                          |
| Asset restrictions    | Which assets the agent may spend. Only USDG is allowed unless you change it; bridged USDC and ETH can be switched on. |
| Time windows          | The hours or days when the agent is allowed to transact.                                                              |
| Approval threshold    | An amount above which a person must explicitly approve the payment before it goes through.                            |

## Setting up a policy

In the parent dashboard, open **Agents → \[agent name] → Spend Policy**. To do it programmatically, use the endpoints in the [agents API](/api-reference/agents-api.md).

Policies can be changed whenever you like. A change only affects transactions made after it is saved. Payments that have already settled stay as they are.

## How rules are enforced

Most spend controls look at a payment after it has been made. Glade checks it before a signature even exists. As the agent signs, it compares the proposed payment with the policy in effect at that moment. If even one rule is broken, the transaction is never built and nothing reaches the chain. So you will not see an agent send an out-of-policy payment that gets quietly rejected later. That payment is simply never signed.

## When a payment needs approval

If a payment is larger than your threshold, the agent prepares the transaction, puts it on hold and notifies the parent account. Someone looks over the amount, who it is going to and any context the agent supplied, then approves or declines it.

| Outcome     | What happens                                                                                      |
| ----------- | ------------------------------------------------------------------------------------------------- |
| Approved    | The payment is signed and sent immediately.                                                       |
| Declined    | The payment is discarded. Nothing is submitted and no money moves.                                |
| No response | The request expires after a configurable period (24 hours by default) and is treated as declined. |

The threshold sets how much freedom the agent has. Put it at zero and you will review every single payment. Set it high for an agent you are comfortable leaving alone with routine, small purchases.

## A sample policy


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.useglade.org/agents/spending-rules.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.