When LLMs Sign Transactions: AI-Driven Smart Contract Threat Model

TL;DR — Quick Summary

The moment an LLM can prepare, approve, or sign blockchain transactions, your threat model stops being "smart contract only" and becomes agent plus signer plus connector plus contract.
The highest-risk failure is not just key theft. It is reasoning-to-execution translation: a probabilistic system turning ambiguous context into exact, irreversible calldata.
The practical control boundary is not the prompt. It is policy outside the model: destination allowlists, capped spend, exact-payload approvals, mandatory transaction simulation, and time-bounded session keys.
For teams shipping wallet-enabled copilots, trading agents, treasury bots, or MCP-connected signers, the right question is: what exact transaction can this system produce at its worst moment?
Auditors now need to review the full path from prompt and memory to connector, signer, and onchain effect. A clean Solidity codebase alone does not make the deployment safe.

Introduction

A conventional smart contract threat model starts from code: privileged roles, external calls, upgrade keys, reentrancy surfaces, price oracles, governance powers, and economic invariants. That model is still necessary. But once a large language model can drive a signer or assemble live transaction payloads, it becomes incomplete.

An LLM is not a deterministic execution engine. It is a probabilistic reasoner operating over prompts, retrieved documents, memory, tool outputs, and ambient context. A blockchain transaction, by contrast, is exact and final. It carries a concrete destination, selector, amount, nonce, gas policy, and calldata blob. The dangerous seam is where language reasoning crosses into machine action.

That seam is where losses happen.

If a human operator signs a bad transaction, we usually ask whether the UI was compromised, whether the policy was weak, or whether the signer misunderstood what they were approving. When an AI system signs or prepares the transaction, the same questions still matter — but now we must add prompt injection, memory poisoning, connector tampering, simulation drift, and authority mis-scoping. The contract may execute perfectly while the system as a whole still fails catastrophically.

This is why teams deploying agentic trading, autonomous treasury operations, AI-assisted governance, or MCP-connected wallet tooling need a dedicated threat model for LLM-driven signing flows.

The core shift: from software user to financial actor

A normal application user clicks buttons. A wallet-enabled LLM stack can:

compose token transfers
approve spenders
route swaps across DEXs
bridge capital cross-chain
submit governance actions
rebalance treasury positions
trigger downstream automation through bots, relayers, or custodial connectors

At that point, the model is no longer simply giving recommendations. It is participating in settlement.

That distinction matters because the economic blast radius becomes immediate. A slightly wrong summary is annoying. A slightly wrong smart contract call can drain a wallet, create an unlimited approval, or lock funds in an unintended system. The determinism gap becomes operational: the model reasons in probabilities, but the EVM executes exact arithmetic and exact calldata.

For security teams, the question changes from "can the AI help with operations?" to "what exact authority does the AI hold, directly or indirectly, and what constrains it when the model is wrong?"

The new attack surface: where LLM signing systems actually fail

The most important observation is that these systems rarely fail through one dramatic Hollywood-style compromise. More often, they fail through ordinary architecture decisions that become dangerous when combined.

1. Prompt-to-transaction escalation

The simplest chain is also the most famous: an attacker places malicious instructions in a channel the model reads, and the model turns those instructions into wallet actions. The source might be a support ticket, governance thread, scraped social post, token metadata field, documentation page, or tool response. The model interprets the text as relevant context and proceeds toward a signing flow.

This is classic prompt injection, but with a crucial upgrade: instead of causing a wrong answer, it causes a financial side effect.

If the same model both decides what should happen and constructs what will be signed, prompt injection becomes a transaction-construction primitive.

2. Indirect context corruption

In many production systems, the dangerous input does not come from the direct user. It comes from retrieval, memory, a connector, or a third-party tool. That makes indirect prompt injection especially serious for wallet-enabled workflows.

A wallet copilot that reads portfolio notes, protocol docs, DAO proposals, support systems, Discord summaries, and MCP tool outputs has many places where attacker-controlled text can enter the loop. The chain is not "attacker tells wallet to send money." It is "attacker poisons the context that the model later treats as trusted reasoning material."

3. Approval abuse is often worse than a transfer

Teams sometimes treat token approvals as harmless setup actions because the first transaction does not move funds immediately. That is a dangerous habit.

A signing assistant that can issue approve() or setApprovalForAll() calls can create durable downstream loss even when the original UI makes the action look routine. This is where approval bypass becomes central. If the model is allowed to authorize unlimited or poorly bounded approvals, the exploit path can unfold later, outside the original review window.

In many real-world systems, the highest-value question is not "can it send tokens now?" but "can it authorize someone else to take tokens later?"

4. Connector and tool-chain tampering

A large share of LLM signing systems do not talk to the wallet directly. They go through an SDK, browser extension, relayer, MCP server, custom policy service, embedded wallet provider, or signing abstraction. That means the trust boundary extends beyond the model and the contract into the connector itself.

If the connector can rewrite destinations, mutate calldata, misreport decoded effects, swap chain IDs, or suppress warnings, the system can fail even when the model's intent was correct. This is the same class of issue we describe under tool integration security and agentic supply chain: the model may be honest, but the tool path can still betray it.

5. Simulation mismatch and state drift

Even a well-designed flow can break if the system simulates one state and signs against another. In DeFi, slippage, route changes, mempool timing, MEV, stale balances, and nonce races matter. A transaction that looked safe during review may be harmful by dispatch time.

That is why transaction simulation must be treated as a mandatory pre-sign control, not decorative UX. And even then, teams need re-validation immediately before broadcast.

6. Identity inheritance

Many agent deployments run with the ambient authority of a developer machine, cloud runtime, bot worker, or shared infrastructure role. When the signing flow inherits that broader identity, wallet compromise is only one of several equivalent compromise paths.

This is the danger of identity inheritance: the agent's wallet authority ends up implicitly backed by every other secret, process permission, and network capability in the host environment. A safe signer cannot rescue an unsafe runtime.

Why LLM signing is more dangerous than normal automation

Traditional automation can be risky too. Scripts have bugs. Bots can be misconfigured. But LLM-driven transaction systems add three structural properties that raise the ceiling on loss.

Ambiguous input, exact output

A scripted automation path usually has narrow inputs and predictable branches. An LLM consumes broad, human-language context and then emits exact, machine-level instructions. The range of inputs is vastly wider than the range of safe outputs.

High-confidence wrongness

A model can produce a fluent rationale for a harmful action. That makes operator review harder, because the system does not look broken. It looks persuasive.

Hidden transitive trust

The user sees a single assistant. In reality, the action path may include retrieval systems, memory stores, wallets, browser contexts, MCP servers, policy services, and relayers. Each added layer can widen the attack surface without being obvious in the UX.

This is why teams should stop describing these deployments as "an AI assistant with wallet support" and instead treat them as autonomous financial execution systems with an LLM in the control loop.

The minimum secure architecture for transaction-signing LLMs

The right design pattern is not "trust the model more." It is "make model failure non-catastrophic."

1. Separate intent generation from signing authority

The model should propose a transaction intent, not directly control an unconstrained signer. That intent should include:

chain ID
destination address
function selector
decoded action summary
exact asset and amount bounds
expiry window
simulation result
human-readable justification

A separate policy layer should decide whether that intent is executable.

2. Use scoped signing identities

Avoid broad hot-wallet authority. Prefer narrow, revocable, expiring identities such as session keys, smart-account policies, or workflow-specific sub-accounts. If an agent only needs to claim rewards, it should not also be able to bridge assets, change governance settings, or grant arbitrary approvals.

3. Bind approvals to the exact payload

A human approval button that says "approve transaction" is not a control. Review must be bound to the exact payload that will be signed: token, spender, amount, destination, chain, selector, deadline, and decoded side effects.

Broad approvals over categories of actions create room for silent drift. Exact payload binding reduces that room dramatically.

4. Simulate, decode, and re-validate

Before any signature exists, the system should simulate the precise transaction, decode all material effects, compare them against policy, and then repeat key checks at dispatch time. If state drift invalidates assumptions, the approval should expire instead of proceeding silently.

5. Enforce deterministic policy outside the model

The model can suggest, summarize, and explain. It should not be the ultimate policy engine. Hard constraints belong outside the LLM:

approved contract allowlists
approved asset lists
exact spend ceilings
exact approval caps
blocked function selectors
blocked chains
mandatory dual control above thresholds
mandatory delay windows for sensitive actions

A safe architecture assumes the model will eventually produce a bad recommendation and makes that recommendation non-executable.

What auditors should test in an AI-driven signing stack

When Zealynx reviews these systems, the interesting questions live above the Solidity layer.

Destination integrity

Can the system only send value to fixed registries, or can it invent new addresses? Are ENS names or aliases re-resolved at execution time? Can a connector substitute a recipient after the model proposes it?

Approval scope

Can the model request unlimited approvals, broad operator rights, or generic delegated permissions? Are parameter bounds enforced on-chain or just described in prompts?

Working auditors in your corner, all year

Zealynx Insiders: weekly live sessions, 1:1 advisory, pair-auditing, and Krait runs on your code, from the firm behind 42 audits. Founders get a two-day audit session on the $500/year plan.

No spam. Unsubscribe anytime.

Transaction intelligibility

Can a human reviewer inspect a meaningful decoded summary of what will happen? Opaque router calldata and hex-only review surfaces make approval theater, not approval security.

Simulation trustworthiness

Is simulation performed with an independent source of truth? Are state changes, approvals, transfers, and internal calls actually surfaced to the operator? Does the system re-check drift between simulation and broadcast?

Tool provenance

If the signing path runs through an MCP Host, wallet SDK, browser extension, or custom relayer, can the operator prove provenance, version pinning, and integrity? Can outputs from the tool path carry fresh instructions back into the reasoning loop?

Runtime containment

If the model host is compromised, can an attacker automatically escalate into the signing layer? Or is the signer isolated by separate credentials, policy engines, and revocation controls?

Failure behavior

What happens when the model is uncertain, the ABI does not decode cleanly, simulation conflicts with expectation, gas spikes, or the policy engine cannot classify an action confidently? Secure systems fail closed.

A practical policy envelope for common use cases

Different wallet-enabled AI systems need different envelopes, but none should be open-ended.

Treasury copilot

Allowed:

fixed counterparties only
exact-amount stablecoin transfers under thresholds
pre-defined payout windows
claim and distribute operations on approved contracts

Disallowed:

new recipients
infinite approvals
governance changes
arbitrary contract interaction

Trading or rebalance agent

Allowed:

exact protocol list
exact asset universe
position-size caps
slippage and volatility bounds
simulation plus post-simulation drift checks

Disallowed:

bridging to new chains
arbitrary calldata
router upgrades without review
emergency override of risk limits by prompt

Governance assistant with execution powers

Allowed:

draft and simulate proposals
execute only pre-approved operational actions
vote only within declared policy ranges

Disallowed:

treasury movement through governance indirection
contract upgrades without external approvals
signer or policy rotation initiated by the same agent

The common pattern is simple: bounded task authority. The agent should not be able to widen its own envelope.

The most common design mistake: confusing explanation with control

Teams often show a nice explanation layer and mistake it for a security boundary. The wallet assistant explains what it plans to do, maybe even in polished prose, and the operator feels reassured.

But explanation is not enforcement.

An LLM can confidently explain a harmful transaction. A compromised connector can explain the wrong transaction. A stale simulation can explain a transaction that is no longer the one being signed. Natural-language narration is useful for usability, but it is not a substitute for policy, decoding, simulation, or payload binding.

In practice, the most important shift for product teams is psychological: stop trusting articulate systems just because they sound deliberate.

Conclusion

The threat model for smart contracts changes materially when LLMs can prepare or sign transactions. The contract is still critical, but it is no longer the whole system. The real trust boundary now spans the model, the prompt and memory layer, the connector, the signer, the policy engine, and the contract itself.

That means the security question is no longer just "is the Solidity safe?" It is:

Can this entire AI-driven execution path be manipulated into producing a valid but harmful onchain action?

If the answer is yes, the deployment is unsafe even when the contract code is flawless.

The practical defenses are not mysterious. Separate planning from signing. Use narrow identities. Simulate before sign. Bind approval to the exact payload. Enforce deterministic policy outside the model. Isolate the runtime. Review the connector supply chain. And audit the whole path as one system.

If your team is building wallet-enabled AI products, this is already your threat model. The only remaining question is whether you are treating it like one.

FAQ

1. Why is an LLM signing a transaction riskier than a normal trading bot?

A normal bot usually operates on narrow, structured inputs and predictable execution logic. An LLM-based signer operates on broad language context and probabilistic reasoning, then turns that reasoning into exact calldata. That widens the space of unsafe inputs dramatically. The dangerous seam is the determinism gap: ambiguous language and context on one side, irreversible machine execution on the other.

2. Is prompt injection really enough to cause fund loss?

Yes — if the architecture lets the model both decide the action and reach a signer or approval path. In that setup, prompt injection can become a transaction-construction primitive. Even worse, indirect prompt injection can arrive through retrieved docs, support systems, scraped content, or tool output rather than from the direct user.

3. Why are token approvals often more dangerous than transfers?

A transfer causes immediate movement. An approval can create durable authority that is exploited later, outside the original review moment. That is why approval bypass matters so much in wallet-enabled AI systems: a seemingly routine setup action can silently grant open-ended spend rights to a malicious or compromised counterparty.

4. What is the minimum safe architecture for an AI wallet assistant?

The minimum safe architecture separates model-generated intent from actual signing authority, uses scoped identities like session keys, requires transaction simulation, binds approvals to the exact payload, and enforces deterministic policy outside the model. The core idea is to make model failure bounded instead of catastrophic.

5. Can transaction simulation solve the whole problem?

No. Transaction simulation is necessary, but not sufficient. Simulations can become stale, connectors can misreport effects, and policies can still be too broad. Simulation reduces uncertainty about the onchain result; it does not remove prompt injection, connector tampering, or authority mis-scoping.

6. What should auditors review beyond the smart contract code?

Auditors should review context inputs, memory behavior, connector provenance, approval scope, signer isolation, policy enforcement, and failure handling across the full execution path. In an AI-driven signing stack, the critical vulnerabilities often live outside the Solidity contracts even though the contracts are where the economic consequences settle.

Glossary

Term	Definition
LLM	A large language model that reasons over text and tools probabilistically rather than executing deterministic business logic.
Determinism Gap	The mismatch between probabilistic AI reasoning and deterministic blockchain execution.
Prompt Injection	Malicious instructions embedded in model inputs that alter the model's behavior or priorities.
Transaction Simulation	A pre-sign execution preview that reveals the actual onchain effects of a transaction before broadcast.
Session Key	A temporary, scoped signing key that delegates limited authority without exposing the primary wallet.
Identity Inheritance	A failure mode where the signer or agent inherits unsafe privileges from the surrounding runtime or host environment.

View complete glossary →

Working auditors in your corner, all year

Zealynx Insiders: weekly live sessions, 1:1 advisory, pair-auditing, and Krait runs on your code, from the firm behind 42 audits. Founders get a two-day audit session on the $500/year plan.

No spam. Unsubscribe anytime.