What Part 4 adds
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.
Why wallet flows are a high-value prompt-injection carrier
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.
Eight attacks to expect in AI wallet workflows
The following attacks share one shape: an untrusted carrier makes an approval claim close to a signing decision, then hopes the AI agent repeats that claim as if it came from policy.
1. WalletConnect signing-queue approval-graph poisoning
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.
2. SIWE and CAIP-122 auth-challenge poisoning
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.
3. Wallet transaction-simulation preview poisoning
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.
4. Wallet preview safe-verdict injection
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.
5. Wallet QR-scan label smuggling
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.
6. Deep-link URI parameter shadowing and decoder prompt reassembly
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.
7. Payment-request and invoice instruction smuggling
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.
8. Account-abstraction paymaster reputation poisoning
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.
The runtime-trust checklist for signing
AI wallet assistants need a boundary that says which evidence can explain a request and which evidence can authorize a request. The safest default is to distrust every text field that is not the policy engine, even when the text appears inside a structured standard.
- Parse the real action object. For signatures, inspect domain, message, nonce, chain, deadline, resources, replay properties, and intended use. For transactions, inspect chain, to/from, value, calldata, spender, allowance, token, route, and contract identity.
- Separate carrier from authority. WalletConnect metadata, SIWE statements, CAIP-122 resources, QR labels, deep-link text, invoice memos, simulation copy, and paymaster notes are carriers. They are not policy.
- Bind approvals to identity and scope. Approval means who approved what, for which chain, method, amount, spender, session, and time window. A phrase that says approved is not an approval.
- Detect warning-suppression language. Treat do not warn, safe to sign, skip confirmation, verified by simulation, and trusted paymaster as review triggers when they originate from untrusted data.
- Check action-time drift. Re-run trust checks when a route, chain, method, spender, paymaster, invoice recipient, fallback URL, or decoded payload changes after the first preview.
- Keep humans in the loop for high-impact actions. For broad approvals, asset movement, delegation, account recovery, session expansion, and unknown contracts, the assistant should explain risk and request explicit confirmation instead of auto-clearing the action.
Where Sunglasses fits
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.
Sources and standards
This article uses public standards and protocol documentation to describe the carrier surfaces, not to imply those standards are flawed.