> ## 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.

# What can an agent spend after a prompt injection?

> Inspect a recorded XRPL testnet experiment, verify its receipts without a wallet, and follow the Reins owner policy lifecycle.

![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.](https://mintcdn.com/reins-b89ee2cb/SWZ1XReuc4UvqUiL/images/social/walkthrough-announcement-20261026.png?fit=max\&auto=format\&n=SWZ1XReuc4UvqUiL\&q=85\&s=54be4004ac551ce435ac4f5736e38667)

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](https://www.reinskit.com/proof/) 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:

```bash theme={"dark"}
mkdir reins-evidence
cd reins-evidence
curl --fail --silent --show-error --proto '=https' \
  https://www.reinskit.com/proof/verify-evidence.mjs \
  --output verify-evidence.mjs
```

After reading the downloaded file:

```bash theme={"dark"}
node verify-evidence.mjs
```

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:

```text theme={"dark"}
PASS over-budget: validated Payment, tecUNFUNDED_PAYMENT, ledger 21707458
PASS within-budget: validated Payment, tesSUCCESS, ledger 21707465
PASS owner-revocation: validated DelegateSet, tesSUCCESS, ledger 21707467
Read-only check complete. No ledger transactions submitted.
```

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.

```bash theme={"dark"}
mkdir reins-testnet
cd reins-testnet
npx reinskit@0.0.2 --version
npx reinskit@0.0.2 init --testnet-accounts
npx reinskit@0.0.2 plan reins.yaml
```

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:

```bash theme={"dark"}
npx reinskit@0.0.2 apply reins.yaml --wallets .reins/testnet-wallets.json
npx reinskit@0.0.2 verify reins.yaml
```

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:

```bash theme={"dark"}
npx reinskit@0.0.2 revoke reins.yaml --wallets .reins/testnet-wallets.json
```

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](https://docs.reinskit.com/guides/mcp.md) 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](https://docs.reinskit.com/quickstart.md), [account model](https://docs.reinskit.com/concepts/accounts.md), and [enforcement boundary](https://docs.reinskit.com/concepts/enforcement.md).


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