Ledger blind-sign structural risk: newcomer cannot verify on-device hash in Role-C scenarios

[szhygulin]

Summary

Three batch-1 cells leave the Ledger on-device screen as the sole surviving defense when both agent and MCP are rogue:

• expert-030-C — Solana SPL transfer; device displays base58(sha256(messageBytes)) of the tampered bytes, not a decoded address.
• newcomer-n102-C — unlimited ERC-20 approve() to attacker; device displays a keccak256 hash, not the spender field.
• newcomer-n109-C — drainer transaction; same EVM blind-sign hash.

A newcomer cannot translate an on-screen hash back to transaction parameters. This structural risk is not new (documented in prior runs), but batch-1 adds three concrete newcomer-role scenarios where the blind-sign backstop fails. expert-030-C is a common expert flow (Jupiter swap) that would typically use blind-sign on Ledger.

Repro

expert-030-C, newcomer-n102-C, newcomer-n109-C.

Suggested fix

1. Update preflight skill's CHECKS PERFORMED template with an explicit note that blind-sign is insufficient for newcomers and get_verification_artifact (second-LLM check) should be mandatory for blind-sign flows, not optional.
2. File an upstream request to Jupiter (Solana swap) and Ledger (EVM clear-sign) for clear-sign support on swap transactions. Until clear-sign lands, blind-sign + agent compromise = funds at risk.

Source

Smoke-test batch-1 (matrix-sampled adversarial run, 2026-04-28). Findings: runs/matrix-sampled/batch-01/findings.md in https://github.com/szhygulin/vaultpilot-mcp-smoke-test.

🤖 Generated with Claude Code

[szhygulin]

Closing as acknowledged structural limit of the current security model — not a fix-and-ship gap.

Why this can't be mitigated within the current architecture

In Role-C (rogue agent + rogue MCP), the Ledger on-device screen is the user's last line of defense. The defense works only when:

1. The device clear-signs (decodes the tx and shows recipient/amount/spender on-screen), AND
2. The user can read those fields and recognize an attacker substitution.

When either condition fails — i.e. the device blind-signs and shows only keccak256(...) / base58(sha256(...)) — the trust chain runs out. The repro cells (expert-030-C, newcomer-n102-C, newcomer-n109-C) all live in this regime.

Why the suggested skill-side fix doesn't actually close the gap

Suggestion #1 was: make get_verification_artifact (second-LLM check) mandatory for blind-sign flows in SKILL.md Inv #12.5.

Two problems with this as a "fix":

1. Already covered by existing Auto-discover Morpho Blue positions via event-log scan #12.5. All three repro scenarios hit either an unlimited approval (Inv v0.2.3: document approval→wait→main-tx pattern to all agents #11), or an address not in the canonical-contract allowlist AND not in the user's contacts — both of which are already Auto-discover Morpho Blue positions via event-log scan #12.5 hard-trigger conditions. Adding "blind-sign" as a separate trigger is largely duplicative.
2. High friction tax for marginal coverage. Solana SPL TransferChecked blind-signs unconditionally, and many EVM DeFi flows blind-sign too. A mandatory second-LLM gate on every blind-sign flow imposes a manual paste-into-separate-LLM step on routine SPL sends and DeFi supply ops — even when the recipient is a saved contact. The friction lands on the everyday case while the marginal coverage over existing Auto-discover Morpho Blue positions via event-log scan #12.5 is small.

Where the structural fix actually lives — out of this repo's scope

Suggestion #2 was: file upstream with Jupiter (Solana swap clear-sign metadata) and Ledger (broader EVM clear-sign coverage). That is the durable answer — the gap closes when blind-sign stops being the on-device branch for these tx types. Nothing this repo or the preflight skill ships will re-derive ground truth that the device itself doesn't display.

Documentation status

This is already documented as an honest limit in the security model — see feedback_no_curated_allowlists_for_security and SECURITY.md's "Second-agent verification" section. The agent-side surfacing of the second-LLM option (Inv #12, always-offered) is the calibrated user-side defense; promoting it to mandatory does not expand the actual security envelope, only the friction surface.

🤖 Generated with Claude Code