Definition
An attacker exploits a vulnerability in a cross-chain bridge to steal funds or disrupt coordination between ElizaOS agents (an open-source multi-agent operating system) operating on different blockchains. Cross-chain bridges are the ecosystem-level infrastructure through which assets and messages move between chains; they are an indirect supply-chain dependency of any ElizaOS deployment that spans multiple blockchains.
What it looks like in practice
An ElizaOS agent initiates a cross-chain transfer, locking assets in a bridge smart contract on Solana and expecting them to be minted on the destination chain. An attacker monitors the bridge’s mempool, identifies the in-flight transfer, and exploits a reentrancy vulnerability in the bridge’s locking contract to drain the locked assets before the cross-chain message reaches the destination. The agent receives no minted assets on the destination chain; the source assets are gone. Because the transfer was committed autonomously at a high frequency as part of a multi-step strategy, the total exposure may span several in-flight transfers simultaneously.
Why it’s dangerous in multi-agent context
ElizaOS agents that operate across multiple blockchains depend on bridges as trusted intermediaries. An agent that has committed assets to a cross-chain transfer has no ability to halt or reverse it once in-flight if the bridge is compromised mid-transit. Because agents initiate cross-chain operations autonomously and at high frequency, the volume of assets in transit at any given time may be substantial. Downstream agents on the destination chain that expected the transferred assets as inputs to their own strategies are also disrupted. The bridge failure cascades through the multi-chain agent ecosystem. T38 (Emergent Collusion on Blockchain) can compound the effect if multiple agents simultaneously route through the same bridge, concentrating exposure.
Detection signals
A bridge attack leaves a trail across two chains simultaneously: assets disappear from the source chain without materialising on the destination chain within the expected settlement window.
- A cross-chain lock event on the source chain (Solana) that has no corresponding mint or unlock event on the destination chain within the bridge’s published settlement time limit: implement a per-transfer reconciliation check that fires an alert after the deadline passes.
- The bridge’s locking contract receiving a re-entrant call within the same transaction that initiated the lock: monitor the call stack depth of bridge contract interactions for intra-transaction self-calls.
- Total in-flight transfer value across all agents simultaneously exceeding a defined ceiling: aggregate in-flight exposure across the fleet and alert when the combined value crosses the threshold.
- Bridge contract balance on the source chain dropping faster than the sum of agent-initiated lock events explains. A difference between application-layer records of initiated transfers and the contract’s actual balance indicates unauthorised drains.
- The bridge provider’s own status page or on-chain incident contract (if provided) signalling a halt or anomaly: agents should subscribe to bridge health signals and pause autonomous cross-chain activity on any degradation.
Mitigations
- Audit and select bridges with a strong public security track record and formal verification of bridge contract logic.
- Bound the value of any single autonomous cross-chain transfer; require human approval above a defined threshold.
- Monitor in-flight cross-chain transfers; implement a reconciliation path that alerts if destination-chain minting does not occur within the expected window.
- Distribute exposure across multiple bridge providers rather than routing all cross-chain volume through a single bridge.
Relation to base threat (T1–T17)
T37 extends T17 Supply Chain Compromise. Where T17 addresses the broad class of supply-chain attacks on agent components (frameworks, plugins, tools), T37 is the cross-chain bridge instantiation: the bridge is an infrastructure supply-chain dependency that, when compromised, directly affects the assets and state of all agents that use it. T36 (Smart Contract Vulnerability Leading to Agent Impersonation) covers the analogous risk at the agent’s own contract layer rather than the bridge layer.
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. T37 is covered by the following Top 10 entries:
-
ASI07 Insecure Inter-Agent Communication contributing Agents in a multi-agent system pass instructions, results, and context to one another across APIs, message buses, and shared state. Without per-message authentication and integrity controls, a single compromised peripheral agent becomes an injection source for every peer it can reach. One hop becomes n-hop, and the orchestrator is reachable from the outside.
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 T37 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 Once assets are committed to an in-flight cross-chain transfer, the agent has no ability to halt or reverse the operation if the bridge contract is exploited mid-transit. Because agents initiate these operations autonomously and at high frequency, multiple transfers may be simultaneously exposed. Relying on bridge security alone is a single point of failure with no fallback. Depth means selecting bridges with formal verification of contract logic as the prevention layer, bounding the value of any single autonomous cross-chain transfer and requiring human approval above a threshold as an independent gate, monitoring in-flight transfers with an alert when destination-chain minting does not occur within the expected window as the detective layer, and distributing exposure across multiple bridge providers so that a single bridge failure cannot exhaust the entire cross-chain position.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T37, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
-
An agent that has been compromised, poisoned, or gone rogue will, in most cases, behave differently from its established baseline. Anomaly isolation acts on that difference: when an agent's behaviour score crosses a configured threshold, it is quarantined automatically, credentials revoked, message-queue access cut, in-flight actions aborted. Manual revocation cannot match the speed that cascading multi-agent failures demand.
why it helps Cross-chain bridge attacks produce observable anomalies, unexpected asset flows, message-relay patterns inconsistent with declared bridge logic. Anomaly isolation quarantines the orchestrating agent automatically when bridge-interaction patterns diverge from baseline.
- 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 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.
-
An inter-agent message travels through channels and intermediate agents the receiver did not originate. If nothing binds the message cryptographically to its source, any intermediate hop can substitute or inject content that the receiving agent will treat as authoritative. Message signing closes that gap: the source agent signs each message payload with its private key, and the receiver verifies the signature against a distributed trust bundle before the content reaches the reasoning layer.
why it helps Cross-chain bridge relay messages signed by the originating agent cannot be substituted in transit by a relay-layer attacker, because the receiving chain validates the signature before accepting the cross-chain instruction.
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.
AML.T0010 AI Supply Chain Compromise view on ATLAS ↗ Adversary tampers with components in the AI supply chain (datasets, model weights, libraries, container images) to compromise downstream systems before deployment.
Agentic angle: Agentic systems compose models, MCP servers, agent registries, and prompt templates at runtime. Every dependency is a potential vehicle for compromise.
AML.T0109 AI Supply Chain Rug Pull view on ATLAS ↗ Adversary publishes legitimate AI components to gain adoption, then replaces them with a malicious variant, exploiting the trust established before the switch.
Agentic angle: Trusted MCP servers or model registries used by agents are high-value rug-pull targets because agents fetch and execute without further human review.
AML.T0049 Exploit Public-Facing Application view on ATLAS ↗ Adversary exploits a vulnerability in an internet-facing service to gain initial access. For AI systems this often means the inference API or its surrounding web application.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 7 Agent Ecosystem.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 7 Agent Ecosystem