Security

Security (v0.14.1)

The skill splits trading into two programs with a hard boundary: xrpl-trade proposes (never sees the seed, cannot submit); xrpl-sign is the only signer and requires explicit human approval of the exact proposal hash. Fresh installs are read-only by default — signing stays refused until the typed xrpl-trade live ceremony.

v0.14.1 audit fixes

A third-party audit of v0.14.0 raised seven findings; all are fixed with regression tests:

• Spend-state recovery — corrupt state raises StateError (fails closed, no silent reset). xrpl-sign recover-state rebuilds from the audit log: latest outcome per transaction wins, failed transactions keep only their consumed fee. Untrustworthy rebuilds write blocked state until the operator reconciles and attests (--attest, audit-logged). The signer releases unbound reservations on every failure path.
• Approval-display sanitization — ANSI/OSC escapes, C0/C1 controls, DEL, bidi/format characters, and Unicode separators in untrusted fields render as visible escapes. They can neither act on the terminal nor hide invisibly.
• Strict policy validation — unknown keys, wrong types, truthy strings ("false" is truthy), non-finite values, invalid addresses/tags/ranges, and unsupported transaction types are rejected before the policy is used. spend_limits is required.
• Exact proposal hashes — --approve requires exactly 64 hex characters matching the verified envelope hash. Prefixes are inspection-only and can never select a signing target.
• Forensic ledger ranges — history scans pin one validated integer ledger; no bare "validated" for historical reads.
• Pinned NFT verification — NFT reads pin to one validated ledger; the report shows seller (current owner) vs issuer (minter) separately.
• Delivered-value flows — forensic flows count only tesSUCCESS transactions' meta.delivered_amount, never requested amounts.

Standing safeguards

• Exact operation binding: proposals bind the canonical transaction, account, network, action, profile fingerprint, and policy digest. Signing requires the full 64-character proposal hash; profile, policy, or credential-context changes invalidate the approval.
• Read-only by default: no CLI flag or environment variable skips the typed live ceremony. xrpl-sign --approve refuses (audit-logged) while read-only.
• Ledger authorization: the signer checks a validated ledger snapshot for an enabled master key or authorized RegularKey.
• Spend accounting: reservations are locked while outcomes are ambiguous. Only validated results settle them.
• Output and local files: external display text is sanitized; protected files are checked for owner-only permissions.

Honest boundaries

• 0600 permissions protect against other local users, not software running under the same UID. The skill is hardened for a trusted-operator agent, not for adversarial same-user processes.
• The CLI's --approve flag is an assertion; the human-approval ceremony lives in the agent runtime (Muse), not in the CLI alone.
• Forensic commands (flow, trace, nft-trail, token-trail) report on-ledger facts with LINK:/NOTE: discipline — they never claim common ownership without control overlap.

Recovery

Never delete damaged state to get the signer running. xrpl-sign recover-state rebuilds from the audit log, keeps a backup of the corrupt file, and refuses to omit known liabilities. If the rebuild can't be trusted, signing stays blocked until you reconcile and attest.