On May 4, 2026, an attacker sent a Bankr Club Membership NFT to the wallet linked to Grok, xAI's chatbot. The NFT unlocked transfer capabilities inside Bankr, which controlled the associated wallet. Then came a message on X, an instruction hidden in Morse code. Grok decoded it and repeated it publicly. Bankr treated the output as a command, and roughly $175,000 in tokens moved to the attacker's address.
No private key was stolen. No smart contract was exploited. The failure was in the infrastructure that treated an LLM's output as authorization to move money.
Protecting the private key was not enough to prevent the transaction. Grok never held the key. Its output instead influenced how Bankr exercised the wallet's signing authority. Agentic systems introduce another point of failure for custody infrastructure: software that can shape how financial authority is exercised without ever touching the key itself.
As I laid out in The missing infrastructure for AI agent payments, an agent needs persistent, delegated access to act on its own. The design question is how it gets that access without opening a path for the agent, or anyone who can manipulate it, to gain effective control over everything the wallet can reach.
MPC + account abstraction: the design foundation for AI agent custody
Two approaches illustrate how agent access can be separated from unrestricted asset control.
The first is threshold signing, a threshold signature scheme (TSS) realized in practice as a multi-party computation (MPC) protocol. Rather than a single private key controlling an account, key material is split across independent parties, none of which can produce a valid signature alone. NEAR's chain signatures architecture works this way: a decentralized network of nodes jointly produces a signature for a requested transaction without any single node ever holding the complete key. In practice, that means no individual node holds enough key material on its own to move funds. An agent operating on top of this kind of system can request signatures without ever holding a key that, if leaked or manipulated, would hand over everything at once.
The second is account abstraction, most commonly implemented through the ERC-4337 standard and embedded as part of NEAR Protocol's account architecture since the network's mainnet launch in April 2020. Instead of relying on a standard externally owned account, this approach uses a programmable smart account, where custom authorization and execution logic can be enforced at the account level rather than left entirely to whoever holds the key. Properly configured constraints can therefore continue to apply when an agent requests an action outside its permitted bounds.
Both approaches aim at the same underlying goal: separating an agent's ability to act from unrestricted control over the assets it can reach. Neither is a complete answer on its own, but the two can be complementary. The distinction between them matters: threshold signing protects against the compromise of a single key or signing party, but it says nothing about whether a valid signing request should have been made in the first place. Account abstraction can go further by enforcing hard constraints at the account level, regardless of what an agent, or whatever is manipulating it, asks for. Signature capability and total control do not have to be the same thing.
Why institutional crypto custody doesn't work for AI agents
Enterprise custody platforms already solve a version of this problem. Fireblocks, one of the most established institutional providers, layers a policy engine on top of multi-party computation: every transaction request gets checked against configured rules before any signature is produced. The technology maps closely to what agent custody needs. But the design carries the assumption that there's an institutional operator on the other end.
That assumption, not the price itself, is the real constraint. Institutional custody works because it is surrounded by institutional infrastructure: dedicated security and compliance teams, carefully configured governance, layered approval processes, and professional operators trained to run the system correctly, along with the ongoing monitoring needed to catch problems before they compound. That is less about any single feature working correctly than about a surrounding organization capable of using it correctly, day after day.
Consumer-scale agent commerce cannot assume that operating environment. The gap between the two comes down to cost and complexity, not capability, and it needs the same underlying guarantee, that no single compromised point can drain everything, without requiring every user to become a security professional to get it.
What consumer AI agent custody requires
Access has to be persistent, because an agent that pauses for confirmation on every routine action isn't automation. It has to work the same way whatever network the agent operates on, and it has to keep the agent separated from unrestricted key control. Permissions have to be bounded and specific, with a path to human review when a request falls outside them. And when something goes wrong (a lost device, a compromised account, an agent behaving unpredictably) a human has to be able to take control back, without the recovery mechanism itself becoming the single point of failure custody was built to eliminate.
Bankr's response to the Grok exploit illustrates the difference between closing off a specific attack path and building custody that limits the damage when some other path succeeds. The company added IP whitelisting, permissioned API keys, and a toggle disabling actions triggered by public replies; the transferred tokens were reportedly recovered soon after. Those fixes address how Bankr received the instruction that caused the exploit. They do less to address what the agent was capable of doing once an instruction, however it arrived, was treated as authorized. Input filtering can reduce how often an agent gets manipulated. It does little on its own to bound what happens when manipulation succeeds anyway.
MetaMask's Agent Wallet, which reached general availability on August 6, 2026, shows these principles applied together in a live product. Users set spending limits and allowlist specific protocols before an agent can act, and transactions outside those preset boundaries are paused and routed to human approval rather than executed automatically. Bounded access and recoverable control are being built directly into consumer products, rather than assumed to require institutional resources, moving the category closer to a seamless consumer experience than an enterprise control panel.
Custody vs. policy enforcement in agentic commerce
Custody determines who can access an agent's assets, how that authority is secured, and how control can be recovered when something goes wrong. Grok's compromised output moved real money because nothing in that chain checked whether the instruction deserved to be trusted, not because a key was ever stolen. Threshold signing would not, by itself, have stopped that: the signing nodes would still have produced a signature for a request that arrived through Bankr's normal channel. Account abstraction might have, if the account carried a hard spending limit the exploit could not talk its way past. Institutional custody shows what real protection looks like when a platform is surrounded by the expertise, governance, and monitoring built for exactly this problem. What consumer-grade agent custody needs is that same underlying guarantee, delivered in a form that doesn't require every user to operate like they have an institutional security team of their own.
Securely delegated access still leaves another question unanswered: what is the agent actually permitted to do with that authority? Custody can bound who holds the keys and how those keys get recovered if something goes wrong. It cannot, on its own, decide whether a given instruction should be trusted and executed in the first place. That is where policy enforcement begins, and it's the question I'll take up next.
overview
