Runaway Agent on Solana

OWASP Top 10 for Agentic Applications 2026

The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T32 is covered by the following Top 10 entries:

• ASI02 Tool Misuse and Exploitation contributing

  An agent applies authorised tools in ways their operator did not intend, driven by prompt injection, misaligned reasoning, or manipulated tool outputs. Every individual call looks clean; the harm is in the sequence: data exfiltrated via successive reads, workflows hijacked by parameter tampering, or a legitimate API weaponised across turns.

  OWASP LLM Top 10: LLM06:2025
• ASI06 Memory & Context Poisoning related

  An adversary writes malicious or misleading data into an agent's persistent memory or shared vector store, so that every future session, and every peer agent reading from the same store, operates on corrupted context. The defining difference from single-turn injection (ASI01) is that the poisoned data survives session reset; the agent's reasoning drifts without any new attacker input.

  OWASP LLM Top 10: LLM01:2025LLM04:2025LLM08:2025

Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.

Design principles at stake

When T32 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.

• Defence-in-Depth The runaway loop exploits the fact that autonomous operation removes the human throttle on transaction submission, and the agent's own loop logic is the source of the overload: so no external attack detection is needed. Relying on a balance-threshold alert alone fails because costs accumulate to significant levels before any single alert fires. Depth means idempotency checks before every submission so the loop cannot re-issue a transaction that already succeeded, a hard circuit breaker that halts submissions after N transactions in a rolling window regardless of loop state, a wallet balance floor that halts new submissions independently of the loop counter, and bounded retry handlers with exponential back-off: each layer stopping a different variant of the runaway before the others are needed.
• Rate-limiting / Budgets / Loop prevention The transaction fee accumulates at hundreds of submissions per minute because neither the polling interval guard nor a per-time-window ceiling is enforced, and the agent's completion bias prevents it from self-stopping once the loop is entered. A hard per-time-window transaction ceiling (a circuit breaker that halts all submissions after N transactions in a rolling window) is the externally-enforced rate control that does not depend on loop state or on-chain confirmation events. Combined with bounded retry handlers and exponential back-off, these controls ensure that even a state-synchronisation failure that causes the agent to believe a transaction never executed cannot produce unbounded financial losses, because the rate ceiling trips before the wallet is drained.

Recommended mitigations

Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T32, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).

• Tier 2 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.

  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.

• Tier 2 Kill switch (Kill switch: human authority to halt one agent, a class, or the entire deployment)

  Agentic systems can act faster than a human can intervene through normal channels. A kill switch is the operational guarantee that a named human role can stop agent activity at any scope (single instance, class, or global) through a documented runbook, without requiring a code change or redeployment, and with every invocation written to an audit trail.

  why it helps An agent interacting with a blockchain can enter a self-reinforcing transaction loop, submitting transactions faster than any on-chain mechanism can interject. The kill switch stops the agent process before the loop compounds. It provides that authority without requiring a code deploy or an on-chain intervention, which may be unavailable or too slow.

Red-team pivot: MITRE ATLAS techniques

MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.

Related threats

• T4: Resource Overload
• T25: Workflow Disruption via Dependency Exploitation
• T39: Unintended Resource Consumption via MCP

References

• OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 3 Agent Frameworks.

Sources

• OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 3 Agent Frameworks