Your Agent Doesn’t Need Your Keys

On May 4, 2026, somebody tweeted Morse code at Grok. Grok, doing its job, decoded the dots and dashes back into English. The decoded text happened to include a command tagging @bankrbot, telling it to move roughly 3 million DRB tokens out of Grok's wallet. Bankrbot saw a tweet from a trusted identity, parsed the intent, signed the transaction, and broadcast it.

Around $175,000 walked out the door. No smart contract was exploited. No private key was leaked. No model was jailbroken in the traditional sense. One bot said something, another bot believed it, and the chain did what the chain does.

If you build agentic wallets, you should stare at that sequence for a while. Because what failed wasn't Bankr's code, and it wasn't xAI's model. What failed was the architecture the whole category is shipping with right now.

The actual bug is “language equals authorization”

Strip away the Morse code novelty and the bug is plain. Bankrbot was treating any well-formed instruction from a recognized X account as a green light to sign and broadcast. Grok was treating any well-formed user prompt as worth replying to. Glue those two together and the line between “thing a user asked an LLM” and “transaction the wallet just signed” disappears.

Once you see it, you can't unsee it. It is everywhere in the agent stack. The agent that summarizes your inbox can be told things by your inbox. The agent that reads Notion can be told things by Notion. The agent that posts replies on X can be told things by anyone on X. If any of those agents holds a key, the key is one persuasive prompt away from doing something you never approved.

So the question to ask isn't “how do we make the LLM smarter about Morse code.” That arms race has no ceiling. The question is: why did the wallet even let that transaction through?

Agents should never hold the key in the first place

This is the part most teams skip. They generate a hot wallet, hand the private key to the agent runtime, wrap it in some env vars, and call it a day. The agent now has god-mode on the wallet. Every prompt injection, every leaked log, every memory dump, every “I'll just paste this into Claude real quick” moment is now a potential drain.

The fix is straightforward and unglamorous. The agent submits intents. Somebody else does the signing.

That somebody else is what 1Claw's Intents API was built to be. The private key lives in an HSM, inside a Trusted Execution Environment. The agent never sees it. When the agent wants to send a transaction, it calls an API with the shape of the intent (destination, value, chain, calldata), and the signing service decides whether that intent passes policy before it ever touches the key.

This is the part that would have stopped the Bankrbot incident cold. Not a smarter LLM. A dumber, stricter signer.

What “policy-based enforcement on keys” actually looks like

People nod along at “policy-based key enforcement” and then go back to using a hot wallet anyway. So here is what it looks like in practice when you wire it up properly.

Address allowlists per agent. Your DeFi bot can talk to your Aave pool and your Uniswap router and nothing else. Some random attacker address that just showed up in a Morse code reply? Rejected at the signing layer, before the key is ever touched.

Value caps, per transaction and per day. The agent can move 0.5 ETH at a time and at most 5 ETH in a rolling 24 hours. Even if every other guardrail fails and an attacker funnels in a valid-looking intent, the blast radius is capped to a number you decided in advance.

Chain restrictions. Your Base-only bot can't suddenly sign a Polygon transaction because someone tricked it into thinking that was the plan.

Simulation before broadcast. Every intent runs through Tenderly first. Reverts, unexpected token transfers, weird approvals — all caught before they hit a block.

Replay protection and idempotency. The same intent submitted twice doesn't execute twice.

None of this is hard to set up. It is just work that doesn't happen if the agent itself is the signer. The moment you move signing into a TEE with a policy engine in front of it, the agent's compromise stops being equivalent to a wallet drain. That distinction is the whole product.

Intents covers 109+ EVM chains, EIP-1559 and legacy types, EIP-712 typed data, plus key generation for Bitcoin, Solana, XRP, Cardano, and Tron. Same scoped-access model on all of them.

Vault: get the keys out of context

Intents handles signing keys. Vault handles everything else: API keys, RPC URLs, webhook secrets, third-party tokens, the long tail of stuff that agents need but absolutely should not be parking in chat history.

Every team in this space eventually learns this lesson the hard way. Somebody pastes a Stripe key into a Claude window to “just check something.” It is now in the context, in the log, in the memory, possibly in someone's eval set. You can't un-paste it. You can rotate the key, but you can also rotate it five more times before you catch the next leak.

With Vault, the agent fetches secrets at runtime with a short-lived JWT, uses them for the call, and never stores them. If an agent gets compromised, you revoke its identity, not the underlying secret. You don't have to call Stripe support at 2 a.m. about a key rotation.

It is HSM-backed, envelope-encrypted, and on the higher tiers the key material itself is split across GCP, AWS, and Azure HSMs via MPC. Translation for the non-paranoid: even if one cloud provider has a bad week, your secrets are still your secrets.

Pair that with scoped policies (this agent can read api-keys/stripe, nothing else) and a full audit log, and you get something that actually behaves like a wallet for credentials instead of a sticky note.

Shroud: the LLM hop is also an attack surface

Here is the part of the Bankrbot story most coverage missed. The Morse code worked because Grok obediently decoded an obfuscated input and produced output that was indistinguishable from a real command. The LLM was the obfuscation oracle.

Shroud sits between your agent and the LLM provider, inside a TEE, and inspects both directions. Going out, it normalizes Unicode, catches homoglyphs, scores prompt injection across six categories, flags encoded payloads (yes, including the “decode this and act on it” patterns that broke Grok), redacts any secret from your vault using Aho-Corasick exact matching, and scrubs PII before it ever reaches the model. Coming back, it scores response-side injection, blocks markdown-image exfil, and catches the model when it tries to echo or hallucinate credentials.

For an agent that talks to the world through a model, this is the part of the pipeline that decides whether “language equals authorization” is a viable attack. With Shroud in front, it isn't.

Stack the three and the incident doesn't happen

Run the Bankrbot scenario back through this stack.

The Morse code reply hits Grok. If Grok were behind Shroud, it flags the encoded payload at the request layer and refuses to forward it cleanly. Even if you skip that step, the decoded “send tokens” output gets scored on the response side and gets blocked or redacted before it reaches downstream consumers.

Even if both of those fail and Bankrbot receives a clean-looking instruction to move funds, the wallet behind it doesn't have the private key anymore. The agent submits an intent. The intent's destination isn't in the allowlist for this agent. The signing service returns a 403. The TEE never touches the key. Nothing moves.

Three layers, each independent. Any one of them would have stopped the loss. All three together is what “production-ready agent wallet” should mean from now on.

If you ship an agent wallet, do this now

If you're building anything in the agentic-wallet space (Bankr-style bots, autonomous DeFi agents, MCP-driven traders, treasury automation, the whole category), the takeaway is short.

Stop generating hot wallets for your agents. Stop pasting keys into env files. Stop hoping your LLM won't say the wrong thing on the wrong day. Put the keys in an HSM, put a policy engine in front of the signer, put a TEE between your agent and its model, and write down what the agent is actually allowed to do.

1Claw exists to be those three pieces, wired together, with one dashboard and one audit log. Vault, Shroud, Intents. 1,000 requests a month free, no card needed. You can have a scoped, policy-enforced agent wallet up and running in an afternoon.

The next Morse code incident is already in somebody's drafts. The only question is whose wallet it drains.

Start free at 1claw.xyzRead the Intents docsRead the Shroud docs