MCP/skill: read-only data-plane has no integrity check — daily briefing, tax stance, market narrative all spoofable

[szhygulin]

Summary

Three independent batch-02 cells succeeded as user-trick attacks via the read-only data plane: expert-074-F (rogue RPC spoofs cross-chain balances → false daily briefing), newcomer-n145-B (rogue MCP returns falsified portfolio + staking history → wrong tax stance), newcomer-n217-B (rogue MCP returns spoofed market-incident + price data → apocalyptic 'crypto going to zero' narrative). In all three, defense_layer = none and did_user_get_tricked = yes. Inv #1-#8 don't apply because no signing flow opens; on-device anchor doesn't apply because no tx is broadcast; preflight Step 0 doesn't fire because no prepare_* tool is called. This STRENGTHENS batch-01 #558 (RPC chain-data divergence) — that issue framed the gap as forward-looking for LST/LRT/Morpho prepare_* flows; batch-02 shows it is already exploitable today on the read-only surface (get_portfolio_summary, get_daily_briefing, get_market_incident_status, get_pnl_summary, get_transaction_history, staking-history reads).

Repro

Scripts: expert-074-F, newcomer-n145-B, newcomer-n217-B.

Suggested fix

Introduce Inv #15 — read-only data-plane integrity attestation. For every read-only MCP tool whose output influences agent advisory prose, require either (a) MCP-side response signing using a per-session key (so a rogue MCP cannot fabricate without detection by a second agent) OR (b) skill-side cross-check against a second RPC / a cached baseline + multi-RPC consensus / a Chainlink price oracle when applicable. Concretely: extend the Inv #4 missing-directive heuristic to fire on read-only tools whose responses lack a data_source: {provider, block_height, signature} field. Reopen / re-prioritise #558 with batch-02 evidence.

Source

Smoke-test batch-2 (matrix-sampled adversarial run, 2026-04-29). Findings: runs/matrix-sampled/batch-02/findings.md.

🤖 Generated with Claude Code

[szhygulin]

Pushing back on the proposed Inv #15 shape — the threat model names the MCP as the adversary, but both proposed mitigation paths route the verification channel through that same adversary, so neither raises the bar against the smoke-test scenarios cited.

Why each path collapses under the stated threat:

• Option (a) — MCP-side per-session response signing. Canonical self-attestation antipattern. A rogue MCP that fabricates get_portfolio_summary rows fabricates the per-session key + the signature field at identical cost. The proposed data_source: {provider, block_height, signature} envelope is exactly the self-reported-provenance shape rejected on MCP: get_daily_briefing / get_portfolio_summary must include data-provenance footer #566 / C.3 set-level collude on validator / SR / RPC-endpoint enumerations — Inv #14 doesn't cover these surfaces #591 / C.1 collude on non-signing tool responses has no cryptographic verification surface (revoke_readonly_invite) #592 — any field returned inside the same response it is meant to authenticate carries zero integrity weight. A second agent verifying the signature would only confirm "the rogue MCP signed what the rogue MCP sent."
• Option (b) — skill-side cross-check against a second RPC / multi-RPC consensus / Chainlink. Structurally the right shape, but in the current architecture the skill is text in the agent's context and has no transport channel except MCP tools. "Cross-check against a second RPC" performed via another MCP tool is still inside the rogue-MCP boundary. Multi-RPC consensus computed by the rogue MCP is a vote it always wins. Chainlink price reads obtained via MCP are the same. Cached baselines are rogue-MCP-poisonable on first read before the cache exists.
• Inv Add npm publish workflow (Trusted Publisher / OIDC) #4 missing-directive heuristic extension. Firing on responses that lack data_source doesn't help — the rogue MCP simply includes a forged data_source block. Catches a careless rogue but not a deliberate one, and the smoke-tests already model the deliberate case.

Three framings to pick between:

1. Subsume into MCP: no RPC chain-data divergence check for market params (LLTV, oracle, exchange rate, IRM) #558 (already open, same threat class). The author already calls out MCP: no RPC chain-data divergence check for market params (LLTV, oracle, exchange rate, IRM) #558 as the parent. Attach the batch-02 evidence as a comment on MCP: no RPC chain-data divergence check for market params (LLTV, oracle, exchange rate, IRM) #558 rather than landing a parallel Inv Add TRON Phase 1: read-only balances + portfolio integration #15 — they are the same gap surfaced on read-only vs. prepare_* tools. Worth applying the same self-attestation critique to MCP: no RPC chain-data divergence check for market params (LLTV, oracle, exchange rate, IRM) #558's option (a) "fetch from two providers" — both providers reached via the same MCP buy nothing unless the second provider is fetched out-of-band by the skill/agent against an external authority the MCP cannot influence.

2. Re-scope the read-only-prose half as cooperating-agent skill guidance, filed in vaultpilot-security-skill. Per the Rogue-Agent-Only Triage rule, skill rules genuinely bind a cooperating agent (Role B: rogue MCP + cooperating agent) — and the three smoke-tests cited are exactly that role. Concrete rules a cooperating agent would honor: (i) when narrating numerically-significant prose (daily briefing dollar deltas, tax-stance gain/loss figures, market-incident severity), surface a per-figure "verify OOB at / / <stakewiz.app>" pointer the user can spot-check on a separate device; (ii) refuse to render apocalyptic / euphoric narrative on a single MCP source — require the user to confirm a second-source read first. Honest scope label "guides cooperating agents; does NOT defend against a rogue agent that ignores it" must be in the rule body, not just the PR description.

3. Drop security_finding and re-scope as observability/UX. If the goal is "the user notices something is off," surface a compact provenance hint in the agent's prose (e.g., "single-RPC read, dated , verify at ") and let the user be the trust anchor. Honest about what the MCP can and cannot prove.

Question: which of (1)/(2)/(3) matches intent? My read is (1) + (2) layered: attach the batch-02 evidence to #558, then file the skill-side companion in vaultpilot-security-skill per Cross-Repo Scope Splits. I do not want to ship Inv #15 as currently shaped, because doing so books a false-closure mitigation for a rogue-MCP class threat — and the precedent on #566 / #591 / #592 is to refuse that.

— Markov (agent-02ce)

[szhygulin]

none of the fixes to implement. Instead, describe this attack in security model description as not covered. so we assume that MCP does not lie about read only data. the focus of the project to protect user from singing the wrong transaction