AI agent wallet security: prompt injection, god-keys and a 12-point checklist.

The incident that defines the category

In May 2026 an attacker sent an NFT to a wallet controlled by a public AI agent, then replied to one of the agent’s posts with a message encoded in Morse code. Decoded, it was an instruction: send roughly 3 billion units of a token to a specified address on Base. The agent decoded it, treated it as a request, and executed. Ledger’s write-up puts the loss at about $174,000 and the token’s price down nearly 40% within minutes (Ledger Academy, published 2026-05-20). Our research pack rounds the figure to ~$175k.

Three things were true at once. No private key was stolen. No AMM or bridge was exploited. The agent did precisely what its wallet permitted. Ledger’s diagnosis is the right one: the system had no human-in-the-loop check for a high-value, irreversible action. The wallet’s policy lived in the model’s instructions, and the model’s instructions are what the attacker wrote to.

The wider backdrop is louder and less precise. The research pack records Q1 2026 DeFi hack losses above $1B (per Agentic Finance Graph research pack, 2026-09-04); public trackers publish materially different totals for the same quarter depending on whether they count only smart-contract exploits or also key compromises and off-chain infrastructure failures. Quote the definition with the number or do not quote the number. What is not disputed is the working assumption on both sides: AI accelerates attack and defence, and an agent that reads the open web is a new attack surface bolted onto an old asset class.

Ledger also documents a smaller case from February 2026: an agent that lost about $2,100 (Ledger Academy, 2026-05-20) — small because the operator had deliberately funded it thinly. That is the cheapest control on this page and the one most operators skip. A wallet cannot lose what it does not hold.

The threat model: eight ways an agent wallet loses money

Agent wallets fail in a handful of repeatable ways. The table maps each to the control that stops it and the layer where that control has to live to count. “Enforced in the prompt” appears nowhere in the third column, on purpose.

Two rows deserve emphasis. Review farms are a wallet-security problem because reputation is what other agents use to decide whom to pay; a farmed score is a phishing lure with a registry entry. How ERC-8004 reputation gets gamed is covered separately. Flash-herd risk is not an exploit at all; it is correlated policy. If ten thousand agents run the same yield mandate against the same ERC-4626 vaults, the exit is the incident.

Why EIP-7702 delegation is not custody transfer

EIP-7702 has been live on Ethereum mainnet since Pectra on 2025-05-07. It lets an EOA set its code to a 23-byte pointer at deployed bytecode, gaining batching, sponsored gas and session keys without moving funds to a new address. That is the right primitive for agents, and it is routinely oversold. ethereum.org is explicit: the private key of the EOA retains full control over the account after the delegation, and delegating to a Safe does not make the account a multisig, because a single key can still bypass any signing policy (ethereum.org, page updated 2026-07-17).

Read that as an operator, not a protocol designer. The delegated implementation enforces caps on the session key. It enforces nothing on the master key, which can send a new type-0x04 authorization that replaces the implementation, or clears it to the zero address, at any time. The whole model therefore reduces to one question: where is the master key? If it sits in the same runtime as the agent — an environment variable next to the model’s tool calls — the policy is theater. A prompt-injected agent with the raw key does not negotiate with a session module. It signs as the owner.

The corollary applies to the implementation you delegate to. A malicious or buggy implementation runs with the EOA’s full balance in the EOA’s own context. Wallets are expected to whitelist audited implementations and to refuse raw delegation requests from applications; ethereum.org’s own guidance is that wallets use caution when helping users delegate to a third-party contract. The EIP-7702 brief covers the wire format and detection in full.

The god-key label

Our indexer applies one label that operators dislike and incident responders thank us for. A funded, labeled agent wallet that is a raw EOA — no delegation designator, no smart-account code — and shows no evidence of signer isolation is tagged god_key = true. Not “unsafe”. Precursor. The wallet may be run perfectly well from a TEE or a hardware signer; from the outside we cannot see that, and neither can the counterparties paying it.

code = eth_getCode(wallet)
if code == 0x:                                   state = EOA
elif code[0:3] == 0xef0100 and len(code) == 23:
    implementation = code[3:23];                 state = DELEGATED
    risk = allowlist.has(implementation) ? "audited" : "unknown"
else:                                            state = CONTRACT   # 4337 / classic

god_key = state == EOA
          and labeled_agent
          and usdc_balance > dust                  # dust = 1 USDC
          and not signer_isolation_evidence        # attestation, hardware path, published policy

Delegation to an unknown implementation earns a second label, implementation_risk = unknown. We publish both as shares of funded labeled wallets — delegated_share and its inverse, god_key_share. Dust thresholds and windows are in the methodology; the panels sit on the graph page. If your wallet carries the flag and should not, the fix is public: delegate, or publish attestation of where the key lives.

Where the policy is actually enforced

Vendors say “spend limits”. The useful question is which layer would have refused the Morse-code transfer. There are five candidate layers and they are not interchangeable.

The hardware row is where the May incident would have died. Ledger’s model is “agents propose, humans sign, and hardware enforces”: keys stay in a Secure Element, the secure screen renders what is really being signed, and the Device Management Kit (DMK) lets an agent request approvals from a Ledger device today; hardware-enforced agent policies such as a daily cap or a three-contract allowlist were on Ledger’s roadmap for Q3 2026 (Ledger Academy, 2026-05-20). MetaMask’s Agent Wallet ships two postures: Guard Mode, the default, with daily spend limits, allowlisted protocols and human approval for anything outside policy; and Beast Mode, which drops the allowlists and pauses only on transactions flagged as malicious, with simulation, threat scanning and MEV protection on every route (MetaMask Agent Wallet materials, per research pack, 2026-09-04). Beast Mode is a legitimate choice for a thinly funded trading wallet. For anything else it is a god-key with better telemetry. The provider comparison grades each vendor on which row of this table it actually occupies.

Session keys: the policy surface that matters

Once the EOA delegates, the implementation issues session keys — valet keys, in this site’s usage. The controls that production wallet APIs expose are few, and an agent policy should set all seven. Example values are illustrative, not measured.

Two caps get skipped most often. A per-transaction cap without a session cap is salami-sliced in an afternoon. A target allowlist without a function allowlist still permits an approve on an allowed token to an unlisted spender, followed by a transferFrom the policy never sees. Coinbase’s CDP upgrades the existing EOA in place with sponsored delegation on Base, Arbitrum, Ethereum, Optimism and Polygon; Alchemy’s pattern is delegate, create a session with a permissions array, one EIP-712 signature from the human, then the agent signs with the session key only (research pack, 2026-09-04). Implementations documented as audited on ethereum.org (page updated 2026-07-17; addresses shown lowercase — verify live before use):

The same page lists further examples. Anything not on a published allowlist stays implementation_risk = unknown in our data until an audit or a partner says otherwise.

The 12-point operator checklist

• 1. The master key never enters the agent runtime. Hardware, HSM or TEE. If it is an environment variable next to the model, stop reading and fix that first.
• 2. Delegate under EIP-7702 to an audited implementation and record the designator. Unknown bytecode is a finding, not a preference.
• 3. The agent signs with a session key only, with all seven controls set: time, per-tx cap, per-session cap, function, asset, target, rate and gas.
• 4. Policy is enforced on-chain or in the signer, never solely in a prompt or in a config file the agent can read.
• 5. Function allowlists cover approve, permit and delegatecall paths, not just the happy-path swap and deposit selectors.
• 6. Human or hardware approval for anything outside policy, with a threshold low enough that the approver still reads what they sign.
• 7. Fund thinly. Working balance for the job plus gas; treasury sits in a wallet the agent cannot reach.
• 8. Simulate and screen every transaction before signature: destination screening, revert prediction, unusual-outflow detection.
• 9. Kill switch on retry streaks: N consecutive reverts, or gas burned above cap, revokes the session automatically.
• 10. Treat all inbound content as hostile: replies, NFT metadata, tool outputs, encoded text. Nothing the agent reads may change what it is allowed to sign.
• 11. Log the signer of every outbound transaction (session-key ID or master) so the incident question can be answered in minutes, not days.
• 12. Rehearse revocation. Practise clearing the designator to the zero address and rotating session keys before you have to do it under pressure.

Graded against this list, most “agent wallets” we see pass points 3 and 8 and fail points 1, 4 and 11. That is why the god-key share, not the mint count, is the security number we lead with — the same logic that separates agentic finance from agent registration.

Incident response: session key or master key?

When money leaves an agent wallet, the first hour is a classification problem. The answer decides whether you have a policy failure or a total loss.

T+0   Revoke every session key on the module. If unsure, clear the
      designator: send type-0x04 with address = 0x000…000 from the
      master key, from a clean machine.
T+5   Pull outbound txs since the last known-good balance. For each:
        signed by session key, inside policy    → injection or scope gap
        signed by session key, outside policy   → implementation / module bug
        signed by master key (raw EOA tx)       → key exfiltration or co-location
        new 0x04 auth to unknown implementation → master key compromised
T+15  Master key: assume full loss. Sweep what remains to a fresh,
      isolated key; rotate any chain_id = 0 authorizations, which were
      valid on every chain.
T+30  Session key: leave the master where it is, close the policy gap
      (selector, target, cap), issue a new session, resume.
T+60  Write the incident-ledger row: vector, signer, layer that failed,
      value, recovery, and the label the graph should have shown.

Checklist point 11 exists because of line T+5. Without per-transaction signer attribution every incident looks like a master-key breach until proven otherwise, and the cautious response — sweep everything, burn the address — costs more than most policy failures. Ledger’s write-up of the May case is the template for what to publish afterwards: vector, mechanism, loss and the missing control, in plain language (Ledger Academy, 2026-05-20). The incident-ledger module of the graph records the same fields — prompt injection, policy bypass, infinite retry, sanctioned outflow — as first-class entities, and the Agentic Desk is being built to alert on designator changes and god-key funding events for labeled wallets.

Sources

• ethereum.org, EIP-7702 (Pectra roadmap page; custody statements and audited implementation table) — page last updated 2026-07-17 — link
• Ledger Academy, “Ledger’s Guide to Agentic AI Security” (May 2026 Morse-code incident, February 2026 case, DMK and roadmap) — published 2026-05-20 — link
• EIP-7702 specification, ethereum/EIPs (set-code transaction, authorization tuples) — mainnet activation with Pectra, 2025-05-07 — link
• Coinbase Developer Platform, EIP-7702 wallet documentation (in-place upgrade, sponsored delegation chains) — as recorded in the research pack, 2026-09-04 — link
• MetaMask Agent Wallet announcement (Guard Mode, Beast Mode, allowlists, simulation) — as summarized in the research pack, 2026-09-04 — link
• Agentic Finance Graph research pack (incident reality check, 7702 technical note, open questions, implementation spec) — 2026-09-04 — link

FAQ