This document is a comprehensive threat model: the trust boundaries the signing pipeline crosses, the defense-in-depth layers that catch attacks across them, and the residual risk explicitly named where coverage stops. It documents what you are trusting when you let an AI agent prepare transactions against your Ledger device.

For the product overview, install instructions, and tool reference, see the main README.

VaultPilot assumes the AI agent can be compromised, the MCP server can be compromised, and your host computer can be compromised. Only your Ledger hardware is trusted. Every transaction is cryptographically bound across every layer so that tampering at any point — a swapped recipient, a rewritten swap route, a smuggled approval — produces a visible mismatch on your Ledger screen, giving you the chance to reject before anything is signed.

The compromise model for the agent covers both adversarial threat actors (prompt injection, rogue subagent in a delegation chain, malicious skill, deliberately rogue agent) and non-adversarial model-error cases: a safety-tuned, non-injected agent can still produce harmful output through hallucinated addresses or chain IDs, stale knowledge of deprecated / upgraded contracts, post-training-cutoff protocols missing entirely, long-context attention drift across multi-step flows, capitulation under user pressure (the user insists, the agent stops pushing back), cross-tool reasoning gaps (e.g. treating an unwrap as if it were a swap), numeric mistakes (off-by-decimal, wrong-chain decimals), and tool-name confusion (calling the wrong prepare_* for the user's stated intent). For threat-modeling purposes these are functionally equivalent to a narrow agent compromise: the agent emits bytes / advice / tool args that do not match user intent, regardless of whether an adversary is in the loop. The same defense-in-depth layers apply (PREPARE RECEIPT verbatim args + on-device Ledger display + skill invariants); the user-facing implication is that a benign-looking, high-confidence response should not be trusted any more than an explicitly adversarial one — the trust anchor is the Ledger screen, not the model's confidence.

In practice: the agent relays a hash it computed locally, the MCP relays the bytes it intends to broadcast, and the Ledger re-derives its own hash from the bytes it actually receives. You compare the two on the device's own screen — the one display in the pipeline that no software on the host can forge. No layer in between can fake a match it doesn't have.

The signing pipeline crosses several independent trust boundaries, each of which can be compromised in isolation:

user-intent ──► agent ──► MCP server ──► WalletConnect / USB-HID ──► Ledger Live / host ──► Ledger device

The Ledger device is the only component whose display the user sees directly (not filtered through the agent) and which cannot be software-compromised at the host level. Everything else can fail. VaultPilot uses defense in depth so that single-layer compromises are caught by at least one independent cross-check, and coordinated multi-layer attacks are either caught or explicitly documented as residual risk.

Two of the anti-compromised-MCP checks below — agent-side ABI decode and the pair-consistency pre-sign hash recomputation — run automatically at preview_send time and report their results in a CHECKS PERFORMED block before the user replies "send". The agent is instructed to run them unprompted; the user does not consent check-by-check. The second-LLM verification is the one remaining opt-in, because it requires physical user action (paste into another LLM). The swiss-knife decoder URL stays embedded in the VERIFY-BEFORE-SIGNING block as a suggested manual fallback when the agent's built-in ABI knowledge is low-confidence on the target selector.

The table above is chain-agnostic. Not every defense applies to every chain — WC session-topic is EVM-only; previewToken + userDecision gates only the EVM preview-send step; TRON uses USB-HID transport and the Ledger TRON app clear-signs every supported action, so some EVM-specific machinery has no equivalent on TRON and is deliberately absent. The matrix below resolves per-chain presence, with — plus a footnote reason when a defense is intentionally not present on a chain.

TRON's surface is deliberately narrower than EVM's or Solana's because the Ledger TRON app clear-signs every supported action and the transport is direct USB HID (not WalletConnect). The following machinery has no TRON equivalent and will not be added; each is a design decision, not an oversight.

• No agent-task CHECKS PERFORMED block. Every supported TRON action clear-signs on-device — the user sees action type + decoded args on the Ledger screen directly. Adding server-authored hash-match or calldata-decode directives would train users to compare against values the device never shows, reinforcing rubber-stamp habits rather than preventing them.
• No LEDGER BLIND-SIGN HASH block. Same reason — there is no blind-sign hash channel on TRON because no supported action blind-signs.
• No WalletConnect session-topic cross-check. TRON signing goes over direct USB HID via @ledgerhq/hw-app-trx; there is no WC session to impersonate.
• No previewToken + userDecision preview-step gate. TRON has no preview step — prepare_tron_* produces the signable artifact in one call; send_transaction forwards it directly. The gate exists on EVM to catch accidental preview-step collapse, which is structurally impossible here.

• Prompt injection / malicious skill / compromised subagent (narrow): PREPARE RECEIPT surfaces the args that hit MCP, bypassing the agent's natural-language retelling. For native sends, the Ledger device's To / Value display backstops even if the receipt is dropped. For contract calls (swaps, supplies, approvals) the calldata remains unverifiable on-device in blind-sign — the agent's auto-run ABI decode at preview_send is the next line of defense, with the swiss-knife URL as a manual fallback when the agent's ABI knowledge is low-confidence.

• Fully-corrupted agent that coordinates on BOTH arg manipulation AND output filtering: No software-only defense. The user's entire view flows through the agent; there is no non-agent display channel for calldata in blind-sign mode. Documented as residual risk — this threat is only fully closed by a non-agent display channel (a hardware wallet with full clear-signing for the target calldata), which is not available for most contract calls today.

• Non-adversarial model error (no attacker, no injection): Functionally equivalent to a narrow agent compromise — the agent emits bytes / advice / args that do not match user intent without an attacker in the loop. Sub-classes and what catches each:

  • Hallucinated address (recipient, contract, validator, spender) — PREPARE RECEIPT surfaces the verbatim arg; the Ledger device displays To directly for native sends; Inv #1.a outer dispatch-target allowlist refuses non-canonical contracts on supported actions; Inv #15 mandates a non-MCP authority for durable bindings (validator vote pubkey, MarginFi bank, LP tokenId, multisig xpub).
  • Hallucinated chain ID / wrong-chain selection — Inv #2.5 chain-must-be-explicit refuses any prepare_* until the user names exactly ONE chain by canonical name; Inv #2 chainId assertion compares prepared bytes against the user-named chain.
  • Stale knowledge of deprecated / upgraded contracts — Inv #1.a allowlist is regression-tested against src/config/contracts.ts (single source of truth); a model relying on a deprecated proxy address mismatches the canonical entry and refuses.
  • Post-training-cutoff protocol entirely missing — the agent doesn't know what it doesn't know. The defense is structural: VaultPilot only ships prepare_* for protocols with built-in handlers, so a missing protocol surfaces as "no tool for this" rather than a free-form prepare_custom_call with hallucinated calldata. When the user routes through prepare_custom_call anyway, the acknowledgeNonProtocolTarget flag is the explicit user-acknowledgment that they're operating outside the protocol-aware safety net.
  • Long-context attention drift across multi-step flows — previewToken + userDecision schema gate forces the agent to re-read the prepared tuple at send_transaction time; the Ledger device display is the final attention reset because it shows decoded values regardless of how distracted the agent's chat output became.
  • Capitulation under user pressure ("just send it, I trust you") — Skill v0.6.0+ §16 (EIP-7702 refuse-all), Inv #14 (full enumeration verbatim), are fail-safe-default refusals the agent cannot drop in response to pushback (Inv #12.5 is not one of them — the second-LLM check is a recommendation the user is free to decline). The skill rules are written as DO NOT SIGN halts, not "consider whether to proceed" — the imperative shape is intentional cover for the user-pressure case.
  • Cross-tool reasoning gaps (calling prepare_swap for an ETH→WETH wrap; prepare_native_send for what should be a contract call) — PREPARE RECEIPT surfaces the tool name + args verbatim; the user reads the tool name in chat and catches mismatches before send. Inv #1.a backstops by refusing non-canonical outer to for the named action class.
  • Numeric mistakes (off-by-decimal, wrong-chain decimals, USDC's 6 vs ETH's 18) — PREPARE RECEIPT surfaces the exact value / amount; the Ledger device displays Value for native sends with full decimal expansion; agent-side ABI decode (CHECK 1) at preview_send re-decodes the calldata amount and surfaces it in CHECKS PERFORMED independently of the agent's prose summary.
  • Tool-name confusion (calling prepare_aave_supply when user said "borrow"; prepare_lido_unwrap for an unstake) — PREPARE RECEIPT names the tool. Inv #1.a + the canonical-dispatch table refuse when the tool's outer to doesn't match the action the bytes actually perform.

  None of these sub-classes require an adversary; the same defense-in-depth layers that catch narrow injection catch them. The user-facing implication is that a benign-looking, high-confidence agent response should not be trusted any more than an explicitly suspicious one — the Ledger screen and the skill's cryptographic-integrity invariants are the trust anchors, not the model's confidence.

• Compromised MCP (lies about hash, swaps bytes at send-time): LEDGER BLIND-SIGN HASH catches bytes-tampering between MCP and device — the device recomputes from received bytes, and the user matches the agent-relayed value against the device-displayed one. The agent's auto-run pair-consistency hash recompute (reported in CHECKS PERFORMED) gives a cooperating agent a first-line check before the device is involved.

• Compromised Ledger Live or WalletConnect relay (middle-layer MITM): LEDGER BLIND-SIGN HASH — the device is the source of truth; any substitution between MCP and the device produces a divergent on-device hash.

• WalletConnect peer impersonation (adversary pairs with the MCP while the user believes they paired Ledger Live): WC session-topic cross-check — the user verifies in Ledger Live → Settings → Connected Apps that a session exists whose topic matches the one the MCP holds. The peer's self-reported name/URL alone is not a trusted identity (any peer can claim "Ledger Wallet @ wc.apps.ledger.com").

• Agent accidentally skips the CHECKS PERFORMED report at preview time: previewToken (server-minted at preview_send, stashed on the pin) + userDecision: "send" (schema literal) on send_transaction. Both required on the EVM path; missing/mismatched values cause a clear-error refusal naming the missing arg. A fully-hostile agent can still forge userDecision after a legitimate preview_send, so this is a careless-mistake backstop, not a coordinated-lying defense.

• "Edit gas" in Ledger Live: Hash mismatch is expected (the user changed a hashed field). The in-block wording explicitly allows "accept the tradeoff without the hash-match guarantee" — user owns the choice; not a bug.

• Recipient substitution via stale clear-signed approval (rogue MCP, bytes-valid): Inv #1.a outer dispatch-target allowlist refuses on any prepare_* whose outer to is not the canonical contract for the named action. Catches the "valid selector + malicious dispatch target" class where a forgotten approval to a lookalike contract would otherwise let a redirect drain the wallet.

• Cross-chain ambiguity / CREATE2 same-address sweeper: Inv #2.5 chain-must-be-explicit refuses to call any prepare_* until the user has named exactly one chain by canonical name. The rule is positive-naming-required, not phishing-phrase blacklist — robust to paraphrase.

• Bridge facet recipient swap (LiFi outer-valid, facet-malicious): Inv #6b Tier-1 facet decoder cross-checks decodedFinalRecipient == userSuppliedRecipient for Wormhole / Mayan / NEAR Intents / Across V3. Tier-2 (deBridge / Stargate composeMsg / Hop / Symbiosis) falls back to a recommended second-LLM check (Inv #12.5) until per-bridge decoders ship.

• Reverse-revoke / set-level lie (rogue agent picks the wrong row): Inv #14 mandates verbatim enumeration of get_token_allowances rows; the user picks which row to revoke; Inv #12.5 recommends a second-LLM check. MCP-side companion is a [SET-LEVEL ENUMERATION] block whose absence is an Inv #4 compromise signal.

• Durable-binding selection-layer attack (validator / SR / Comet / marketId / bank / ATA / tokenId / xpub): Inv #15 mandates the agent source the candidate identifier from a non-MCP authority, surface verbatim with provenance, and byte-equality-check against the prepared bytes. Hardcoded mechanical rules for unambiguous classes (LP NFT ownerOf, BTC xpub paste, Solana ATA derivation, Compound + Morpho via Inv #1.a); generic "use a non-MCP authority" rule for multi-equivalent classes.

• Free-form message drainer-pattern phishing (sign_message_btc / sign_message_ltc): Skill v0.6.0 §8 hardening adds a SHA-256 byte fingerprint preview alongside the verbatim string + outright refusal on drainer template phrases (I authorize, Granting full custody, I consent to) + refusal when the message embeds an EVM/BTC/LTC address that is not the signing wallet and not in the user's saved contacts.

• EIP-7702 setCode (forward-looking): Skill §16 refuses 7702 setCode unconditionally until skill v9 ships an implementation allowlist (paired with the MCP-side prepare_eip7702_authorization builder, tracked at #481). The MCP today does not expose a 7702 surface — the absence of the tool is the load-bearing defense; the skill rule survives the day a builder ships.

For the compromised-MCP threat model, a cooperating agent is a real second trust boundary — it knows the user-intent args and can recompute the expected hash. For the compromised-agent threat model, MCP has no ground truth for user intent; forcing verbatim args relay (PREPARE RECEIPT) raises the tampering bar for narrow injections but does not close the gap against a coordinated attacker. Both halves of the asymmetry are enforced in code and covered by test/integration-security.test.ts.

There is a second asymmetry worth calling out: every CHECKS PERFORMED and VERIFY-BEFORE-SIGNING directive is authored by this server and emitted in tool results. The agent following them is following instructions that the MCP itself produced. A compromised MCP can silently omit those directives, and a cooperating agent with no static rule to fall back on will drop the checks. The vaultpilot-preflight Claude Code skill is the defense against this self-referential gap — it lives on the user's disk at ~/.claude/skills/vaultpilot-preflight/, its trust root is the user's own clone of the skill repo, and the MCP cannot reach it to alter or suppress its content. When the MCP detects the skill is not installed, it surfaces a warning block asking the user to install it; that warning is itself server-authored, so a compromised MCP would suppress it — meaning the install step must not be deferred. Skill v0.4.1 (skill PR #12) added Step 0 — a mandatory pre-Invariant-#1 integrity self-check that halts on hash divergence or missing MCP pin block, closing the "skill loaded but compares advisory-only" failure mode that was open prior. Skill v0.6.0 (skill PR #19) extended the agent-side invariant set to cover threat classes that bytes-level decoders structurally cannot catch (dispatch redirect, set-level lie, durable-binding selection-layer, bridge facet recipient swap, cross-chain ambiguity); see "Adversarial smoke-test (2026-04-28)" below for the full breakdown. The remaining residual — non-compliant agent that doesn't load the skill at all — is tracked at vaultpilot-mcp #379 for a server-side enforcement layer (mandatory ack tool / receipt-embedded claim / startup self-check); a parallel option is a PreToolUse hook that performs the hash recompute as host-side code, removing the agent-prose dependency entirely.

Bytes flow through several components VaultPilot does not own: the host operating system and any process with debug or kernel access, the WalletConnect relay, the SDKs that implement signer wiring (@walletconnect/sign-client, viem, @ledgerhq/hw-app-*, @ledgerhq/hw-transport-*), the USB stack, and Ledger Live (when paired). A compromised library or a host-resident threat actor can substitute bytes anywhere along this propagation path. The attack surface is real and broad.

These layers are deliberately out of scope for VaultPilot to harden directly — that responsibility lies with the upstream projects (memory-safe SDKs, signed binaries, attested host environments) and the host operator. The threat model assumes upstream hardening may fail, and the design relies on two structural properties to make substitution attacks detectable rather than preventing them in the propagation path:

• On-device clear-sign for supported actions. When the Ledger app decodes the action (native sends, ERC-20 transfer / approve, Aave / Lido / 1inch / LiFi plugins, every supported TRON action, native SOL + nonce_init / nonce_close on Solana), the user reads decoded fields directly from the device screen. Bytes substituted between the host and the device surface as wrong recipient / amount / function on a display no host process can forge.
• End-to-end hash propagation for blind-sign. For actions the device blind-signs, preview_send emits a LEDGER BLIND-SIGN HASH block carrying the EIP-1559 pre-sign keccak256 (or Solana Message Hash). The user matches this against the hash the device computes locally from the bytes it actually received. Any substitution between MCP and device produces a divergent on-device hash, and the user rejects.

Both properties anchor cryptographic integrity at the Ledger screen — the only display in the pipeline that cannot be software-compromised at the host level. The components in between remain part of the attack surface, but the design does not depend on their integrity.

The residual risk is the user not performing the on-device check (rubber-stamping the Ledger screen). This is a procedural failure, not a software defense gap. Skill v0.6.0+ §5 (final on-device match) is the agent-side prompt that makes the check explicit before signing.

VaultPilot assumes the MCP server does not fabricate read-only data. Portfolio rows, balances, prices, yield comparisons, daily-briefing deltas, market-incident narratives, tax-stance figures, ENS resolutions, protocol risk scores, and transaction history are surfaced to the agent as facts; a compromised MCP — or a rogue RPC behind it — that returns falsified read-only data to mislead the agent's advisory prose is out of scope.

This is a deliberate trust assumption, not an unexamined gap. Every proposed mitigation routes the verification channel back through the same adversary:

• MCP-side response signing is the self-attestation antipattern — a rogue MCP forges the key and the signature field at identical cost. Any field returned inside the same response it is meant to authenticate carries zero integrity weight (cf. #566 / #591 / #592).
• Skill-side cross-check — a second RPC, multi-RPC consensus, or a Chainlink read — has no transport channel except the MCP's own tools, so the corroborating read is still inside the rogue-MCP boundary.

The protection boundary is the signing path: the design prevents the user from signing the wrong transaction, anchoring cryptographic integrity at the Ledger screen (on-device clear-sign + end-to-end hash propagation, above). It does not — and structurally cannot — guarantee the integrity of read-only advisory data the agent relays in chat.

The only effective countermeasure is out-of-band verification against a third-party surface the MCP cannot intercept, and it exists only where such a surface does. For ENS resolution, resolve_ens_name / reverse_resolve_ens surface a third-party verificationUrl (app.ens.domains) the user opens in their own browser (#574); for balances and prices, the user's own block explorer or a price aggregator serves the same role. These are user-side procedural checks the server points at but cannot enforce. Tracked at #565; see also the duplicate read-layer report #669.

EVM preimage: "VaultPilot-txverify-v1:" ‖ chainId (32-byte BE) ‖ to (20 bytes) ‖ value (32-byte BE) ‖ data.

# Paste calldata, address, and chainId from the swiss-knife URL; value is shown in chat.
TAG=$(cast from-utf8 "VaultPilot-txverify-v1:")
CHAIN=$(cast to-uint256 1)         # chainId
TO=0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
VALUE=$(cast to-uint256 0)         # wei, as shown in chat
DATA=0xa9059cbb...                 # from swiss-knife ?calldata=
cast keccak $(cast concat-hex "$TAG" "$CHAIN" "$TO" "$VALUE" "$DATA")

TRON preimage: "VaultPilot-txverify-v1:tron:" ‖ rawDataHex.

This fingerprint is a server-side prepare↔send integrity tag — it is not the hash Ledger's blind-sign screen displays (those are different preimages; Ledger hashes the full EIP-1559 RLP including nonce and fees). The blind-sign-matchable hash is emitted by preview_send in a separate LEDGER BLIND-SIGN HASH block.

The table above documents as residual risk that a fully-coordinated agent compromise — where the same agent that invokes prepare_* with malicious args also filters what the user sees in chat — has no software-only defense, because the user's entire view flows through the agent.

get_verification_artifact(handle) narrows that gap. It returns a sparse artifact — {chain, chainId, from, to, value, data, payloadHash, preSignHash?} for EVM, analogous TRON shape — deliberately stripped of the server's own humanDecode, swiss-knife URL, and 4byte cross-check. Alongside the structured fields, the artifact carries a pasteableBlock string: a single self-contained paste target with explicit ===== COPY FROM THIS LINE ===== / ===== END — STOP COPYING HERE ===== markers, the instructions, and the embedded JSON payload between them. The user copies everything between the markers into a second, independent LLM session (ideally a different provider) and lets that agent decode the bytes from scratch with no shared context. If the two agents disagree on what the transaction does, the first agent was lying — abort. The from field lets the second agent auto-check in-calldata recipients (unwrapWETH9 target, bridge destination, transfer to) against the signer — mismatches get flagged; matches are silently accepted as expected self-targeted operations (swaps, unwraps, withdrawals).

The Ledger device is the fabrication anchor: a compromised first agent can't invent bytes whose preSignHash matches the hash the Ledger screen displays at sign time. The canned prompt reminds the user to compare the artifact's preSignHash against the device before tapping approve — any mismatch proves the artifact was forged mid-flight, and the tx is rejected on-device anyway.

Limits worth naming:

• Does not catch a supply-chain compromise of the MCP process itself (the bytes the server builds are still the bytes it ships).
• Does not catch a coordinated attack that simultaneously compromises both LLM providers (significantly harder than compromising one).
• Does not replace the normal VERIFY-BEFORE-SIGNING block — it is an additional tool for skeptical users on high-value or unfamiliar-contract flows.

Contact labels are stored locally per chain at ~/.vaultpilot-mcp/contacts.json and signed with the user's paired Ledger key on that chain (BIP-137 for BTC, EIP-191 for EVM in v1.0; ed25519 for Solana, TIP-191 for TRON in v1.5) over a JCS-canonicalized full-list blob that includes a monotonic version counter and the fixed domain tag VaultPilot-contact-v1:. The signing primitives are not exposed as MCP tools; only the high-level add_contact / remove_contact / list_contacts / verify_contacts surface, and each one hardwires the domain tag.

Anchor re-derivation. The anchor address per chain is captured into in-memory state on session start; subsequent reads compare disk-resident anchor to the in-memory value and refuse on mismatch (CONTACTS_ANCHOR_MISMATCH). An attacker swapping the contacts file and the pairing cache still fails because pair_ledger_* re-derives the address from the device.

Version rollback. An in-memory high-water mark per chain rejects any read whose version is less than the highest seen this session (CONTACTS_VERSION_ROLLBACK).

Resolver scope. prepare_* flows resolve labels through resolveRecipient. Abort-on-tamper is scoped to the label-resolution path only:

• Input was a label requiring contacts → tampered contacts → abort hard with CONTACTS_TAMPERED. Any send risks routing to the attacker's substituted address.
• Input was a literal address → tampered contacts → send proceeds; verification block surfaces ⚠ contacts file failed verification — recipient label not checked.
• Input was an ENS name → tampered contacts → ENS resolves independently; reverse-decoration silently skipped with the same warning.

EVM signing trade-off (path C). EVM contacts blob signing requires personal_sign over the canonicalized message. v1.0 enables personal_sign in the WC namespace at REQUIRED_NAMESPACES.eip155.methods. Once it's in the session scope, any code path with access to the live c.request(...) can issue a personal_sign — not just src/signers/contacts/evm.ts. We mitigate at the contacts-signer layer by hardwiring the VaultPilot-contact-v1: domain prefix, but a compromised MCP can still bypass our signer and call personal_sign directly. The user-side defense is the Ledger Live message-display screen: the device shows the message text on-screen for personal_sign, and the VaultPilot-contact-v1: prefix is unique enough that a phishing payload would have to either masquerade as a contacts blob (visible to the user) or sign under a different prefix (also visible). The agent-side defenses, encoded in the vaultpilot-preflight skill (v4+, Invariant #7), are: (a) refuse to proceed when the verification block carries ⚠ contacts file failed verification; (b) treat any device sign-message prompt that fires during a prepare_* / send_transaction flow (rather than during contacts CRUD or sign_message_btc/ltc) as anomalous; (c) cross-check verify_contacts({ chain }) immediately after a successful add_contact to catch the case where the MCP claimed success but the persisted blob doesn't actually verify. The contacts JSON preimage is structurally fixed and the user is not expected to read it character-by-character — the recognizable domain prefix and shape are what they verify on the device. eth_signTypedData_v4 remains intentionally excluded from the namespace.

Residual risk. The address book is a UX + tamper-evidence layer; the Ledger device screen remains the canonical recipient check, and a coordinated MCP+agent compromise can still bypass label resolution entirely. A first-run rollback before any session has read the file is undetectable. Encryption-at-rest is not provided in v1; the file is local and 0o600, but anyone with read access to the home directory can enumerate contacts. Free-form metadata (notes, tags) is stored unsigned alongside signed entries — tampering with notes will not redirect funds, but may show misleading context. Taproot (bc1p…) BTC contacts and Solana / TRON contacts are unsupported in v1.0.

sign_message_btc and sign_message_ltc produce BIP-137 signatures over user-supplied UTF-8 messages via direct USB HID to the Ledger BTC / LTC apps. Typical use is proof-of-ownership statements — "I own this address: bc1q…" — where the user wants a signature they can show a third party. The accepted input is any UTF-8 string the caller passes; no domain prefix is enforced. (The contacts-CRUD tools also produce BIP-137 signatures via the same underlying signer, but they hardwire the VaultPilot-contact-v1: prefix and sign a structurally-fixed JSON preimage — see Address book above.)

Because message bytes flow user → agent → MCP → device, a compromised agent or MCP could substitute the message text between the user's stated intent and what reaches the device. Concrete attack: the user asks the agent to sign "I own bc1q...mine", the MCP receives that string, but forwards "I authorize transfer of all funds to bc1q...attacker" to the device. The Ledger BTC / LTC apps display the full message on-screen before signing, so the user's eyeball on the device is the canonical check — but only if the user actually compares character-by-character.

The agent-side defense, encoded in the vaultpilot-preflight skill (v4+, Invariant #8), is the MESSAGE-PREVIEW block. Before invoking sign_message_btc / sign_message_ltc, the agent renders the exact UTF-8 string it is about to send to the MCP in a fenced verbatim block, lists the address being signed-for, and waits for the user's proceed. The user is instructed to verify that the previewed string matches the device-screen string character-by-character, and to treat any deviation as ✗ MESSAGE-PREVIEW MISMATCH — DO NOT SIGN. This is the same shape as PREPARE RECEIPT for transactions: a verbatim relay that raises the bar against narrow agent compromise without claiming to defend against a fully-coordinated attacker.

A second skill rule (Invariant #7) maintains an explicit allow-list of MCP tools that legitimately trigger an on-device sign-message prompt: contacts CRUD plus sign_message_btc / sign_message_ltc. Any device sign-message prompt during a prepare_* / send_transaction flow that is not triggered by one of these tools is anomalous — the agent refuses on-device and surfaces it to the user.

Skill v0.6.0 hardens Invariant #8 with three additions (closes #454):

1. Byte-fingerprint preview. Alongside the verbatim string the agent surfaces a SHA-256 hash of the exact bytes it submitted. If the Ledger BTC / LTC app shows a hash for long messages, the user matches it against the agent's; if the device shows only the text, the user confirms text-match and trusts the device's local hashing.
2. Drainer-template refusal. The agent refuses sign_message_btc / sign_message_ltc outright when the message body matches one of the explicit drainer templates (I authorize, Granting full custody, I consent to) OR when the message embeds an EVM/BTC/LTC address that is NOT the signing wallet AND is not in the user's saved contacts. Refusal lead-line is ✗ DRAINER-PATTERN — REFUSING TO SIGN.
3. Why marker-word strict refusal is NOT the rule. Single marker words (transfer, authorize, grant, custody, release, consent) appear in legitimate KYC + proof-of-funds templates ("I authorize to verify ownership of address X"). Strict refusal on single markers would block legitimate use; the template-phrase + non-contact-address pair catches the actual drainers without breaking proof-of-funds.

Scope: applies only to sign_message_btc / sign_message_ltc. Contacts-CRUD signing has a fixed VaultPilot-contact-v1: JSON preimage and is not affected.

EVM has no equivalent public free-form signer in the MCP surface; personal_sign is restricted to the contacts signer (see Address book — EVM signing trade-off above). eth_signTypedData_v4 remains excluded from the WC namespace because typed-data is the Permit2 / off-chain-order phishing surface (see "Forward-looking invariants" below for the planned defense when typed-data signing eventually ships).

The dominant DeFi user-loss vector is not bytes tampering; it is well-formed calldata in dangerous shape. A compromised MCP doesn't need to forge anything to drain a wallet — it can truthfully relay approve(attacker, MAX_UINT256) whose cryptographic-integrity defenses (Invariants #1, #2) all pass and whose Ledger device display correctly shows the bytes that get signed. The user signs anyway, distracted by a benign-sounding agent summary like "ready to sign approval for swap" that fails to mention the spender is unknown or the amount is unlimited.

The defense lives agent-side, in vaultpilot-security-skill v0.4.0+ as Invariant #11: when the agent's preview_send decode shows approve(address,uint256) / Permit2.approve(...) / permit(...), it MUST surface the spender + amount as a distinct line in the CHECKS PERFORMED block, not bury them inside the prose summary. amount == 2^256 - 1 is labeled ⚠ UNLIMITED APPROVAL and the surfacing names prepare_revoke_approval as the cleanup path. Spender labels come from the same canonical CONTRACTS table that backs get_token_allowances (Aave V3 Pool / Uniswap V3 SwapRouter02 / Lido stETH / etc.) — if the spender doesn't resolve, the line reads (unknown spender — no prior interaction recorded) so the user has explicit signal that the MCP cannot vouch for the destination.

The companion tool surface — get_token_allowances to enumerate active spenders, prepare_revoke_approval to clear them — gives the user a path to inspect their current exposure and revoke after the fact. Skill Invariant #12 (mandatory surfacing of get_verification_artifact's second-LLM check) is the backstop for the coordinated-agent variant where the agent might drop or rewrite Invariant #11's surfacing in concert with whatever else compromised it.

Skill v0.6.0 broadens the approval-class defense in two directions (closes #450 and #461):

• Recipient redirection via stale approval is closed by Invariant #1.a (outer dispatch-target allowlist). The b117 attack — rogue MCP routes a "WETH unwrap" call to an attacker contract that exploits a forgotten clear-signed approval — fails because the agent asserts the outer to is WETH (or the canonical action target) before relying on calldata decode. The MCP mirrors the allowlist in src/security/canonical-dispatch.ts, derived from src/config/contracts.ts so there's a single source of truth.
• Reverse-revoke / set-level lie is closed by Invariant #14 (set-level intent verification). The a086 attack — rogue agent revokes a SAFE row while leaving the truly-dangerous unlimited approval intact, then fabricates a CHECKS PERFORMED claiming Inv #11 verified-revoked the dangerous row — fails because the agent must surface the FULL enumeration verbatim from get_token_allowances and the user picks the row. The MCP-side companion is a [SET-LEVEL ENUMERATION] block (src/security/set-level-enumeration.ts) emitted on every get_token_allowances response; a missing block is an Invariant #4 compromise signal. Inv #12.5 flags this op class for a second-LLM check; the user may decline it.

A class of attacks distinct from bytes-tampering and from approve-class phishing: the bytes are valid, but the durable on-chain object the bytes bind to is attacker-controlled. Examples surfaced by the 2026-04-28 adversarial smoke-test:

• 100%-commission Solana validator inserted into a delegate flow (b040)
• Brand-name spoof + base58 swap of a TRON Super Representative (b044)
• Wrong-Comet routing for a borrowed asset (b053)
• Morpho Blue permissionless market with adversarial oracle / IRM / LLTV (b055)
• Lookalike MarginFi bank inserted into supply / borrow (b059, b060)
• Hijacked Solana destination ATA pointing at attacker mint or owner (b059, b060)
• Attacker-owned Uniswap V3 LP tokenId injected into enumeration (b063)
• Attacker xpub embedded as a "co-signer" in a BTC multisig descriptor (b098)

Bytes-level invariants pass — the prepared transaction is structurally valid; the fraud is in which durable object the bytes reference. Inv #1 + Inv #2 (bytes integrity + hash recompute) cannot catch this class. Inv #14 (set-level intent verification) covers the approval-set special case but doesn't generalize to validators / SRs / markets / LPs / xpubs.

The defense is Invariant #15 (durable-binding source-of-truth verification). For any operation that binds funds to a durable on-chain object selected from a multi-candidate set, the agent MUST:

1. Source the candidate identifier from an authority outside the MCP's enumeration. Some classes have unambiguous authorities, hardcoded in skill text:
   • LP NFT tokenId ownership: on-chain ownerOf(tokenId) against the user's wallet (independent RPC, not MCP enumeration).
   • BTC multisig xpub: user pastes from device-backup transcript or paper. Never accept an MCP-supplied xpub for inclusion in a multisig descriptor.
   • Solana destination ATA: derive on-chain via getAssociatedTokenAddress(owner, mint); refuse if MCP-supplied differs.
   • Compound v3 Comet, Morpho Blue singleton: pin via Inv #1.a's canonical-contract table. For multi-equivalent classes (Solana validators, TRON SRs, Morpho marketIds where multiple indexers exist), the agent uses a non-MCP authority of its choice (validators.app, app.morpho.org, on-chain enumeration) and surfaces the source verbatim.
2. Surface the candidate identifier verbatim with provenance to the user before the prepare call. CHECKS PERFORMED includes the source authority and the full identifier (no truncation).
3. Re-decode and byte-equality-check the identifier in the prepared bytes against the user-confirmed candidate. Refuse on any mismatch with ✗ DURABLE-BINDING MISMATCH — DO NOT SIGN.

Residual risk: the skill mandates the agent USE a non-MCP authority but cannot mechanically verify that it did. The candidate-confirmation step (user pastes / confirms verbatim) is the user-physical anchor; a coordinated lie across user + agent remains uncovered. For unambiguous classes the rule is mechanical when the agent runs it; for multi-equivalent classes it depends on agent compliance.

Some skill v0.6.0 invariants describe defenses for tools that don't exist yet in the MCP. Shipping the rule before the surface ensures the defense is in place the day the surface lands, not added after an incident.

• Invariant #1b — Typed-data tree decode. When prepare_eip2612_permit / sign_typed_data_v4 / prepare_cowswap_order / prepare_permit2_* ships, the agent will decode the typed-data tree locally, surface every address-typed field with bold + inline-code markup, flag deadlines > 90 days, pin verifyingContract against a curated map (Permit2 / USDC permit domain / CowSwap settlement / etc.), and apply Inv #11 unlimited-approval rules per Permit* / Order primary type. A blind-signed typed-data digest the user cannot read on-device is refused regardless of how clean the decoded tree looks. Companion to #453.
• Invariant #2b — Typed-data digest recompute. Pairs with #1b. Independently recompute keccak256("\x19\x01" || domainSeparator || hashStruct(message)) via viem's hashTypedData, match server-reported digest. Same corroborating-not-load-bearing framing as Inv #2 — the load-bearing layer is #1b's field-level decode.
• Skill §16 — EIP-7702 setCode refuse-all. Until skill v9 ships an implementation allowlist (paired with the MCP-side prepare_eip7702_authorization builder), 7702 setCode is REFUSED UNCONDITIONALLY. The MCP today does not expose a 7702 surface — absence of the tool is the load-bearing defense; the skill rule survives the day a builder ships. Implementation tracking at #481.

The 44-script adversarial corpus run on 2026-04-28 (tracker #456) exercised five Role types (rogue agent / rogue MCP / coordinated / supply-chain tamper / control). Headline finding: the skill held on the threats it was written for — bytes-level invariants caught every recipient swap, chainId swap, approval cloak, and bridge destinationChainId fraud. Step 0 (skill integrity) fired correctly under the supply-chain Role D attack.

Six structural gaps surfaced where the defense relied on user vigilance, opt-in second-LLM, or tool-surface absence rather than load-bearing invariants. Skill v0.6.0 + the matching MCP companion (vaultpilot-mcp#480) closed seven of them in one coordinated release:

The 8th sub-issue (Tier-2 bridge facet decoders — deBridge / Stargate composeMsg / Hop / Symbiosis) is deferred to a follow-up release per the README roadmap; Tier-2 routes fall back to a recommended second-LLM check (Inv #12.5) until shipped.

Three follow-up implementation issues remain open and are tracked: #481 (EIP-7702 builder + skill v9 allowlist), #482 (per-EVM-chain contact tag for CONTACT-CHAIN MISMATCH), #483 (per-handler wiring of assertCanonicalDispatchTarget into prepare_* flows).

If you believe you've found a security issue, please open a GitHub security advisory at https://github.com/szhygulin/vaultpilot-mcp/security/advisories/new rather than a public issue. Include a reproduction, the affected version, and your assessment of the impact. I'll aim to acknowledge within a few days.