How an AI Agent Actually Gets Its Own Wallet
An attacker gifted an AI agent an NFT in May 2026 — and that alone granted control over its wallet. The instruction to steal was hidden as Morse code. How wallets for autonomous agents are actually secured today, and why the permission itself becomes the vulnerability.
On May 4, 2026, someone sent the X bot Grok a "Bankr Club Membership" NFT. Grok was linked to its own wallet through the crypto trading bot Bankr, and that wallet was configured so that owning certain NFTs automatically unlocked elevated rights, in this case transfer and swap permissions ordinary users didn't have. The NFT was the gift. The trap arrived as a reply to a completely different tweet: a request to translate a Morse code message. Grok obliged, the decoded text read, in effect, "send 3 billion DRB tokens to this address," and because the safety layer didn't recognize encoded text as an instruction, Bankr processed the translation as an authenticated command and executed the transfer. Damage: somewhere between $150,000 and $200,000, depending on the source. Nobody stole a private key, no spending cap was exceeded, no line of code had a bug. The permission itself was the attack.
That story is the best way into a question the previous article in this series deliberately left out. That one was about how money moves once an agent wants to pay, x402, AP2, stablecoins versus card networks. This one is about the layer underneath: how does an agent get a wallet it can be trusted with in the first place, without a human approving every transaction, and without anyone handing it the master key to do so?
Why the seed can never touch the prompt
A human wallet protects exactly one thing: the seed phrase every other key can be deterministically derived from. For an AI agent, that model breaks down for two reasons. First, anything a language model sees as text potentially ends up in context, in logs, in debug output, in the next request to a third-party provider. A seed in the prompt is a seed that eventually leaks somewhere. Second, an agent holding the full key is, by definition, unconstrained: every rule, "only up to $50," "only to this address," would then have to be enforced inside the agent itself, precisely the component prompt injections like the Morse code message above are best at manipulating. The answer the industry has largely converged on by 2026: the agent never gets the master key. It gets a wallet whose limits live in code or infrastructure, not in the model's good intentions.
Three architectures, one problem
Smart contract wallets with session keys. Through account abstraction (ERC-4337, live since 2023) or, since Ethereum's Pectra upgrade on May 7, 2025, through EIP-7702, a wallet address can be programmed to issue temporary, tightly scoped secondary keys, session keys. A session key can specify exactly: which contract functions may be called (only swap() on a specific router), how much can move at most, and how long the key is even valid, often just hours. The real difference between the two standards runs deeper: ERC-4337 requires an entirely new smart-contract address and runs through additional bundler infrastructure; EIP-7702 lets an existing standard address (an EOA) temporarily behave like a smart contract via an authorization signature, same address, same balance, noticeably less gas. An analysis from early 2026 counted more than 25,000 accounts already upgraded to EIP-7702 (roughly 13,000 on Ethereum, plus Optimism, BNB Chain, and Base), at around 1,000 interactions per day, with infrastructure providers like ZeroDev, Pimlico, and Openfort building their agent session-key systems on top of it.
Multi-Party Computation (MPC). Instead of generating a key and then restricting it, MPC never generates a complete key at all. Provider ChainUp describes its model like this: the private key is split into several independent shares that live separately on different devices or servers; to produce a signature, the shares compute together without the complete key ever being reassembled at any point, not even in memory. A single compromised share isn't enough to sign anything.
Trusted Execution Environments (TEE). The third building block doesn't secure the key itself but the place where it gets used: an isolated hardware environment, typically an AWS Nitro Enclave instance, with no persistent storage and no operator login, in which key material can be processed without ever existing in plaintext outside the enclave.
The real-world case: MPC and TEE together
The clearest example is Coinbase's "Agentic Wallets," launched February 11, 2026 specifically for autonomous agents (source: Coinbase's own product documentation, so not a neutral voice, but technically verifiable). The design combines both building blocks: private keys are split via Coinbase's own cb-mpc library using distributed key generation (EC-DKG) and threshold ECDSA over the secp256k1 curve, and computation happens exclusively inside an AWS Nitro Enclave. Documented programmable controls include session caps ("$5 over the next hour"), per-transaction limits, and per-token allowlists, one example from the docs: a $10 USDC per-transaction limit, a $200 USDC session cap, plus an allowlist of exactly three DEX router addresses. Coinbase itself describes the security gain over a key simply sitting on disk as "several orders of magnitude" higher, a self-assessment, but one backed by a verifiable architecture.
Where it still goes wrong: the permission is the attack
This is exactly the punchline of the Grok-Bankr story from the opening: none of the three techniques above would have stopped it. No spending cap was exceeded, no allowlist bypassed, no key compromised. The attack consisted of the system accepting ownership of a particular NFT as valid authorization, regardless of how that NFT arrived in the wallet, and of the subsequent instruction slipping past content review because it was encoded text. Security researchers classify this under the OWASP Top 10 for LLM applications (2025) as two categories at once: "Prompt Injection" (LLM01) for the Morse code trick, "Excessive Agency" (LLM06) for the agent being authorized to carry out a consequential action like this without confirmation in the first place. Between 80 and 88 percent of the loss came back after negotiations with the attacker; the rest is treated as an informal bug bounty.
A second case from the same year shows the other side of the same coin. On January 31, 2026, the Solana platform Step Finance and its sister projects lost roughly $40 million from treasury wallets, not through a smart contract bug, but because attackers compromised the personal devices of several executives and gained direct access through them. Step Finance shut down entirely on February 23, 2026. The lesson is uncomfortable but important: even the cleanest MPC or TEE architecture only protects the key, not the devices and people who have access to the administrative layer above it. The same rule that applies to personal seed phrases, just applied one level up.
At a glance
| Building block | Protects against | Does not protect against |
|---|---|---|
| Session keys (ERC-4337/EIP-7702) | Unlimited access to the master key | Legitimate-looking but abused permissions |
| MPC | Theft of a complete key in one place | Compromised administrator devices |
| TEE | Key material sitting in plaintext on a host | Flawed application logic inside the enclave |
| All combined | Most classic custody failures | Prompt injection and excessive agency |
What this means for actually deploying an agent
Three rules follow from both cases, regardless of whether you build your own infrastructure or use a provider like Coinbase, ZeroDev, or Openfort. First: an agent never sees the seed phrase or the master key, full stop, that's exactly what session keys, MPC, and TEEs exist for. Second: limits belong tight and short-lived, not generous "just in case," a $200 session cap instead of $20,000 cuts the damage of a successful attack by a factor of a hundred. Third, and this is the real lesson from Bankr: any permission arriving from the outside, an NFT transfer, a token approval, a message with an embedded instruction, has to be treated as untrusted input, not as the owner's consent. Following these three points doesn't mean "no risk," but it does mean the risk has moved to a place where it can actually be bounded.
Sources:
Custody architecture
- Cobo: What is ERC-4337? Account Abstraction Explained
- bex.co: EIP-7702 Session Keys: How Ethereum's Biggest Wallet Upgrade Lets AI Agents Trade DeFi Without Full Custody (March 2026)
- Openfort: Best AI Agent Wallets for Developers in 2026, Compared
- ChainUp: Coldcard Exploit 2026: Lessons for Institutional Custody
Coinbase Agentic Wallets
- Coinbase Developer Platform: Introducing Agentic Wallets (February 11, 2026)
- eco.com: Coinbase Agentic Wallets Explained
Grok-Bankr exploit (May 2026)
- Giskard: How Grok got prompt-injected: an X user drained $150,000 from an AI wallet
- AMBcrypto: AI-linked wallet drained via prompt injection in Bankr exploit
- Coincub: Permission Granted: The Layer AI Agent Wallets Forgot to Defend
Step Finance hack (January/February 2026)
- BleepingComputer: Step Finance says compromised execs' devices led to $40M crypto theft
- Cointelegraph: Step Finance Shuts Down After $40 Million Hack
Direct follow-on
