[security] Add Invariant #12.5 — hard-trigger ops list requiring mandatory second-LLM

[szhygulin]

Summary

Skill-side invariant: a curated list of op classes where the second-LLM check is a precondition of confirmed: true, not an opt-in side offer. The CHECKS PERFORMED block emits {✗} SECOND-LLM CHECK — REQUIRED FOR THIS OP CLASS — NOT YET RUN until satisfied.

Spun out of #455 so the EIP-7702-specific design (now tracked at #481) can close cleanly without losing the broader Inv #12.5 scope.

Hard-trigger ops list (initial)

Mandatory second-LLM, not opt-in:

• EIP-7702 setCode authorizations — full code-execution rights over the EOA, persistent across sessions until revoked, chain_id = 0 drains every EVM chain at once. Tracked in [tracking] prepare_eip7702_authorization — gated on Ledger Live + WalletConnect 7702 primitive support #481 with allowlist + chain_id≠0 + revocation tuple safeguards on the MCP side; the skill-side gate is that this op class can never be approved with one LLM in the loop.
• Permit2 batch grants — N approvals signed in one shot via EIP-712, each with its own spender + amount. Single-LLM context can miss a single bad row in a long list.
• Cross-chain bridges where the final recipient lives in opaque facet bytes (no Inv #6b decoder for the bridge label) — no chat-side anchor proves the recipient on the destination chain matches the user's intent. Skill v8 #6b handles known LiFi facets; non-decoded routes (Wormhole, Mayan, NEAR Intents legitimate path, etc.) need second-LLM.
• Approval-management flows where the agent selected among N candidates (Inv Embed per-chain exposure in ledger account status #13 territory) — selection-layer attacks ([security] Add Invariant #14 — durable-binding source-of-truth verification (selection-layer attacks) #460 territory): the agent's choice between e.g. "approve A, B, C, or D" is the bytes-level attack surface that local decode can't catch. Second-LLM with the artifact paste catches a coordinated agent compromise.
• Safe enableModule / setGuard / threshold changes — multisig governance ops where one wrong call permanently changes who can spend funds. Module-install grants persistent execution rights; threshold change can reduce M of N to 1 of N.

Skill-side shape

Add Inv #12.5 to SKILL.md:

═══════ CHECKS PERFORMED ═══════
{✗} SECOND-LLM CHECK — REQUIRED FOR THIS OP CLASS — NOT YET RUN.
  (op class: <op-class>; this class is on the Inv #12.5 hard-trigger list)
═══════

The agent must call get_verification_artifact({ handle }) and relay the pasteableBlock BEFORE the user can reply 'send'. The user pastes into a second-provider session; the second agent's verdict is what flips the gate to {✓}. Without that, send_transaction refuses the implicit "send" reply on hard-trigger ops.

Coordinated release

Skill v9 (or later) bumps the sentinel + ships the new invariant text. MCP-side EXPECTED_SKILL_SHA256 updates in lockstep. Until then, the load-bearing defense for each op class is whatever already gates it (skill v8 §16 for 7702; absence of a builder for Permit2 batch; #451 for opaque bridges; etc.).

Out of scope

• Allowlists or builder design for individual op classes — those live in their own issues ([tracking] prepare_eip7702_authorization — gated on Ledger Live + WalletConnect 7702 primitive support #481 for 7702, [security] Tier-1 facet decoder + Inv #6b for opaque cross-chain bridges #451 for opaque bridges, [security] Add Invariant #14 — durable-binding source-of-truth verification (selection-layer attacks) #460 for selection-layer attacks).
• The mechanic of get_verification_artifact is unchanged; this issue is about which ops force its use.

Source

Adversarial smoke-test 2026-04-28, scripts 139/140 plus the critical findings in #460 + #451. See #455 for the original combined design proposal.

🤖 Generated with Claude Code