Introduction
In May 2026, an attacker moved roughly $150,000 in DRB tokens out of an AI agent wallet without stealing a single key, according to Giskard’s technical write-up. The agent, built on Grok and connected to the Bankrbot execution layer, treated a Morse-code reply on X as a valid transfer instruction because nothing in its architecture required a second, independent confirmation for a high-value transaction. Spending limits and session caps, the two defenses most agent wallets ship with today, did not apply because the attacker had already unlocked a higher permission tier first. Multi-signature and threshold-signing guardrails are built specifically to close that gap.
This article covers how they actually work, what is already running in production, and the failure modes they introduce have not been fully considered yet
The Guardrail Gap Spending Limits Don’t Close
A spending limit checks one thing: how much value moves in a single transaction or over a time window. It says nothing about who, or what, authorized that transaction in the first place. That distinction is the entire story of the Bankrbot incident.
The attacker’s first move was not the injection itself. It was sending the agent’s wallet a Bankr Club Membership NFT, which unlocked an “Executive” permission tier that bypassed the transfer limits and swap restrictions already in place. Only then did the attacker post an encoded Morse-code message to Grok on X. Grok decoded it and replied, tagging Bankrbot. Bankrbot’s execution layer, according to SlowMist’s postmortem, treated that reply as a valid executable command and initiated an on-chain transfer of roughly 3 billion DRB tokens. SlowMist calls this a permission chain attack: a scenario where the output of one AI system gets treated as trusted financial authorization by another, with no independent check in between.
Our deep dive on agent wallet exploits and prompt injection covers the injection mechanics themselves in detail. This piece is about the layer that was missing entirely, an independent second party or threshold of parties whose approval does not depend on the same model, session, or trust chain that just got compromised.
That is what multi-sig and threshold signing add. A spending cap answers “is this transaction small enough to allow.” A multi-sig or threshold scheme answers a different question: “did enough independently-controlled parties agree this should happen.” Those are not interchangeable, and a wallet can pass the first check while catastrophically failing the second, which is exactly what happened here. About 80% of the stolen funds were eventually recovered once the community identified the attacker, but recovery is not prevention, and it is not a control any team should be designing around.
How Multi-Sig and Threshold Signing Actually Gate a Transaction
Two distinct cryptographic approaches get called “multi-sig” in agent wallet discussions, and they behave differently enough that conflating them leads to bad architecture decisions.
Classic multi-sig, the model popularized by Safe (formerly Gnosis Safe), is a smart contract that holds funds directly and requires a threshold of signatures, for example, 2-of-3, from separate private keys before it will execute a transaction. Each signer is a distinct on-chain identity. The contract itself enforces the threshold, so even if one signer’s key is fully compromised, the attacker still needs the second signature to move anything.
MPC and threshold signing work differently. There is no single private key at all. Instead, the key exists only as mathematical shares distributed across separate parties or devices, and a valid signature can only be produced when enough shares participate in a joint computation, without ever reconstructing the full key in one place. Vultisig’s comparison of providers describes this as the difference between “delegated self-custody,” where a provider or the agent’s own infrastructure holds one of the shares, and genuine threshold custody, where no single party, including the wallet provider, can sign alone.
For an agent wallet specifically, the practical implementation usually sits on top of ERC-4337 account abstraction, which lets a smart contract wallet define its own validation logic instead of relying on a single ECDSA signature. Layered with EIP-7579’s modular account standard, a team can plug in a threshold-checking module without rebuilding the wallet from scratch: low-risk actions get validated by a scoped session key with its own cap and allow list, and anything crossing a defined risk threshold gets routed to a separate validation module that will not clear the transaction until a second, independently-controlled signer or share threshold has weighed in.
That second signer never has to be a human sitting at a terminal. It can be a hardware-isolated policy service, a separate agent with a narrower mandate, or a human approver, but it has to be a genuinely separate trust root from whatever produced the original instruction, which is precisely the check Bankrbot’s architecture skipped.
For more on how identity and permission layers for autonomous agents actually fit together, see our breakdown of why ERC-8004 doesn’t secure an agent’s ERC-6551 wallet and our look at what the ERC-8004 agent registration numbers actually show.
What’s Actually Shipped Versus Still Early
Several providers already run multi-sig or threshold-signing infrastructure for agent wallets in production, though the coverage and gating models differ enough to matter.
| Provider | Signing model | Transaction gating | Status |
| Coinbase Agentic Wallets / AgentKit | MPC, key share held in an AWS Nitro Enclave | Policy Engine checks each transaction against defined rules before signing | Live, production |
| Cobo Agentic Wallet | MPC split between the agent’s own infrastructure and Cobo’s servers | “Pact” framework requires the agent to commit to a declared intent and policy before it can act | Live, production |
| MetaMask Agent Wallet | Non-custodial, optional server component | Guard mode enforces daily spend limits, allowlisted protocols, and 2FA outside policy; Beast mode relaxes these for lower friction | Live, production |
| Vultisig | True threshold signing (DKLS23 protocol), shares held only on user-controlled devices | No single share, including one held by Vultisig itself, can produce a valid signature alone | Live, production |
What is still early is standardization. None of these providers expose the same policy configuration format, and a team building a tiered guardrail system today is effectively locking into one vendor’s specific implementation rather than an open standard. EIP-7579 is the closest thing to a common substrate, since it defines how validation modules plug into a modular smart account regardless of which module a team chooses to write, but an off-the-shelf, audited “multi-sig-for-agents” module that any ERC-4337 wallet can install is not yet something we found evidence of shipping. Safe’s own documentation, referenced in FoxWallet’s survey of the space, covers classic multi-sig and smart accounts generally, but stops short of an agent-specific configuration.
Designing the Guardrail: A Tiered Threshold Model
A workable architecture does not gate every transaction the same way. FoxWallet’s survey of the space proposes a four-tier structure, and it is a reasonable starting point to build on with concrete parameters rather than treat as a finished design.
Low-risk actions, a transaction to a pre-approved contract address, below a fixed cap, using a token the agent is explicitly scoped to touch, cleared through a session key alone. No second party is involved, because the blast radius is already bounded by the scope of the key itself.
Medium-risk actions, a new counterparty address, or a transaction above the session key’s per-transaction cap but still within a daily ceiling, route to a single additional approver. That approver has to be a separate trust root: a human or a policy service running in its own isolated environment, not another instance of the same model that generated the original instruction.
High-risk actions, anything that would move a meaningful share of the wallet’s holdings, interact with an unaudited contract, or change the wallet’s own permission configuration, require a genuine threshold, 2-of-3 or higher, with signers drawn from separately-controlled infrastructure. A time delay on top of the threshold gives a team a window to notice and freeze an in-flight transaction even after signatures clear.
The tradeoff nobody advertises is latency. Every additional signer or delay window is friction an attacker also has to defeat, but it is friction a legitimate, time-sensitive transaction has to sit through too. Teams building this have to decide upfront which categories of action are worth that cost, rather than defaulting to either extreme.
The Risks Multi-Sig Doesn’t Solve
Multi-sig and threshold signing close the specific gap that let Bankrbot execute a single-approval transfer at Executive-tier permissions. They do not close every gap, and treating them as a complete fix creates its own blind spots.
Permission Chain Collapse: When the Second Signer Isn’t Independent
SlowMist’s framing of a permission chain attack, the output of one AI system treated as trusted financial authorization by another, does not stop being a risk just because a second signature is now required. If that second signer is itself another automated system reading the same compromised context, or an agent operated by the same team with no meaningfully separate judgment, the attack surface has not shrunk; it has moved up one level. A threshold of two agents that both trust the same upstream input is not a threshold at all in any meaningful sense; it is the same single point of failure wearing a second signature.
Custody Fragmentation: Splitting Keys Just Moves the Trust Problem
Providers like Cobo hold one share of an agent’s key on their own infrastructure as part of the signing process, which Vultisig’s own comparison describes as “delegated self-custody” rather than genuine threshold custody. That model reintroduces a single point of institutional trust exactly where the architecture was supposed to remove one. It also creates an unresolved operational problem specific to autonomous systems: recovery. A human who loses a seed phrase has recourse through memory, backups, or social recovery.
An autonomous agent that loses access to its own key share, through a provider outage, a bug, or a dispute with the custodian, has none of those options built in, and none of the providers reviewed here publish a tested recovery procedure for that scenario.
Approval Latency: The New Attack Surface Is the Checkpoint Itself
Adding a human or independent-service checkpoint for high-risk actions does not remove the attack surface; it relocates it to the approval step. An attacker who cannot forge a threshold signature can instead target the humans or systems responsible for granting it: social-engineering an approver directly, or flooding the approval channel with plausible-looking requests until fatigue produces a rubber-stamp approval. Mainstream coverage of the Bankrbot incident focused entirely on the injection technique itself. None of the sources reviewed for this piece examined what happens once teams start routing high-risk agent transactions through human or secondary-agent checkpoints at scale, which is the direction the tiered model above is already pushing the industry.
Our comparison of CertiK, Hacken, and Quantstamp is relevant here for teams evaluating who actually reviews a policy engine or a threshold module before it goes into production, since none of the providers above publish a public audit of their specific agent-gating logic.
What This Means for Builders, Auditors, and Operators
For developers integrating an agent with a programmatic wallet, the practical takeaway is that a session cap alone is not a security boundary; it is a damage-limitation setting on top of whatever signing model actually authorizes the transaction. Building the threshold or multi-sig layer in from the start, rather than bolting it on after an incident, means fewer assumptions baked into the code about what counts as a trusted instruction.
Security and audit teams face a review surface that has expanded beyond the smart contract itself. Our look at AI-assisted smart contract auditing covers how audit tooling is adapting to review code faster. The harder, less-tooled problem is reviewing a policy engine’s configuration: the actual rules that decide which transactions need one signature versus a threshold, since a misconfigured tier boundary is functionally equivalent to having no guardrail at all for anything that falls on the wrong side of it.
Wallet and agent operators running these systems day to day face a more operational open question than a technical one: who is the second signer in practice, and does that person or system have genuinely separate context from the agent itself, or are they approving requests fast enough that the checkpoint is a formality.
What to Watch
EIP-7579 module adoption beyond Safe’s own ecosystem. Whether other smart account providers standardize on the same modular interface will determine if an audited, portable multi-sig-for-agents module ever becomes something a team can install rather than build from scratch.
Whether Safe or another major multi-sig provider ships an agent-specific configuration. FoxWallet’s survey found only a passing reference to Safe’s general documentation, not a purpose-built agent module. That is a gap an established provider is well positioned to fill.
Post-incident changes to Bankrbot’s own architecture. How the team that built the exploited system responds, specifically whether they add a genuine second-signer requirement rather than a higher spending cap, will be a public test case for whether the industry actually internalizes the permission chain framing or treats this as an isolated bug.
x402’s relationship to policy layers. As x402 extends stablecoin-based payments for agents, how that payment protocol interacts with, or ignores, the threshold and multi-sig layer described here will shape whether guardrails travel with a transaction across protocol boundaries or stay siloed to whichever wallet initiated it.
Conclusion: Where the Guardrail Layer Actually Stands
Multi-sig and threshold signing are not theoretical for AI agent wallets. Coinbase, Cobo, MetaMask, and Vultisig all run some form of it in production today, and the underlying account abstraction standards, ERC-4337 and EIP-7579, already support plugging a threshold check into a smart account without rebuilding it from scratch.
What is still unresolved is standardization and the harder design questions that come after the cryptography works. No open, audited module lets a team install agent-appropriate multi-sig the way they would install any other smart account plugin, which means every implementation today is a custom integration with a specific vendor’s assumptions baked in. And a threshold requirement only closes the gap it was built for. If the additional signer shares the same compromised context as the original agent, or if the approval step itself becomes the target, the guardrail has moved the problem rather than solved it.
Which direction this goes, toward a common, auditable substrate or toward a handful of vendor-specific black boxes, depends more on whether a major provider ships a genuinely open agent module in the next year than on any further refinement of the signing math itself. The cryptography is not the hard part anymore. The trust design around it is.
FAQs.
What is a multi-sig guardrail for an AI agent wallet?
A multi-sig guardrail is a rule built into a wallet’s smart contract or signing process requiring more than one independently-controlled approval before a transaction executes. Instead of a single key or session authorizing a transfer, a threshold of separate signers, which can include humans, isolated policy services, or hardware-secured modules, has to agree first. This adds a check on who authorized an action, not just how large it is.
Doesn’t a spending limit already solve this problem?
No. A spending limit only restricts transaction size or frequency; it does not verify that the instruction itself came from a trustworthy source. The May 2026 Bankrbot incident happened because an attacker first unlocked a higher permission tier, which raised the applicable spending limit, then used a single compromised instruction to clear it. A multi-sig guardrail addresses authorization directly, independent of transaction size.
How do developers actually add a multi-sig guardrail to an agent’s wallet?
Most implementations build on ERC-4337 account abstraction, using a modular smart account standard like EIP-7579 to install a validation module that routes transactions above a defined risk threshold to a second signer or a share-based threshold check. Providers including Coinbase, Cobo, and Vultisig offer this as managed infrastructure today, though each uses its own policy configuration format rather than a shared open standard.
What’s the difference between classic multi-sig and MPC threshold signing?
Classic multi-sig, the Safe model, uses a smart contract holding funds directly, requiring signatures from a threshold of separate private keys. MPC or threshold signing has no single private key at all, instead distributing mathematical key shares across parties, with a valid signature only producible when enough shares jointly compute it. Both require multiple independent approvals, but MPC removes the concept of a single reconstructable key entirely.
What should a security team check before approving an agent’s wallet policy for production?
Verify that the second signer in any threshold has genuinely separate context from the primary agent, not another instance reading the same inputs. Confirm the risk-tier boundaries are specific and auditable rather than left to the agent’s own judgment, and check whether the provider publishes a tested key-recovery procedure for lost or disputed shares, since most reviewed providers currently do not.
A spending limit tells you how much moved. A multi-sig guardrail tells you whether it should have moved at all, and right now only a handful of providers actually enforce that distinction. Subscribe below for no-hype AI crypto analysis before the market catches up.
Editorial & Disclaimer Note: Content on CryptoAIAnalysis is independently researched and written using publicly available documentation, technical resources, and observable network data. The aim is to explain AI-powered crypto and blockchain systems clearly, highlight real-world use cases, and discuss limitations alongside potential. This content is provided for informational and educational purposes only and does not constitute financial, investment, or legal advice. Cryptocurrency and AI-related investments involve risk, and readers should always conduct their own research before making decisions.
