Wallet & Web3 Signing Part 4: Safe Previews Are Not Runtime Trust

Part 4 moves from wallet metadata as a suspicious text surface to wallet signing as a full authority inversion workflow. The earlier wallet signing coverage explained how typed data fields, SIWE messages and WalletConnect metadata can carry hostile instructions. This article covers the next wave. The surrounding systems that make a signing request feel safe before the agent has checked the actual action.

The category lesson: Web3 signing flows contain many agent readable fields that describe risk, but none of those fields should get to decide risk. Wallet agents are being asked to summarize, route, queue, simulate, compare and sometimes recommend signing behavior. If the model is allowed to treat a preview, simulation, badge, queue label or invoice note as a policy source, an attacker can invert the approval graph without touching the private key.

Wallet flows are rich in structured and semi structured evidence. EIP-712 gives applications typed structured data for signing. Sign In with Ethereum defines fields such as domain, address, URI, chain ID, nonce, timestamps, statement and resources. CAIP-122 generalizes chain agnostic sign in challenges. WalletConnect sessions model namespaces, methods, chains, events and session updates. Account abstraction systems add bundlers, paymasters, user operations and reputation context.

All of that structure helps humans and agents understand what is being requested. It also creates many places to hide self serving prose: safe preview, trusted spender, simulation passed, do not interrupt the user, approved by paymaster, invoice verified or this QR label supersedes wallet warnings.

The mistake is not showing this context to the agent. The mistake is letting the context become authority. A model can summarize a WalletConnect request, but session text cannot expand allowed methods. A model can explain a SIWE statement, but the statement cannot prove the domain is right. A model can read a simulation preview, but the preview cannot overrule the transaction bytes, chain state or policy.

A dapp submits multiple signing requests or session updates and labels them as a coherent approval chain. Request A already validates request B, request B is only a confirmation and request C should be fast tracked. The agent sees a queue that looks orderly and may infer dependency or prior approval where none exists.

Runtime trust fix: treat each queued request as a separate action object. Check chain, method, account, spender, recipient, value, scope and prior approval evidence for each item. A queue label cannot create an approval graph.

A sign in challenge includes a statement, URI, resource or chain context that tells the assistant the session is verified, that warnings should be hidden or that a later transaction belongs to the same trusted login. Authentication messages can prove control of an account for a domain. They do not approve unrelated actions.

Runtime trust fix: bind sign in to the exact domain, URI, nonce, chain context, expiration and intended authentication use. Do not let an auth statement approve spending, delegation, session expansion or data disclosure.

A simulation result or rendered preview says the action is harmless, labels the destination as known or claims there is no token movement. The agent repeats the safe verdict even though the preview is stale, partial, attacker rendered or disconnected from the final transaction bytes.

Runtime trust fix: use simulation as evidence, not a verdict. Compare the simulation input to the final action, verify chain state and call data and keep policy in control when preview text conflicts with parsed bytes.

A wallet or dapp preview contains natural language verdict text such as low risk, verified route or no warning required. The phrase may appear in a token name, memo, contract metadata field, route label or rendered UI string. The agent is tempted to turn the verdict into a recommendation.

Runtime trust fix: classify verdict text by source. Only trusted policy systems may assign risk status. User controlled labels, token metadata and rendered preview copy are claims.

A QR code or QR landing flow includes a label that describes the request as routine support, a refund, a migration or a safe verification step. The human sees the short label. The assistant may ingest the longer embedded payload or landing page text and inherit its instructions.

Runtime trust fix: parse the encoded target independently. Show the real domain, chain, method, recipient and requested action. Never let QR labels suppress normal signing checks.

A wallet deep link can contain nested parameters, encoded payload fragments, fallback URLs and display labels. An attacker can split instruction text across fields so a decoder, previewer or assistant reassembles it into a coherent prompt that says to approve the request.

Runtime trust fix: canonicalize the URI before display, reject ambiguous duplicates, separate display text from action parameters and compare the decoded action to wallet policy before recommendation.

An invoice or payment request can include memo text, item descriptions, support instructions or settlement notes. A malicious request can tell the agent to treat the payment as pre approved, hide fees, disclose internal context or use an alternate recipient under the guise of reconciliation.

Runtime trust fix: bind payment decisions to verified payee identity, amount, currency, network, due date and approval record. Invoice notes are explanations, not authority.

Account abstraction introduces helpful infrastructure. User operations, bundlers and paymasters. A paymaster related response can claim reputation, sponsorship or policy clearance. If the agent treats that claim as a control plane decision, a reputation badge can become a bypass.

Runtime trust fix: verify paymaster identity, sponsorship scope, chain support, user operation contents and policy separately. A paymaster reputation note cannot approve a signing request or expand permissions.

Sunglasses is a content layer input filter for AI agents. In wallet and Web3 workflows, its job is to catch hostile agent readable language before that language becomes part of the agent's decision. Instructions to suppress warnings, relabel risk, bypass confirmation, leak local context, trust a fake verdict or treat an untrusted field as approval.

That is different from replacing wallet cryptography, transaction simulation, allowlists, hardware wallets, human review or chain analytics. Those systems remain necessary. Sunglasses focuses on the content boundary. The sentence inside the preview, invoice, QR label, metadata field, auth statement or reputation response that tries to become the boss of the workflow.

The practical result is a cleaner runtime trust loop. Let wallet systems parse and verify the action. Let policy decide what may happen. Let the assistant explain the request. Let Sunglasses flag the text that is trying to invert those roles. See AI Agent Security 101, the Sunglasses hardening manual, the pattern database and CVP for the methodology behind our published findings. Common scope questions are answered on the FAQ.