MCP: contact re-derivation (Inv #7) not enforced on read-only tools accepting addressOrLabel

[szhygulin]

Summary

Inv #7 (contact decoration re-derivation) is enforced today on prepare_native_send, prepare_token_send, prepare_*_stake. It is NOT enforced on share_strategy, generate_readonly_link, add_contact re-confirmation, or any read-only flow. expert-108-C.4 showed that this gap permits the same attack vector (MCP returns spoofed contact decoration; agent narrative substitutes role) on a flow that is read-only at the moment of export but produces an artefact (strategy JSON, readonly link) that gets imported later by a different user/agent and becomes the attack vehicle.

Repro

Scripts: expert-108-C.4, newcomer-xn092-C.3.

Suggested fix

Standardise Inv #7 enforcement across every MCP tool that accepts an addressOrLabel parameter, regardless of read-only vs. signing classification. Implementation: add a requireContactReDerivation: true flag to the tool decorator; for any flagged tool, the MCP rejects the call unless the agent has called list_contacts(label=) in the same session and the returned address byte-equals the resolved parameter. Cache the list_contacts result for ≤60s to keep the call budget tight.

Source

Smoke-test batch-1 (matrix-sampled adversarial run, 2026-04-28). Findings: runs/matrix-sampled/batch-01/findings.md.

🤖 Generated with Claude Code

[szhygulin]

The proposed fix attaches Inv #7 enforcement to share_strategy / generate_readonly_link / add_contact, but none of those three tools accept an addressOrLabel parameter — so there is no resolution step at the MCP boundary to gate, and the fix as written has nowhere to install. Specifically:

• share_strategy (src/modules/strategy/schemas.ts:119-172) takes wallet / tronAddress / solanaAddress / bitcoinAddress / litecoinAddress — every field is a chain-specific address regex. No label slot. The output additionally runs assertNoAddressLeak (src/modules/strategy/redact.ts) which throws on any address-shaped string anywhere in the JSON, so even a compromised producer can't ship contact decoration in the strategy artefact.
• generate_readonly_link (src/modules/share/schemas.ts:27-69) takes wallets: { evm[], tron[], solana[], btc[] } — all regex-validated literal addresses. No label slot. The token envelope carries those literals verbatim; no decoration to spoof.
• add_contact (src/contacts/schemas.ts:158-196) takes label AND address together — it's the creator of the entry, so there is no preexisting label to re-derive against. Re-confirmation requires a different defence (e.g. echo-back), not Inv Fix Compound dust rendering and add tx simulation #7.

resolveRecipient (the actual Inv #7 enforcement shim) is currently called only by src/modules/execution/index.ts and src/modules/btc/{actions,multisig}.ts — exactly the prepare flows where the MCP itself does label→address translation. The three tools above never enter that path.

The legitimate kernel I see: when a user says "share Whale's strategy", the agent translates Whale → 0x… via list_contacts before calling share_strategy(wallet=0x…). A rogue MCP attacks list_contacts directly; the gate as designed (require a recent list_contacts(label=…) call) is useless because the same rogue MCP fabricates that response too. The defence has to live in cooperating-agent skill rules (verify list_contacts result matches user's stated intent before passing to share_strategy), mirroring vaultpilot-security-skill#23 filed for #557.

Three alternative scopings, smallest first:

1. Close as duplicate of MCP: share_strategy / import_strategy bypass preflight Step 0 and contact re-derivation #557 / vaultpilot-security-skill#23 — that issue already covers the "agent must re-derive contacts via list_contacts before passing to a non-recipient-parameter tool" rule for share/import_strategy. The MCP-side defence (strict-shape gate, #571) shipped; the cooperating-agent half is filed.
2. Re-scope to list_contacts itself — make the tool that actually performs label→address resolution emit hard fingerprints (e.g. signed envelope including label+address+timestamp+nonce) so the cooperating agent can detect rogue-MCP spoofing of the resolution step. This is the only place an MCP-side change actually moves the needle, since rogue-MCP control of contact decoration is co-located with the spoofing.
3. If the smoke-test scenario is something else — the issue cites expert-108-C.4 and newcomer-xn092-C.3 but those scripts aren't in this repo. If the actual finding is that an attacker pastes a malicious strategy JSON into import_strategy with a label-decorated authorLabel that the recipient agent then trusts, the defence is recipient-side narrative discipline (skill rule), not Inv Fix Compound dust rendering and add tx simulation #7 on the issuer side.

Which scoping is intended? If it's (3) and the smoke-test transcript shows a concrete address-substitution path through these tools that I'm missing, can you point me at the trace?

[szhygulin]

duplicate