T37 · Helmwart ID · OWASP MAS Guide source
An attacker exploits a vulnerability in a cross-chain bridge to steal funds or disrupt coordination between agents operating across different blockchains.
ExtendsT17: Supply Chain Compromise · base threat in OWASP v1.1 catalog
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
AML.T0010AI Supply Chain Compromiseview 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.T0109AI Supply Chain Rug Pullview 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.T0049Exploit Public-Facing Applicationview 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.
Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.
Press play. The voice downloads once, then it’s cached.
On-device · private