Skip to main content
An open smoked-glass book carries a soft sage path toward a finite tray of silver pellets, with a separate platinum reserve behind it. Reins mark in the corner. An instruction such as “never spend more than 10 XRP” is not an account permission. If an agent has access to a larger funded account, the instruction and the available authority are different things. Reins starts with the account boundary: keep owner funds separate, give the agent an allowance account to act for, and inspect everything that key can reach. This article walks through recorded evidence and a reproducible verification path. Reins is a testnet alpha. No external security review has been completed.

​
Start with a deliberately compromised agent

In the recorded October 21, 2026 experiment, a script obeyed an injected spending instruction. No language model was called. The experiment asks what the ledger accepts when the agent tries to spend, not whether a model resists the instruction. The selected receipts show three events:
  1. An oversized Payment for 199.999952 XRP returned tecUNFUNDED_PAYMENT.
  2. A Payment for 10 XRP returned tesSUCCESS, with 10 XRP delivered.
  3. An owner-signed DelegateSet with an empty permission list returned tesSUCCESS.
The second event matters as much as the first. The reachable funds could still be sent to the attacker’s chosen destination. This was a spending boundary, not a judgment that the payment was appropriate. Failed transactions can also incur fees. The evidence page contains the selected receipts and their scope. The records were checked again on October 26, 2026 using read-only transaction queries. That check did not create new accounts, sign a payment, or run a new attack experiment.

​
Verify the evidence without a wallet

You need Node.js and curl. Download the standalone verifier, inspect its source, then run it:
After reading the downloaded file:
The verifier reads existing transactions from the configured XRPL testnet RPC. It checks validated status, transaction hashes, types, relevant fields and engine results, including the delivered amount for the successful payment. It contains no signing or transaction-submission operation. Expected output while those records remain available:
Testnet history may disappear after resets. An unavailable record, network error or mismatched field is an unverified result. It must not be treated as a pass. These selected receipts do not prove every property of an account configuration or replace a security review.

​
Identify who enforces each boundary

The owner holds the vault keys. The vault does not delegate to the agent. A separate allowance account delegates only the configured transaction types. The agent identity holds its own fee float. The XRP Ledger evaluates account funding, delegated transaction types, and the amount and expiration of refill Checks. Delegating Payment does not specify a maximum amount for each payment or an approved destination. The Reins toolkit checks supported transactions, computes worst-case outflow, runs simulation, and explains decoded fields. Its prepared-transaction path binds submission to the transaction that was reviewed. Those checks depend on using the toolkit path; they are not independent ledger restrictions on a compromised agent. The independent policy co-signer for per-payment caps, payee rules and rolling velocity is planned. It has not shipped. An optional multisig account topology does not by itself provide that policy service. When evaluating exposure, inspect the allowance’s spendable balance, reserves, fees, outstanding objects, reachable refills and the agent fee float. A YAML amount is not a native rolling daily spending cap. budget.period controls refill Check lifetime.

​
Run your own testnet policy lifecycle

The following workflow uses the published CLI version 0.0.2 and Node.js 22.12 or later. It is separate from verifying the recorded receipts above. Account initialization uses the faucet and can submit testnet transactions; apply and revoke also submit transactions. Use a fresh project directory and fresh testnet accounts. Never reuse a production wallet seed.
Initialization writes reins.yaml and a private local .reins/testnet-wallets.json file containing plaintext testnet seeds. Keep that wallet file out of Git, uploads and the agent process. The generated policy includes Payment, CheckCash and EscrowFinish; review whether each delegated type is needed before applying it. Read the proposed transactions, signing roles, enforcement descriptions and limitations. Planning does not submit transactions. After reviewing the configuration:
Setup spans multiple transactions. A failure can leave earlier steps completed. Inspect reported results and live state before retrying. Verification reads the ledger and does not require the owner wallet file. When the experiment is finished, revoke as the owner:
Read the final verification report. Submission alone does not establish that revocation succeeded.

​
Make setup failures actionable

A local follow-up to 0.0.2 addresses friction in this first-run experience. Previously, a missing policy produced a raw ENOENT error, and init --out config/reins.yaml failed if the config directory did not exist. The updated source creates missing policy parent directories, explains how to recover from a missing policy, and adds guidance when starter addresses have not been filled. It preserves the original validation findings and still refuses to overwrite an existing policy unless --force is supplied. These changes are unreleased source changes, not behavior claimed for npx reinskit@0.0.2. The build and 122 offline tests passed on October 26, 2026. No new ledger transactions were needed to verify these CLI changes.

​
Connect the agent only after inspecting the boundary

Start the MCP server without a signing key. It can inspect, explain and prepare transactions, but cannot sign and submit them in that configuration. Keep the owner wallet file outside the MCP configuration. The useful question is not only whether an agent followed its instructions. It is what the agent’s authority allowed after those instructions failed. The account model, reachable funds and enforcement layer need to be inspected together. Continue with the quickstart, account model, and enforcement boundary.