EVIDENCE TRAIL
Blockchain transaction guard — pre-commit safety checks
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. Note: the MDX cites NIST IR 8202 §4.3 for "transaction validation as a core security control" — §4.3 is the Round Robin Consensus Model section; the cybersecurity content is in §7.5. This trail uses §7.5 and flags the discrepancy.
Last cross-checked against upstream sources: · 9 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Multi-Agentic System Threat Modelling Guide v1.0 — T32 Runaway Agent on Solana
§4 ElizaOS — Layer 3 Agent Frameworks · T32 Runaway Agent on Solana — Mitigations
"Enforce a hard per-time-window transaction ceiling (circuit breaker) that halts all submissions after N transactions in a rolling window, regardless of loop state. Monitor wallet balance continuously; alert and halt new submissions when balance drops below a defined reserve floor."
Supports: Names a per-time-window transaction ceiling as the primary structural control for a runaway agent. This is the on-chain analogue of the value-and-rate cap that the blockchain transaction guard enforces before broadcast.
Does not prove: Framing is specific to ElizaOS on Solana. Does not describe a pre-broadcast inspection layer; mitigations are loop-level controls, not a signed-transaction guard policy.
OWASP Multi-Agentic System Threat Modelling Guide v1.0 — T26 Model Instability Leading to Inconsistent Blockchain Interactions
§4 ElizaOS — Layer 1 Foundation Models · T26 Model Instability — Mitigations
"Validate all LLM outputs against a strict schema before submitting them as transactions or MCP tool calls; reject outputs that do not conform rather than attempting to normalise them. Implement an idempotency check before each transaction submission: verify that the intended action has not already been committed before sending a new request."
Supports: Establishes schema validation and idempotency checking as required pre-submission steps for blockchain-integrated agents — two of the five check classes in the transaction guard (schema maps to contract-allowlist and value-bounds validation; idempotency maps to nonce checking).
Does not prove: Does not describe a signed-transaction guard object or a gas/compute-unit cap. Schema validation and idempotency checking here are application-layer concerns; the guard operationalises them at the signing boundary.
OWASP Agentic AI — Threats & Mitigations v1.1 — T8 Repudiation & Untraceability
§T8 Repudiation & Untraceability — Scenario 1
"Scenario 1: Financial Transaction Obfuscation — An attacker exploits logging vulnerabilities in an AI-driven financial system, manipulating records so that unauthorized transactions are incompletely recorded or omitted, making fraud untraceable."
Supports: Names financial transaction obfuscation as a concrete T8 scenario in agentic AI. The transaction guard's denial log (every guard-rejected transaction with reason code) is the upstream audit artifact that makes this scenario detectable and attributable.
Does not prove: T8 is a logging/traceability threat, not a transaction-guard control. The scenario motivates the need for guard-level audit trails but does not define what the guard should inspect.
OpenZeppelin Contracts v5 — Pausable (utils/Pausable.sol)
NatSpec header comment — OpenZeppelin/openzeppelin-contracts/contracts/utils/Pausable.sol
"Contract module which allows children to implement an emergency stop mechanism that can be triggered by an authorized account. This module is used through inheritance. It will make available the modifiers `whenNotPaused` and `whenPaused`, which can be applied to the functions of your contract."
Supports: Provides the on-chain pause primitive — the `whenNotPaused` modifier is the enforcement point for halting agent-controlled contract execution. When the transaction guard's off-chain policy denies all submissions, `Pausable` is the on-chain complement that blocks contract-side execution of any transactions that still reach the chain.
Does not prove: Pausable is an on-chain mechanism; it does not inspect transaction parameters (value, target, gas, nonce) before broadcast. It is a post-broadcast halt, not a pre-commit guard. Cannot substitute for application-layer transaction validation.
Gnosis Safe — Smart Account Guards
Safe Docs — Advanced — Smart Account Guards
"Safe Guards are used when there are restrictions on top of the n-out-of-m scheme. The check before a transaction can programmatically check all the parameters of the respective transaction before execution."
Supports: Defines "programmatically check all the parameters of the respective transaction before execution" as the native Safe Guard contract capability. This is the on-chain expression of the same pre-commit inspection that the application-layer transaction guard implements off-chain. The institutional deployment variant of the Helmwart control uses a Safe Guard for wallet-level enforcement.
Does not prove: Safe Guards enforce on a per-wallet (Safe) basis; they do not address multi-chain deployments, Solana (which uses a different account model), or agent-specific policy fields (per-agent value caps, agent-identity allowlists). An on-chain guard also adds gas overhead that an off-chain pre-commit check avoids.
Solana RPC API — simulateTransaction
Solana RPC HTTP Methods — simulateTransaction — Description
"Simulates a signed transaction using the chain data available at the requested commitment, without broadcasting it."
Supports: Verbatim documentation of the Solana pre-broadcast simulation call referenced in the "How to deploy" section of the mitigation page. Confirms that simulateTransaction is a read-only dry-run that catches compute-unit overruns and program errors before any state is committed.
Does not prove: simulateTransaction validates execution feasibility and compute budget — it does not enforce application-layer policy (value bounds, contract allowlists, agent-identity checks). These must be checked in the application layer before calling simulateTransaction.
MITRE ATLAS AML.M0004 — Restrict Number of AI Model Queries
ATLAS catalogue — AML.M0004 description and technique-use note (AML.T0034)
"Limit the total number and rate of queries a user can perform. Limit the number of queries users can perform in a given interval to hinder an attacker's ability to send computationally expensive inputs."
Supports: Establishes rate limiting on AI model queries as a named ATLAS mitigation. The transaction guard's per-time-window transaction ceiling is the blockchain-specific application of this rate-limiting principle: capping the number of signed transactions the agent can submit per rolling window.
Does not prove: AML.M0004 addresses model query rate limiting (inference calls), not transaction-level rate limiting on a blockchain. The mapping is analogical — the principle transfers but the mechanism differs. Does not mention gas, nonce, or value bounds.
MITRE ATLAS AML.M0026 — Privileged AI Agent Permissions Configuration
ATLAS catalogue — AML.M0026 description
"AI agents may be granted elevated privileges above that of a normal user to enable desired workflows. When deploying a privileged AI agent, or an agent that interacts with multiple users, it is important to implement robust policies and controls on permissions of the privileged agent. These controls include Role-Based Access Controls (RBAC), Attribute-Based Access Controls (ABAC), and the principle of least privilege so that the agent is only granted the necessary permissions to access tools and resources required to accomplish its designated task(s)."
Supports: Names RBAC, ABAC, and least-privilege as required controls for privileged agents. The transaction guard's contract allowlist and per-agent value cap are the blockchain-specific expression of least-privilege: an agent is granted signing authority only for the contract addresses and value amounts required by its designated task.
Does not prove: AML.M0026 defines the permission framework; it does not specify that permissions should be enforced at transaction-signing time, or that a guard should inspect the signed transaction before broadcast. The Helmwart control operationalises the principle at the signing boundary.
NIST IR 8202 — Blockchain Technology Overview
§7.5 Cybersecurity
"The use of blockchain technology does not remove inherent cybersecurity risks that require thoughtful and proactive risk management. Existing cybersecurity standards and guidance remain highly relevant for ensuring the security of systems that interface and/or rely on blockchain networks."
Supports: Establishes that standard cybersecurity controls remain necessary for blockchain-integrated systems and that existing standards apply. Motivates applying pre-commit inspection (a standard software security control) to agent-initiated blockchain transactions. The MDX page cites this document for "transaction validation as a core security control."
Does not prove: The cited section §4.3 in the MDX is the Round Robin Consensus Model section — it contains no text about transaction validation or security controls. The relevant cybersecurity content is in §7.5. NIST IR 8202 is also a general overview (2018) that does not address AI agents or pre-commit guard patterns.