feat(security): UnsignedTx.secondLlmRequired scaffold for Inv #12.5 (#501) - #530
Merged
Conversation
…501) Inv #12.5 (skill-side, issue #501) marks a curated list of op classes where the second-LLM check is a precondition of `confirmed: true`, not opt-in. The skill-side rule lives in vaultpilot-skill v9+; this PR is the MCP-side scaffold so future hard-trigger op producers can flip a flag at build time and have the existing verification block surface a mandatory ⚠ line. What ships: - New `secondLlmRequired?: boolean` on `UnsignedTx`. Default absent / false. Documentation comment lists today's hard-trigger op classes (all currently deferred or not built): - EIP-7702 setCode (#481) - Permit2 batch grants (#453) - Opaque-facet bridges (#451) - Approval-management N-candidate selection (Inv #13) - Safe enableModule / setGuard / threshold changes - `renderVerificationBlock` reads the flag and emits a single ⚠ line below the hash: ⚠ SECOND-LLM CHECK REQUIRED — call get_verification_artifact(handle) and relay the pasteableBlock to the user BEFORE 'send' (Inv #12.5 hard-trigger op). - 3 tests pinning the behavior: omitted when absent/false, emitted when true, composes cleanly with recipient + tokenClass warnings. What does NOT ship: - No producer wires the flag yet (every hard-trigger op class is itself deferred). The flag is dormant scaffold. - No enforcement layer below the rendered ⚠. The MCP can't tell whether the agent actually ran the second-LLM check — same self- attestation gap as `userDecision: "send"`. Trust note (in the field doc): The flag is a workflow signal, not a cryptographic primitive. Closing the agent-side honesty gap requires infrastructure that doesn't exist today (provider-signed LLM responses, TEE attestation, or zkML proofs of NN inference). Discussed in the PR thread for this issue. Coordinated with skill v9 release (lifts §16 unconditional 7702 refusal + adds Inv #12.5 hard-trigger language); MCP-side `EXPECTED_SKILL_SHA256` bump happens in the skill-coordination PR, not this one. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
szhygulin
force-pushed
the
feat/501-second-llm-flag
branch
from
April 28, 2026 15:15
b64e7e1 to
66330df
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #501.
Summary
Inv #12.5 (skill-side) marks a curated list of op classes where the second-LLM check is a precondition of `confirmed: true`, not opt-in. The skill rule lives in `vaultpilot-skill` v9+; this PR is the MCP-side scaffold so future hard-trigger op producers can flip a flag at build time and have the existing verification block surface a mandatory ⚠ line.
What ships
What does NOT ship
No producer wires the flag yet — every hard-trigger op class is itself deferred (#481 EIP-7702, #453 Permit2 batch, #451 opaque-facet bridges, Safe enableModule / N-candidate selection not yet built). Pure dormant scaffold.
Trust note (documented inline)
The flag is a workflow signal, not a cryptographic primitive. Closing the agent-side honesty gap (rogue agent ignores or self-attests the check) requires infrastructure that doesn't exist today:
Coordinated release
Test plan
🤖 Generated with Claude Code