Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-blockchain-tx-guard

Blockchain transaction guard — pre-commit safety checks for every agent-initiated transaction

A blockchain transaction, once committed, cannot be undone. An agent that signs and broadcasts a transaction without an enforcement layer before it can exceed its authorised value, call a contract it was never provisioned to reach, or drain a wallet in a runaway loop, and by then the funds are gone. A transaction guard intercepts each proposed transaction before signing, checks it against value bounds, a contract allowlist, a gas or compute-unit limit, and a replay-protection nonce, and refuses to sign anything that falls outside declared policy.

Last reviewed 2026-05-14 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
edge · seam
Restricted to edge kinds: external-call
COVERAGE
6 threats
T26 · T32 · T33 · T34 · T36 · T37
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Every blockchain transaction the agent proposes goes through a pre-commit guard before it is signed and broadcast. Never sign first and audit later.
  • The guard inspects target address, function selector, value bounds, and contract allowlist against a declared policy; anything outside policy is rejected.
  • Pre-broadcast simulation against a forked chain state surfaces reverts, unexpected state changes, and gas anomalies before the transaction touches the mempool.
  • Pair an off-chain policy engine (caught early, easy to update) with an on-chain Safe Guard contract (cannot be bypassed by a compromised signing key) for institutional deployments.

How it behaves

Agent proposes a blockchain transaction (target, function, value, args)
Check target allowlist, value bound, function selector, and simulation result against policy
Sign and broadcast
Refuse to sign; log denial reason
Run the simulation step after off-chain policy checks pass and before the final signing call.

What it is

A blockchain transaction guard is a pre-commit inspection layer that every agent-initiated blockchain transaction must pass before it is signed and broadcast to the network. Because a committed blockchain transaction is irreversible, all enforcement must occur before the transaction leaves the agent's signing environment: there is no rollback path once it is on-chain.

The guard enforces five check classes:

  1. Value bounds, the native-token or token value transferred does not exceed a per-session or per-period limit, configurable per agent identity and action class.
  2. Contract allowlist, the transaction target address is on a pre-approved allowlist; any call to a non-allowlisted address is denied regardless of the agent's stated justification.
  3. Gas and compute-unit limit, the gas limit (EVM chains) or compute units (Solana) requested does not exceed a per-transaction maximum, preventing runaway computation from accumulating on-chain cost.
  4. Replay-protection nonce, the transaction nonce is monotonically increasing and consistent with the wallet's on-chain state; gaps or re-used nonces are rejected before signing.
  5. Finality confirmation, reads that inform agent decisions require N-block confirmation before being treated as settled, configurable per chain.

Together these five checks mean a misbehaving or manipulated agent cannot commit a transaction outside its authorised scope. An agent acting erratically cannot reach a contract it was not provisioned to call, and an agent caught in a runaway loop reaches the gas or value limit before doing lasting damage.

Detection signals

  • Transaction guard denials per agent per session. A sustained rate points to a misbehaving agent, a prompt injection redirecting the agent toward a non-allowlisted contract, or a runaway loop hitting the value limit.
  • Contract allowlist misses per agent. Each miss is a potential prompt-injection signal: an agent being directed at a contract it was never provisioned to reach.

Threats it covers

  • T26 Model Instability Leading to Inconsistent Blockchain Interactions −1 severity step

    WHY IT HELPS Model Instability on-chain is the risk that an agent whose model has drifted or degraded begins issuing erratic transactions. The transaction guard's value bounds and contract allowlist constrain that erratic behaviour structurally: a drifted agent cannot commit a transaction that exceeds its value limit or targets a contract outside its approved set.

  • T32 Runaway Agent on Solana −2 severity steps

    WHY IT HELPS Runaway Agent on Solana (or any chain) requires the ability to issue transactions at unconstrained rate and value. The transaction guard's gas and compute-unit limit and per-session value ceiling are the direct structural controls: a runaway agent that reaches those limits produces a denied transaction, not a committed one.

  • T33 Blockchain Reorganization Attack (Indirect) −1 severity step

    WHY IT HELPS Blockchain Reorganisation exploits the window between transaction broadcast and finality. Requiring N-block confirmation before treating a transaction as settled reduces the reorg exploitation window. The guard does not eliminate reorgs below the confirmation threshold, but it prevents the agent from acting on unconfirmed state.

  • T34 Wallet Key Compromise −1 severity step

    WHY IT HELPS Wallet Key Compromise allows an attacker to submit arbitrary transactions through the compromised signing key. The transaction guard's per-session value limit and contract allowlist bound the financial exposure until the key is rotated. This is a partial mitigation: it does not prevent the compromise or detect it.

  • T36 Smart Contract Vulnerability Leading to Agent Impersonation −1 severity step

    WHY IT HELPS Smart Contract Vulnerability exploited for agent impersonation is partially bounded when every agent-initiated call passes the transaction guard: the contract allowlist rejects calls to non-approved addresses, and value bounds limit damage from a vulnerable contract that an attacker redirects the agent toward.

  • T37 Cross-Chain Bridge Attack (Indirect) −1 severity step

    WHY IT HELPS Cross-Chain Bridge Exploitation requires submitting a transaction to the bridge contract. The transaction guard's contract allowlist and value bounds gate every bridge-bound transaction before broadcast, reducing the attacker's operational window to transactions that fall within those declared limits.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Reversibility / Dry-run / Hold periods The transaction guard is a pre-commitment gate placed at the one point where blockchain irreversibility can still be avoided: by refusing to sign any transaction that falls outside declared policy, it prevents the committed outcome rather than attempting to undo it.
  • Safety / Harm-limitation An agent with blockchain signing authority can cause immediate, permanent financial harm if a single transaction is misdirected or unconstrained. The transaction guard enforces the safety boundary structurally, refusing to sign transactions that exceed value limits or target non-approved contracts, so no individual reasoning error or prompt manipulation can produce a committed harmful outcome.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Five deployment options covering off-chain policy engines, on-chain guard contracts, simulation APIs, detection infrastructure, and typed-data validation. The off-chain layer (Defender or Tenderly) catches most issues before broadcast; the on-chain layer (Safe Guard) enforces at the wallet for institutional deployments. Use at least one of each.

OpenZeppelin Defender Managed platform for authoring, simulating, and monitoring agent-initiated EVM transactions. Transaction Proposals enforce a human-or-policy approval step before broadcast; Defender Monitor raises alerts on on-chain events that match a defined condition.

Why choose it: Best when your agent targets EVM-compatible chains (Ethereum, Polygon, Arbitrum, Base) and you want a hosted approval workflow with no infrastructure to operate. The simulation step runs the transaction against a forked chain state before submission, surfacing reverts and unexpected state changes. Monitor rules close the detection loop: a transaction that passes all policy checks still triggers an alert if it moves funds above a threshold or calls an unexpected function.

More details:

Tenderly Simulator API JSON-RPC compatible simulation endpoint that replays a signed or unsigned transaction against a forked chain snapshot, returning execution traces, gas used, state diffs, and revert reasons without broadcasting anything.

Why choose it: Best as the simulation leg of a custom guard when you want to run your own value-bound and allowlist checks in application code but need an authoritative answer about whether the transaction will revert before signing. Supports all EVM-compatible chains and returns structured traces your guard policy can inspect. Call it after off-chain policy checks pass and before the final eth_sendRawTransaction.

More details:

Forta Network Decentralised threat-detection network where community-contributed and custom detection bots monitor on-chain activity in real time and emit alerts to a subscribed endpoint or webhook.

Why choose it: Best as the detective complement to your pre-commit guard: Forta runs after broadcast and catches anomalies the pre-commit layer missed (a transaction that passed all policy checks but triggered unexpected contract state, or a series of individually-small transfers that constitute a drain). Pre-built bots cover large-value transfer detection, flash-loan patterns, rug-pull signatures, and anomalous ERC-20 approval grants. Deploy a custom bot that alerts whenever your agent wallet calls a contract outside the expected set.

More details:

Gnosis Safe + Guard Contract A Safe Guard is a smart contract implementing the ITransactionGuard interface and registered with a Gnosis Safe multisig; every transaction the Safe executes calls checkTransaction on the guard before execution and checkAfterExecution after.

Why choose it: Best for institutional deployments where the wallet is a Gnosis Safe and you need policy enforcement to survive a compromised off-chain agent process. Because the guard runs inside the EVM as part of the Safe's execution flow, it cannot be bypassed by an attacker who gains control of the agent's signing key. Implement value bounds, contract allowlists, and caller-identity checks directly in checkTransaction. Adds roughly 5 to 15k gas per guard invocation. Requires Safe contracts v1.3.0 or later.

More details:

EIP-712 Typed-Data Validation Require the agent to construct every transaction payload as an EIP-712 typed structured-data object and validate the schema, values, and target address against a policy before signing with eth_signTypedData_v4.

Why choose it: Best when you want to enforce a strict schema contract between the agent's planning layer and its signing layer. Because EIP-712 types are declared in the payload and hashed into the signature, any mutation of the transaction after schema validation (a prompt-injection attack that changes the target address) produces a signature mismatch detectable at broadcast. Works on all EVM chains without an external service dependency; suitable for air-gapped or latency-sensitive deployments.

More details:

Trade-offs

  • The off-chain pre-commit layer adds latency before broadcast: Tenderly simulation typically returns in 200 to 600 ms; Defender approval workflows add minutes if human approval is required. Design the agent's task planner to treat the guard as a synchronous gate, not a fire-and-forget step.
  • On-chain Safe Guard enforcement adds gas cost per transaction (roughly 5 to 15k gas). At typical gas prices this is negligible for high-value institutional transactions; disproportionate for high-frequency, low-value micro-transactions. Match the enforcement layer to the transaction profile.
  • Allowlist maintenance is a persistent operational burden: every new contract or counterparty requires a policy update. For deployments where the agent's contract set evolves rapidly, an unmaintained allowlist drifts toward being meaningless. Budget for a review cycle tied to agent capability releases.
  • Value bounds set at the transaction level do not prevent an agent from sending many small transactions below the per-transaction limit. Pair with m-rate-quota to enforce aggregate per-period value ceilings.

When NOT to use

  • Do not apply a blockchain transaction guard to read-only agents that never sign transactions: the guard has no transaction to intercept.
  • Do not add an application-layer guard when the wallet is already a Gnosis Safe with a registered Safe Guard contract that enforces the same policy: two independent allowlists that must be kept in sync are worse than one.
  • Do not require on-chain simulation for Solana micro-transaction agents where the compute unit cost of simulateTransaction exceeds the value of the transaction itself; accept the risk and enforce only value bounds and the compute-unit limit.

Limitations

  • The guard inspects the agent's proposed transaction, not what the chain will ultimately execute. Smart contract state can change between simulation and broadcast, so a transaction that passes all checks can still revert or produce unexpected state changes.
  • The contract allowlist cannot block semantic manipulation: a transaction within all policy bounds that sends value to a correctly allowlisted contract but for the wrong purpose (a prompt-injection attack that changes the function arguments) passes the guard. Pair with output validation on the agent's planning layer.
  • Forta detection bots are reactive: they fire after broadcast. A transaction that drains a wallet in a single call is not preventable by Forta; only the pre-commit guard layer prevents it.
  • EVM-specific mechanisms (EIP-712, Defender, Safe Guard) do not transfer to non-EVM chains. Solana agents require separate Squads multisig policy or custom program-level checks; Cosmos chains use CosmWasm or module-level authz grants. There is no cross-chain guard standard as of mid-2026.

Maturity tier reasoning

  • Tier 2 fits because the individual primitives (OpenZeppelin Defender, Tenderly Simulator, Forta detection bots, Gnosis Safe Guards, EIP-712 typed-data validation) are all production-available and documented by their respective maintainers.
  • What keeps the agentic application at Tier 2 is the absence of a standardised pre-commit guard API that spans blockchain ecosystems. EVM, Solana, Cosmos, and Aptos each require a different implementation; there is no canonical integration between agentic AI frameworks and blockchain signing pipelines.
  • Institutional DeFi tooling (Fireblocks TAP, BitGo policy engine, Copper ClearLoop) has solved this problem for human-operated custody; the agentic layer is an extension that has not yet been formally standardised.

Last verified against upstream docs: 2026-05-30.