> ## Documentation Index
> Fetch the complete documentation index at: https://a-identity.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Bounded Authority

> A spend limit you set, enforced three independent ways, including an on-chain revert.

Identity answers *who* an agent is. **Bounded authority** answers *what it may do
with money*. In A-Identity, a limit you set on an agent is not a suggestion. It is
enforced in **three independent ways**, so no single layer failing can move value it
shouldn't. A human in the tower sets the policy and approves anything above it.

![Three cards: server pre-check labelled advisory, on-chain policy vault labelled source of truth, and Circle Agent Wallet labelled hosted screening](https://mintcdn.com/a-identity/6WJeNsr11cqAySNG/images/architecture-enforcement.png?fit=max\&auto=format\&n=6WJeNsr11cqAySNG\&q=85\&s=4c750f9e5d9c482677d668af5f622aff)

## Three independent enforcement layers

**1. Server policy engine (pre-check)**

The fast first gate: daily cap, auto-approve ceiling, payee allowlist, freeze, and
the human-approval requirement. Resets at 00:00 UTC. This is a check, not the
source of truth: it is the fallback, not the guarantee.

**2. On-chain policy vault (the source of truth)**

Each agent can get its own `AgentSpendPolicy` contract on Arc that **holds the USDC
and enforces the same policy on-chain**. An over-limit `pay()` **reverts on Arc**
with a typed error you can read on the explorer, not a server "no". The human
owner can override an approved payment, adjust limits, freeze, or withdraw.

**3. Circle Agent Wallet (hosted screening)**

Optionally, the agent's USDC lives in a Circle Developer-Controlled Wallet whose
hosted policy engine **screens every transfer** at the wallet layer (sanctions,
address allow/block, freeze). A screening denial is authoritative.

At settlement, `executeInstruction` routes a payment **vault, then Circle, then direct**, each
additive with a fallback, so one layer hitting an infra error never fabricates a
success, and a real policy rejection always stops the payment.

## The money shot: an on-chain revert

The difference between a demo and a product is where the "no" comes from. Here it
comes from the chain:

```solidity theme={null}
function pay(address to, uint256 amount) external onlyOperator {
    if (frozen) revert IsFrozen();
    if (allowlistEnabled && !allowed[to]) revert PayeeNotAllowed();
    if (autoApproveMax != 0 && amount > autoApproveMax) revert AboveAutoApprove();
    uint256 d = today();
    if (dailyCap != 0 && spentOnDay[d] + amount > dailyCap) revert DailyCapExceeded();
    spentOnDay[d] += amount;
    if (!usdc.transfer(to, amount)) revert TransferFailed();
    emit Paid(to, amount, d, false);
}
```

An agent that tries to overspend doesn't get a server error page. Its transaction
**reverts on Arc**, verifiably, for anyone to check.

> [!NOTE]
>
> **Owner vs operator.** The vault's `owner` is a human wallet (sets policy, overrides,
> freezes, withdraws). The `operator` is the agent's signer (may only `pay` within
> policy). They are genuinely separate keys, and the agent can never change its own limits.

## What each layer actually enforces

| Layer | Enforces | Trust model |
| - | - | - |
| Server policy engine | Cap, ceiling, allowlist, freeze, approval gate | Fast pre-check / fallback |
| On-chain vault | The same policy, on Arc, where an over-limit `pay()` reverts | Trustless source of truth |
| Circle Agent Wallet | Transaction screening (sanctions / allow-block / freeze) | Hosted wallet-layer control |

> **[See it on the explorer](/chains/arc)**
>
> Provision a vault from the **Permissions** screen, then watch an over-limit payment
> revert on Arc testnet.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.