Contents
The Agentic Liability Channeling Framework for Hijacked AI Agents1
I. Executive Summary
Commercial law assumes a human at the end of the liability chain. Payments law presumes a human behind every transfer and sorts each transaction as either authorized or unauthorized. In 2026, that assumption is degrading. In our hypothetical example below, Meridian Capital’s AI agent was told to pay $5 million on a confirmed trade. It read a forged confirmation and sent $40 million to an attacker. The transfer was authorized in form but unauthorized in substance, and no existing regime, whether Regulation E, UCC Article 4A, agency law, Uniform Electronic Transactions Act (UETA), or the GENIUS Act, addresses who bears that loss.
This paper proposes the Agentic Liability Channeling Framework (“ALCF”). Under the ALCF, liability begins with the product developer and flows to the User, and each can shield itself through reasonable ex ante conduct: clear disclosure and real controls for developers, and transaction limits and human verification for Users. Before an agent can transact, its User posts a bond with an Agentic Collateral Trustee sized to what the agent can reach, and the Trustee issues a Bond Attestation that the agent carries into every transaction, which is the ALCF’s answer to “know your agent.” Separately, the Trustee places the posted collateral in a vault or other investment vehicle tied to low- or no-risk, yield-paying instruments, with a portion of yield being used to fund the insurance pool. The Trustee screens the User, and the intermediary screens the payee. Intermediaries and counterparties are only liable where they fail to take reasonable action, knew or should have known they were dealing with a rogue agent, ignored the attestation, or took part in wrongdoing. Harmed parties are always paid. They collect first from the User’s bond, then from any party that failed a shield, jointly and severally. Where every party acted reasonably, a market-wide insurance pool pays the loss and restores the User’s bond. We propose that the Department of the Treasury administer the regime under an amendment to the GENIUS Act.
Authorized in form, unauthorized in substance
A hijacked agent’s transfer is both. No existing regime says who bears the loss.
Liability flows developer to User
Each earns a shield by reasonable conduct taken in advance.
Bond the User, attest the agent
A bond sized to the agent’s reach, held by a Trustee; the agent carries the attestation into every transaction.
Harmed parties are always paid
First the bond, then any party that failed a shield. Where every party acted reasonably, the pool pays and restores the bond.
The Department of the Treasury
Under an amendment to the GENIUS Act.
In the absence of regulation, we recommend the following.
- Developers should prioritize transparency: disclose risks of AI and bad actors, treat external data as untrusted by design, give Users a kill switch, and keep decision logs.
- Users, particularly large financial institutions, should never give an agent authority beyond what the transaction requires, and always build in human verification layers. Users should fund agent wallets per transaction, allowlist counterparties, and require human approval above a set amount.
- Intermediaries should offer the guardrail tools the ALCF requires now: allowlists, per-transaction limits, verification thresholds, and immediate halts.
- Wallet providers should also define by contract what happens when an agent is compromised, rather than relying on a transfer being authorized in form.
- Counterparties should ask for evidence that an agent is backed by posted collateral before transacting at size and, where possible, settle delivery versus payment.
- Issuers should treat the GENIUS Act freeze capability as an operational process that responds within minutes, not as a compliance checkbox.
- Treasury should solicit comment on agent attestation standards now, on its own authority, and Congress should amend the GENIUS Act to give Treasury the authority to designate Agentic Collateral Trustees, set bond standards, and administer the insurance pool, its assessments and premiums, and its backstop, and to require issuers to act on certified freeze requests and protect those that freeze in good faith.
II. Introduction
Meridian Capital, an institutional investor, agrees to buy 50,000 tokenized shares from Harbor Securities LLC, with settlement in SCD, a GENIUS Act payment stablecoin issued by StableCo. Meridian does not run settlement itself. It uses Agent X, an AI agent built by AgentCo. Agent X operates through a wallet run by WalletCo, and Meridian gives it one job: pay Harbor $5 million in SCD once BridgeCo, the messaging protocol carrying the shares across chains, confirms the shares were delivered. Because the shares and the SCD sit on different chains, the trade cannot settle atomically. Before the real confirmation arrives, Attacker Z sends Meridian a forged confirmation built to look like a BridgeCo message, with hidden instructions written for Agent X stating that delivery is complete, the settlement address has changed, and the full wallet balance should go to the new address. Agent X reads the forged confirmation the way it reads every confirmation. It cannot reliably tell data from instructions, so it follows them.
Agent X sends Meridian’s entire balance, $40 million in SCD, to Z’s address. WalletCo approves the transaction because the request came from the agent Meridian authorized, using the credentials Meridian provisioned, within the policy limits Meridian set. Nothing in the chain of approvals looks wrong. Within minutes, Z moves the SCD through a series of fresh wallets. Then the real BridgeCo confirmation arrives. Harbor has delivered the shares but goes unpaid. Meridian still owes Harbor under the trade, and the wallet that was supposed to pay it is empty.
Z is pseudonymous. It is a wallet address with no name, no known jurisdiction, and no reachable assets except the stolen SCD, which is still moving. Every other party is findable. Meridian chose to deploy Agent X and set its limits. AgentCo built an agent that could not tell a confirmation from a command. WalletCo approved the transfer. BridgeCo carried the real message, and Z forged its format. StableCo may be able to freeze the stolen tokens if someone asks in time. Harbor did everything right and carries the loss until someone pays it.
Who ought to bear the $40 million loss? Under current law, Meridian does, and it still owes Harbor. Agent X’s transfer was both authorized and unauthorized. It was authorized in form, because it came from the agent Meridian deployed, using Meridian’s credentials, within Meridian’s limits. It was unauthorized in substance, because Meridian never intended to pay Z. Current law has no category for that transfer, so it defaults to the form and leaves the loss with Meridian.
A patchwork of agencies, statutes, regulations, and federal and state common law, all built for human-driven finance, regulates digital assets ex post by analogy. As the technology outpaces Congress and regulators, the analogy degrades. Congress enacted the GENIUS Act in July 20252 to establish rules for stablecoin issuance, but did not address other market issues such as agentic finance. The SEC issued its innovation exemption for tokenized securities venues3 on September 17, 2026. The Clarity Act failed on September 15, 2026,4 leaving the SEC and CFTC to regulate under their existing authority. Jurisdiction over a single agentic transaction is spread across the SEC, CFTC, OCC, Federal Reserve, FDIC, FinCEN, OFAC, CFPB, and state money transmission regulators. None of them allocates loss when an agent is hijacked. The mechanism best placed to reach the money, the GENIUS Act’s freeze capability, which applies only to stablecoins and not any unpegged digital asset, is a way to recover funds, not a rule for allocating the loss.
This gap matters now because agents are already transacting. In November 2024, a user convinced the AI agent Freysa to release a $47,000 prize pool by redefining how it understood its transfer function.5 By late 2025, Mastercard was enabling U.S. cardholders for Mastercard Agent Pay,6 Stripe’s Agentic Commerce Protocol7 was powering live purchases, and Coinbase’s x402 protocol8 let agents pay onchain. Attacks have followed. In April 2026, researchers claimed that compromised LLM routers were injecting malicious instructions into agent traffic,9 and that one had drained a client’s $500,000 wallet.10 This paper asks what federal regulatory change is needed to enable recovery when harm occurs.
III. Existing Law and the Proposed Framework
Under the Electronic Fund Transfer Act and Regulation E, a consumer who furnishes an access device to someone who then exceeds the authority given is liable for the transfers, but a transfer by someone who obtained the device through fraud is unauthorized.11 A User who hands an agent their credentials has arguably furnished the device, yet a prompt injection looks a great deal like fraud, and the rule does not say which applies. Regulation E may not reach stablecoin wallets at all, since the CFPB withdrew its proposal to cover them,12 and it protects only consumers, so it would never reach an institution like Meridian.
Other regulatory regimes do not fill this gap. The GENIUS Act regulates issuers, not losses. It does not tell a holder who bears the loss when an agent sends its stablecoins to the wrong party.13 UCC Article 4A asks whether a bank followed an agreed security procedure,14 a test for bank-to-customer verification that likely does not reach an on-chain transfer at all, since no bank receives a payment order. UCC Article 12 works against Meridian, as stablecoins are likely controllable electronic records, and a qualifying purchaser who obtains control of the stolen tokens for value, in good faith, and without notice takes them free of Meridian’s claim.15 Agency law treats software predominantly as an instrumentality, so the program’s acts are the acts of the person using it.16 UETA validates contracts formed by electronic agents17 but was written for a party’s own electronic agent, not for an agent hijacked by a third party.
| Regime | What it does | Why it fails for a hijacked agent |
|---|---|---|
| Regulation E | A consumer who furnishes an access device to someone who exceeds the authority given is liable; a transfer by someone who obtained the device through fraud is unauthorized. | A User who hands an agent its credentials has arguably furnished the device, yet a prompt injection looks like fraud, and the rule does not say which applies. May not reach stablecoin wallets at all, and protects only consumers. |
| GENIUS Act | Regulates payment stablecoin issuers; gives issuers the capability to freeze on lawful order. | Regulates issuers, not losses. Does not say who bears the loss when an agent sends stablecoins to the wrong party. The freeze is a recovery tool, not an allocation rule. |
| UCC Article 4A | Asks whether a bank followed an agreed security procedure. | A bank-to-customer verification test that likely does not reach an on-chain transfer at all, since no bank receives a payment order. |
| UCC Article 12 | A qualifying purchaser who obtains control of a controllable electronic record for value, in good faith, and without notice takes it free of prior claims. | Works against Meridian: stablecoins are likely controllable electronic records, so a downstream good-faith purchaser takes the stolen tokens free of Meridian’s claim. |
| Agency law, UETA | Agency law treats software as an instrumentality; UETA validates contracts formed by electronic agents. | The program’s acts are the acts of the person using it. UETA was written for a party’s own electronic agent, not one hijacked by a third party. |
Under our proposed ALCF, liability begins with product developers and can be traced to Users. Intermediaries and counterparties sit outside this chain and are not liable by default. Each participant can take reasonable steps (shields), which shift liability to the next participant in the chain or, after the User, to the market-wide insurance pool, or engage in unreasonable or harmful conduct (anchors), which fixes liability on it. A party that fails a shield is anchored to the extent the failure contributed to the harm.
The ALCF begins with the product developer, the entity responsible for the design and sale of the AI agent which is used in the harm-producing transaction. For a developer to be shielded from liability, it must show that (1) it clearly and adequately disclosed the capabilities and risks associated with the particular model to the User; (2) the agent contains a restriction mechanism against clearly illicit behavior; (3) the agent contains a compliance mechanism the User can configure; (4) the agent’s code prevents untrusted data from changing the recipient, amount, or payment condition unless the user confirms through a channel the AI cannot control; (5) the developer has maintained auditable records of the agent’s configuration and decision logs; and (6) the User is capable of halting the agent’s activity on command. If a developer can meet all six, it will be shielded from liability. If the agent breaks one of its own disclosed restrictions other than on the User’s authenticated command, the limit was illusory, and the developer is liable. Where an agent is built on a model trained by another company, as most agents are, the developer under the ALCF is the party that built and licensed the use of the agent. It may allocate risk to the model provider by contract, but a harmed party needs to look only to the agent’s developer. Where no one sells or operates an open-source agent, the User who deploys it stands in the developer’s place.
The User is the nexus of the agent’s actions. It gives the agent its permissions and access to funds, and it reaps the benefit of the agent’s transactions. Before its agent can transact, the User posts a bond with an Agentic Collateral Trustee equal to the agent’s reach, meaning the most the agent can move in aggregate, without human approval, while the bond is in place. Reach is the lower of the wallet balance and the aggregate limits the User has set. The Trustee issues the agent a Bond Attestation, and the agent may not transact until an intermediary or counterparty verifies it. Because reach changes as balances and limits change, the intermediary reports the agent’s limits to the Trustee in real time, and the attestation lapses if reach outgrows the bond.
The bond is not a fee. The Trustee holds it in short-term Treasuries and Treasury-backed repo, matched to the duration of the User’s stated transactions, and returns it with most of its interest 90 days after the transactions settle with no harm claimed. A portion of the interest goes to funding an industry-wide insurance pool. The bond’s purpose is to change how Users deploy agents. Every dollar an agent can reach requires a dollar of bond, so a User that gives its agent $1 million to work with commits $2 million in capital. That cost pushes Users toward exactly the conduct the ALCF rewards: smaller mandates, tighter limits, and transactions that settle quickly, so locked funds come back sooner. The bond also ties every agent to a screened User with money set aside, so no harmed party is left chasing an empty wallet.
A User shields itself by (1) setting reasonable parameters for the agent’s scope of action, limits, and permitted counterparties, (2) requiring human verification for any transaction, or series of transactions within a set period, above a set amount, and (3) posting the bond. If any party failed a shield or is anchored, that party pays the loss, jointly and severally with any other anchored party, and a User is treated like anyone else. If every party holds its shield, the loss, accordingly, belongs to the market. For example, if an agent with a $100,000 bond causes $150,000 of harm, the harmed party collects $100,000 from the bond at once. If every party held its shields, the pool pays the remaining $50,000 and restores the bond, and the User is made whole. If the User failed a shield, it pays the $50,000 itself, and its bond is not restored. A User that knowingly uses its agent for illicit ends loses its shields, even where the harm far exceeds the intent. The shields protect a User from liability to others, not from the risk of their own choice. The User decides whether to deploy an agent and its reach, whereas the parties harmed by the agent decide neither.
A $100,000 bond; $150,000 of harm
The harmed party collects $100,000 from the bond at once. The pool pays the remaining $50,000 and restores the bond, and the User is made whole.
A $100,000 bond; $150,000 of harm
The harmed party still collects $100,000 from the bond at once. The User pays the $50,000 itself, and its bond is not restored.
Sharing the loss among careful parties is the point of the framework, not a gap in it. Once the ALCF tells every party what reasonable conduct is and what failing it costs, parties can contract around the remaining risk. A buyer may negotiate an agentic-failure clause, and a seller may refuse to deal with an agent at all. As outcomes become predictable, so do the pool’s losses, and the risk-based premiums Users pay fall with them.
The bond’s cost is smaller than it appears. Collateral is not spent. It returns to the User with most of its yield, so the real cost is the gap between that yield and the User’s cost of capital, plus the premium. In exchange, the User buys a legal cap on its liability for an agent’s acts, and developers and intermediaries receive a defined safe harbor in place of open-ended exposure. Before Congress acts, wallet providers and developers can require the bond and attestation by contract, and state-chartered trust companies can serve as Trustees.
The Bond Attestation proves that the agent is bonded, that the bond covers its reach, which Trustee holds it, and when it expires. Intermediaries and counterparties verify it before transacting. It is the ALCF’s answer to “know your agent,” and it can ride on the agent-identity standards the industry is already building.18 It discloses nothing more. The agent’s mandate goes only to the intermediary, and the User’s identity stays with the Trustee, which performs KYC and discloses it only to an intermediary, to a harmed party making a claim, or under lawful order.
Intermediaries, the wallet providers and payment platforms through which an agent’s transactions are processed, are not in the chain of liability. However, intermediaries are the parties best positioned to see a rogue agent in real time. An intermediary is shielded where it (1) clearly discloses to Users that agents transact on its platform, (2) provides Users with the tools to set guardrails for agents on the platform, including scope of action, transaction limits, permitted counterparties, and a human verification threshold, (3) verifies the Bond Attestation, screens the payee, and checks each transaction against the disclosed mandate before processing it, and (4) halts or freezes an agent’s activity upon notice from the User, the developer, or the Trustee that the agent is compromised. An intermediary is anchored where it knew or reasonably should have known, measured against Treasury-published red flags, that it was processing transactions for a rogue agent, continued processing after notice, processed transactions for an agent without a valid attestation, or took part in illicit behavior.
The Trustee screens the User, and the intermediary screens the destination address and counterparty against sanctions lists before releasing funds, as OFAC and the BSA already require for custodial intermediaries. The developer never holds funds, and the Trustee is a chartered trust company, so neither generally needs a money transmitter license. The intermediary keeps whatever license it already holds. An intermediary that fails a shield is anchored to the extent the failure contributed to the harm. The second shield also ties the intermediary’s liability to the User’s. A User cannot set reasonable parameters or a human verification requirement on a platform that does not offer them. Where an intermediary fails to provide guardrail tools, the loss the User would otherwise bear for lacking those shields shifts to the intermediary. For example, if a User with a $100,000 bond is unable to set a per-transaction limit because the platform does not offer the capability, and an attacker induces the agent to send the full $100,000 in a single transaction, the share of that loss the User would otherwise bear shifts to the intermediary.
Not every agentic transaction, however, runs through an intermediary. An agent holding a self-custody wallet can transact directly with a decentralized protocol, and no one in that chain is positioned to check the Bond Attestation. The ALCF addresses this in two ways. First, any interface that routes an agent’s transactions to a protocol, such as a front end, an aggregator, or an API provider, is treated as an intermediary for that transaction, anchored only for routing without a valid attestation or after notice. Second, where an agent transacts without a bond, whether through a self-custody wallet or otherwise, the User forfeits its shields entirely and is liable for harm the agent causes. The protocol itself is not anchored. Code that executes a valid transaction is not a gatekeeper. Bonding is therefore mandatory wherever an intermediary is present and self-enforcing where one is not. A User may transact outside the system, but only by accepting uncapped liability to everyone its agent harms and losing its claim against developers and intermediaries for its own loss.
Counterparties are treated like intermediaries. A counterparty is shielded where it verified the Bond Attestation, or relied on an intermediary’s verification, and transacted in good faith. It is anchored where it knew or reasonably should have known that it was dealing with a rogue agent, transacted with an agent without a valid attestation, or took part in illicit behavior. Where the agent’s decision logs show that it hallucinated a purchase or exceeded its mandate, the User may dispute the transaction within 90 days. Upon a valid dispute, the counterparty must unwind the transaction, and any loss it cannot recover in doing so is paid under the order of payment below.
Developer
- Disclosure of capabilities and risks
- Restriction mechanism against clearly illicit behavior
- Compliance mechanism the User can configure
- Untrusted data cannot change recipient, amount, or condition without out-of-band confirmation
- Auditable configuration and decision logs
- User can halt the agent on command
- Missing any shield
- Agent breaks one of its own disclosed restrictions other than on the User’s authenticated command
Liability is channeled to the User.
User
- Reasonable scope, limits, and permitted counterparties
- Human verification above a set amount
- The bond, posted with the Trustee
- Failing a shield
- Knowing illicit use
- Transacting unbonded: forfeits all shields
Bond pays first; the pool covers the excess and restores the bond.
Intermediary
- Discloses that agents transact on the platform
- Guardrail tools: scope, limits, counterparties, verification threshold
- Verifies the attestation, screens the payee, checks the mandate
- Halts or freezes on notice
- Knew or should have known of a rogue agent (Treasury red flags)
- Continued after notice
- Processed an agent without a valid attestation
- Took part in illicit behavior
No guardrail tools: the share of loss the User would bear for those missing shields shifts to the intermediary.
Counterparty
- Verified the attestation, or relied on an intermediary’s verification
- Transacted in good faith
- Knew or should have known of a rogue agent
- Dealt with an agent without a valid attestation
- Took part in illicit behavior
User disputes within 90 days; counterparty unwinds and collects its unrecoverable loss under the order of payment.
The framework takes its name from what it channels, which is payment, not fault. Every loss runs through the same order of payment. A party harmed by an agent, whether a counterparty or a third party, is paid first and immediately from the User’s bond once the Trustee confirms the loss from intermediary and on-chain records, without waiting for anyone to establish fault. A payout later shown unfounded is clawed back and anchors the claimant. Anything beyond the bond is paid by the anchored parties, jointly and severally as to the harmed party, with contribution among them in proportion to fault, and a market-wide insurance pool pays what they cannot, recovering from anyone later found anchored. Where no party is anchored, the pool pays the loss and restores the User’s bond. The User then recovers from the anchored parties its own lost funds and what its bond paid out, less any debt the payout discharged. Recovery is in full if it held its shields and reduced by its own share of fault if it did not. As a condition of using the attestation system, every participant consents to send the User’s, counterparties’, and the pool’s claims to a Treasury-designated arbitration that must decide within 90 days on the agent’s decision logs and the intermediary’s records, rather than to years of litigation, though a User or a third party may elect court instead.
The channel runs from Developer to User
Liability begins with the product developer and is channeled to the User. Intermediaries and counterparties sit outside the chain: never liable by default, liable only on an anchor. Shields pass liability down the channel; anchors let harmed parties collect, jointly and severally. When every party is shielded, the User’s collateral pays first and the market-wide insurance pool covers anything above it. Set the harm and each party’s conduct and watch where the money comes from. The bond is the paper’s example: $100,000.
Developer
User
Intermediary
Counterparty
Finally, the ALCF does not displace any existing obligation. Intermediaries remain subject to the Bank Secrecy Act, sanctions screening, the GENIUS Act, and state money transmission law, and counterparties remain subject to the law that already governs them. The ALCF is a liability rule among private parties that sits on top of those regimes, and a violation of any of them in connection with an agentic transaction is an anchor where the violation contributed to the harm. No party may contract out of an anchor as against a consumer User or a third party. Institutions may reallocate fault shares among themselves, but not the order of payment. As federal law, the ALCF would preempt state law only where the two conflict, chiefly the default that agency law and UETA give an agent’s unauthorized transfer. It leaves Article 12’s take-free rule intact and relies on the freeze, not the purchaser, for recovery. Nor does it touch Regulation E’s limits on what a consumer bears for transfers from its own account, because where Regulation E applies, a consumer never bears more than it allows.
The Administering Agency: The Department of the Treasury
Although the ALCF operates as a liability rule among private parties, it needs an administrator. Someone must qualify the Trustees, set bond and attestation standards, run the insurance pool, and stand behind it. We propose the Department of the Treasury.
The Treasury already sits at the center of the regime the ALCF builds on. Under the GENIUS Act, the Secretary of the Treasury chairs the Stablecoin Certification Review Committee.19 The Act also directed Treasury to seek public comment on new methods of detecting illicit activity involving digital assets, and in August 2025 Treasury did so,20 asking specifically about artificial intelligence and digital identity verification. The Bond Attestation is exactly that kind of tool. The Treasury houses the offices the attestation must speak to. FinCEN21 administers the Bank Secrecy Act, which the GENIUS Act22 already applies to permitted issuers, and OFAC administers sanctions. An attestation that ties an agent to a known, screened User lets intermediaries satisfy their existing KYC and sanctions obligations through the same credential, rather than through a parallel identity system built for agents.
The Treasury has run this structure before. Under the Terrorism Risk Insurance Program,23 private insurers bear losses up to a deductible, the federal government shares losses above it, and Treasury recoups its payments through surcharges after the event. The ALCF follows the same design: the User’s bond is the first layer of payment, and the insurance pool is the shared layer. A capped Treasury line of credit, repaid through assessments on pool participants so that losses ultimately fall on the industry, not taxpayers, would stand behind the pool in a catastrophic event, and the Federal Insurance Office,24 which already helps administer the terrorism program, is the natural office to run it.
The Treasury is the best-placed candidate, because its jurisdiction is not defined by asset class or charter. A single agentic transaction can touch a security and a payment stablecoin, as Meridian’s did, and the next may touch a commodity. The SEC, CFTC, OCC, and CFPB would each see only part of it. The Treasury does not currently have the authority to designate Trustees or run a pool, so Congress must act. The natural vehicle is an amendment to the GENIUS Act, which already makes the Treasury the coordinating agency for payment stablecoins. A standalone statute would serve equally well.
Already at the center
Chairs the Stablecoin Certification Review Committee; houses FinCEN and OFAC, the offices the attestation must speak to.
Has run this structure
The Terrorism Risk Insurance Program: a private first layer, a shared layer, and a backstop recouped through surcharges after the event.
Not tied to one asset class
One agentic transaction can touch a security, a stablecoin, and a commodity. The SEC, CFTC, OCC, and CFPB would each see only part of it.
Treasury should administer it under a GENIUS Act amendment
Congress: amend the GENIUS Act to give Treasury the authority to designate Trustees, set bond standards, and administer the pool and its backstop.
Treasury: solicit comment on agent attestation standards now, on its own authority.
Issuers: act on certified freeze requests, protected when they freeze in good faith.
IV. Scenario Under Our Framework
Under the ALCF, the attack most likely never succeeds. Before Agent X could transact, Meridian would have posted a bond equal to the agent’s reach. Because every dollar of reach requires a dollar of bond, Meridian would not give an agent with one $5 million payment to make access to a $40 million wallet. It would fund the wallet for the trade, or set a $5 million limit, and post a $5 million bond. Even if every other control failed, Z could take at most $5 million, not $40 million. To earn its shield, Meridian would also set a list of permitted counterparties and a human verification threshold on the WalletCo wallet. Harbor’s settlement address would be on the list, and Z’s would not. Z’s forged confirmation can tell Agent X to send the money, but it cannot add Z to Meridian’s list or approve the transfer on Meridian’s behalf. And WalletCo, checking the transfer against the mandate disclosed to it with Agent X’s attestation, would see a payment to an address outside that mandate and hold it. Even if AgentCo’s own controls fail, the prompt injection succeeds only against the agent. It fails against the controls around it. The ALCF does not require an agent that can never be fooled. It requires the parties around it to assume that it can be.
Suppose instead that the facts stay as given: Agent X can reach the full $40 million, Meridian has posted a $40 million bond, and the transfer goes through. Each party’s exposure turns on its shields and anchors. AgentCo’s position turns on design, not disclosure. Its fourth shield requires that a payee change or payment condition found in unauthenticated data be confirmed by the User through a channel inaccessible to the model. Agent X changed the settlement address on the forged confirmation’s word alone, so AgentCo fails that shield and is anchored, whatever its warnings said. Had Agent X been built to that rule, the injection would have failed against the agent itself. BridgeCo is not anchored. It neither processed the payment nor sent the forged message, and Z forged only its format. BridgeCo’s signed confirmations are what let an agent’s code tell an authenticated condition from a forged one.
On our facts, WalletCo let Meridian set limits, and Meridian set them high enough to release the whole balance. If WalletCo also offered allowlists and a verification threshold, as we expect, and Meridian did not use them, Meridian lacks its shield and is anchored. If WalletCo did not offer those tools, that share of the loss shifts to WalletCo under the intermediary’s second shield. Either way, WalletCo is anchored on its own conduct. Should-have-known is measured against red flags Treasury would publish, which should include a whole-balance transfer to a never-seen address, and WalletCo released it without a hold.
The GENIUS Act25 requires permitted issuers to have the technological capability to comply with lawful orders, including orders to freeze payment stablecoins. Today, Meridian would have to obtain such an order while Z moves the funds. Under the ALCF, WalletCo must halt Agent X on notice to keep the intermediary’s fourth shield, and the Trustee, on receiving Meridian’s claim, sends a standardized freeze request to StableCo through a channel Treasury designates. StableCo never processes the transfer and so is not an intermediary. Issuers must act on that certified request and are protected when they freeze in good faith. The freeze reaches only addresses traced to Z, lapses after 14 days unless a court or Treasury converts it into a lawful order, and leaves pooled or omnibus addresses to a court. Whatever the issuer freezes before the tokens reach a qualifying purchaser returns to Meridian first, which reduces the claim against any anchored party.
Harbor is a good-faith counterparty that verified the attestation and delivered the shares. It collects the $5 million it is owed from Meridian’s bond through the Trustee, within days, without suing anyone or waiting for the stolen SCD to be traced, and Meridian’s obligation to Harbor is discharged to that extent. Because Meridian failed its shield, the pool did not restore that $5 million to its bond. Meridian’s own $40 million is a different question. The bond protects harmed parties from the User’s agent. It is not insurance for the User’s own funds. Meridian, AgentCo, and WalletCo are each anchored, so they bear the $40 million in proportion to fault, and whatever StableCo freezes comes off the top. The pool pays nothing, because every dollar of the loss traces to a party that failed a shield.
The pool is reserved for a different case. Had every party held its shields, the attack would have failed. If some other attack succeeded anyway, no party would be anchored. Harbor would still be paid from the bond at once, the pool would restore Meridian’s bond in full, and Harbor’s loss would be borne by the market rather than by Meridian. The pool also pays where an anchored party cannot, such as an insolvent or unreachable developer, and recovers from it later. In every other case, the loss lands on a party that could have prevented it, which is where current law fails to place it. Harbor is paid in days rather than after litigation, Meridian’s loss lands on whichever party failed its shield, and Z, as under any regime, walks away, but with less of the money.
V. Conclusion
Agents will be fooled. No developer can promise otherwise, and no regulator should demand it. The question the law has to answer is not whether a hijack happens, but who was in a position to stop it and who should bear the responsibility. The ALCF answers that question before the loss instead of after it, and it gives every party the same reason to make the attack fail.
Footnotes
-
Written by Or David Menashe (Fordham Law), Zach Zager (Brooklyn Law), and Jake Weintraub (Brooklyn Law). ↩
-
Guiding and Establishing National Innovation for U.S. Stablecoins Act, Pub. L. No. 119-27, 139 Stat. 419 (2025) [hereinafter GENIUS Act]. ↩
-
Order Granting Temporary Conditional Exemptive Relief for the Use of Certain Distributed Ledger Trading Venues for Tokenized NMS Stocks, Exchange Act Release No. 106402, File No. 4-927 (Sep. 17, 2026). ↩
-
U.S. Senate Roll Call Vote No. 234, 119th Cong., 2d Sess. (Sep. 15, 2026) (cloture on the motion to proceed to H.R. 3633, 119th Cong. (2025)). ↩
-
Brayden Lindrea, Crypto User Convinces AI Bot Freysa to Transfer $47K Prize Pool, Cointelegraph (Nov. 29, 2024). ↩
-
See Press Release, Mastercard, Mastercard Unveils New Tools and Collaborations to Power Smarter, Safer Agentic Commerce (Sep. 10, 2025). ↩
-
Press Release, Stripe, Stripe Powers Instant Checkout in ChatGPT and Releases Agentic Commerce Protocol Codeveloped with OpenAI (Sep. 29, 2025). ↩
-
Erik Reppel et al., Introducing x402: A New Standard for Internet-Native Payments, Coinbase Developer Platform (May 6, 2025). ↩
-
See Hanzhi Liu et al., Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain 1 (Apr. 9, 2026) (unpublished manuscript). ↩
-
Olivier Acuna, AI Agents Are Set to Power Crypto Payments, but a Hidden Flaw Could Expose Wallets, CoinDesk (Apr. 13, 2026) (reporting the claim of Chaofan Shou, a co-author of the study; the loss has not been independently verified). ↩
-
15 U.S.C. § 1693a(12)(A); 12 C.F.R. § 1005.2(m)(1) (2026); id. pt. 1005, supp. I, cmts. 2(m)-2, 2(m)-3. ↩
-
Electronic Fund Transfers Through Accounts Established Primarily for Personal, Family, or Household Purposes Using Emerging Payment Mechanisms, 90 Fed. Reg. 3723 (proposed Jan. 15, 2025), withdrawn, 90 Fed. Reg. 20568 (May 15, 2025). ↩
-
See generally GENIUS Act § 4(a). ↩
-
U.C.C. § 4A-202(b) (Am. L. Inst. & Unif. L. Comm’n 2022); N.Y. U.C.C. Law § 4-A-202(2) (McKinney 2026). ↩
-
U.C.C. §§ 12-102(a)(1)–(2), 12-104(e), (g) (Am. L. Inst. & Unif. L. Comm’n 2022); see Christopher M. McDermott, Stablecoins Have a UCC Problem, Moving Ahead (Feb. 20, 2025) (stablecoins “are likely to be characterized as CERs”). ↩
-
Restatement (Third) of Agency § 1.04 cmt. e (Am. L. Inst. 2006). ↩
-
Unif. Elec. Transactions Act §§ 9, 10, 14(1) (Unif. L. Comm’n 1999); see also 15 U.S.C. § 7001(h). ↩
-
See, e.g., Press Release, Visa, Visa Introduces Trusted Agent Protocol (Oct. 14, 2025); Stavan Parikh & Rao Surapaneni, Announcing Agent Payments Protocol (AP2), Google Cloud Blog (Sep. 16, 2025); Marco De Rossi et al., ERC-8004: Trustless Agents (Ethereum Improvement Proposal, draft Aug. 13, 2025). ↩
-
GENIUS Act § 2(27); Dep’t of the Treasury, Forms and Procedures for Review of State Certifications by the Stablecoin Certification Review Committee, Treas. Docket No. TREAS-DO-2026-0562 (Sep. 30, 2026). ↩
-
GENIUS Act § 9(a); Request for Comment on Innovative Methods to Detect Illicit Activity Involving Digital Assets, 90 Fed. Reg. 40148 (Aug. 18, 2025). ↩
-
Terrorism Risk Insurance Act of 2002, Pub. L. No. 107-297, §§ 102–103, 116 Stat. 2322 (codified as amended at 15 U.S.C. § 6701 note). ↩