> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reinskit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Know what enforces each restriction

> Distinguish XRP Ledger rules, Reins toolkit checks, and the planned policy co-signer so you can assess an agent allowance without overstating protection.

A restriction matters only if you know who enforces it. Reins separates ledger rules, toolkit checks, and rules that require a future independent policy co-signer.

## Enforced by the XRP Ledger

The ledger evaluates configured account rules independently of the agent and the Reins process.

* The vault does not delegate authority to the agent.
* The allowance account delegates the configured transaction types.
* The allowance's balance constraints bound spending from that account.
* Refill Checks have a maximum amount and an expiration.

The practical loss boundary depends on spendable balances, reserves, fees, outstanding objects, and funds made reachable through refills. A YAML budget alone does not limit the amount of every delegated payment.

## Checked by the Reins toolkit

The toolkit checks supported transactions before signing, computes worst-case outflow, simulates them, and creates explanations from decoded fields. The prepared-transaction flow binds submission to the transaction that was reviewed.

These checks depend on using the toolkit. An agent holding a full signing key can attempt transactions through another path. Do not describe toolkit-only checks as ledger rules.

Simulation is a preview against ledger state. It does not promise later inclusion or prove that a payment is appropriate.

## Planned independent policy co-signer

Per-payment caps, approved outgoing payees, and rolling daily velocity require an independent policy co-signer. That policy service is planned and has not shipped.

The alpha validates and reports the `limits` section of a policy. Accepting that section does not enforce it. The optional hardened account topology is distinct from the planned policy service.

## Read reports with this distinction

CLI and source reports label ledger enforcement `L`, future co-signer enforcement `C`, and toolkit checks `T`. These labels identify the enforcer; they are not interchangeable protection levels.

| Restriction or check | Enforcer | Current state |
| - | - | - |
| Delegated transaction types | XRP Ledger | Configured by the policy flow |
| Account balance constraints and capped refill Checks | XRP Ledger | Part of the funding boundary |
| Transaction checks, explanations, and simulation | Reins toolkit | Available in the alpha |
| Per-payment cap, approved payees, rolling daily velocity | Independent policy co-signer | Planned, not enforced |

## Remaining risks

An attacker can still receive payments inside the reachable allowance. Owner-key compromise falls outside this boundary. Revocation needs live submission and confirmation. Alpha defects can affect both setup and transaction handling.

Use small testnet allowances and verify live configuration. An external security review remains a gate before mainnet use.


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