AIDEFEND in Action AIA-0098 Incident Published: Oct 1, 2026

Grok to Bankrbot Morse Message Triggers a DRB Transfer

An attacker used a Bankr Club membership path and sent a Morse-encoded message to Grok on X. Grok decoded and published an instruction mentioning Bankrbot; Bankrbot treated that public text as an executable command and moved 3 billion DRB on Base on 4 May 2026. The on-chain transfer is directly verifiable. Grok did not hold the wallet key, and the exact dollar valuation and recovery percentage vary by report.

Indirect Prompt InjectionSocial EngineeringHuman-in-the-LoopA2A Security
8 applicable AIDEFEND defenses
Source: Behind the Grok Exploitation: An Analysis of AI Agent Permission Chain Abuse 
Author: SlowMist
Original article: May 7, 2026

Threat Analysis

The attacker did not need Grok to hold a private key. They used Grok as a public-language intermediary: a Morse-encoded request became a decoded reply mentioning Bankrbot, and Bankrbot promoted that text into a wallet command. Bankr membership widened the command path before the transfer.

  1. SlowMist reports the attacker activated Bankr Club membership for the relevant wallet, making Bankrbot's higher-risk transfer capabilities available.
  2. The attacker addressed Grok with an encoded message designed to be decoded into a transfer instruction and a Bankrbot mention.
  3. Grok's public reply translated the message and mentioned Bankrbot. This public output is not authenticated financial authorization.
  4. Bankrbot acted on Grok's natural-language reply instead of independently verifying the root request, wallet owner, asset, amount and destination.
  5. The successful on-chain transaction moved 3,000,000,000 DRB from the Bankr-associated wallet to another address on 4 May 2026; a precise USD loss is not encoded in the transaction.

The Base transaction proves 3 billion DRB moved. Bankrbot acknowledged a Grok prompt-injection event, while SlowMist analyzed the encoded-message chain. Neither the transaction nor the now-unavailable attacker post fixes a USD loss figure or the final recovery percentage.

Applicable AIDEFEND Defenses (8)

AID-H-018.003
High-Impact Independent Validation & Approval Gate
Very High
Require an independent transfer gate bound to the exact wallet, token, amount and recipient, with policy-selected out-of-band approval and replay protection.
AID-H-018.002
Policy-Based Access Control
High
At the sole wallet-signing adapter, resolve the authenticated principal and wallet binding from authoritative owner/delegation records and authorize the exact chain, token, amount and recipient. Public thread ancestry and AI-generated text cannot supply those records. Verify canonical arguments and deny stale or missing authority on every signing path. Legitimate automation may use a registered limited grant, but a public Grok reply alone never creates one.
AID-H-018.004
Intent-Based Dynamic Capability Scoping
Medium
In a redesigned Bankr dispatcher, derive wallet capabilities from a signed owner-authorized grant registry and verify the exact workload, task, tool population, TTL and atomic action budget on each use. Membership activation alone grants no signing authority. This requires a Bankr-side registry and dispatcher implementation; it is not a stock public-X-channel control.
AID-M-009.002
Authority Envelope & Action Risk Classification
Medium
Define a versioned wallet authority policy with owner identity, eligible tokens, per-transfer cap and daily cumulative budget. The authority envelope defines those limits but does not enforce a stateful budget by itself: the signing path also needs an atomic reservation ledger, concurrency control and readback tied to finalized transfers. Until that ledger exists and is tested against split requests, claim only the static per-transfer gate as active.
AID-I-003.004
High-Risk Agent Action Containment
Medium
Before signing, consume independently verified anomaly and approval receipts bound to the exact transaction and apply policy-defined block, defer or approval handling. Possible signals include an unapproved recipient, amount versus balance or a verified capability change; the source does not establish a first-ever transfer or membership change minutes beforehand. Missing signals cannot become an invented event fact or an allow decision. This requires a Bankr-side fenced dispatcher and prevents effects only before signing.
AID-D-015
High-Risk Approval Bypass & HITL Activity Detection
Medium
Only if Bankrbot first implements a signed, exact-transaction approval service can a detector correlate each signed transfer with a valid owner approval for the same wallet, token, amount and recipient. A missing or mismatched receipt then alerts operators to freeze remaining funds. This detects the event after execution and cannot reverse a transfer already finalized on Base; ordinary X posts are not signed approval receipts.
AID-H-018.001
Tool Parameter Constraint & Schema Validation
Medium
At the trusted wallet dispatcher, validate a strict transfer schema with a token allowlist, address format and per-transaction amount ceiling, and reject any request that exceeds the ceiling before signing. This is a static single-call limit; splitting a transfer across calls bypasses it. A daily cumulative limit needs a separate atomic reservation ledger and finality-aware readback, while recipient-owner approval belongs to the independent transfer gate.
AID-R-007
External Side-Effect Reconciliation & Compensation
Medium
Stop new Bankrbot transfer dispatch, reconcile each incident-window transaction against Base chain state using a separate read-only identity, and record whether the recipient voluntarily returned funds, the treasury compensated users or a loss remains. A finalized chain transfer cannot be reversed by this control. Recovery or compensation requires actual funds and independently verified balance changes; a signed disposition record alone is evidence, not restoration.

What Defenders Should Do Now

  • Require Bankrbot to authenticate the wallet owner or a narrowly delegated signed request through a channel it controls; public Grok replies remain untrusted text.
  • Before signing, independently approve the exact wallet, token, amount and recipient and impose a per-transaction ceiling. A daily cumulative budget additionally requires an atomic reservation ledger that handles concurrent and split requests.
  • Alert on verified new-recipient or unusual-amount signals and freeze remaining funds after an unauthorized transfer; a finalized Base transaction cannot be reversed by an alert or recovery record.

1 additional consideration

Evidence and deployment boundary

The primary chain proves the token movement, but public sources differ on USD valuation and recovery; this brief reports the verified token amount.
Recommendation: Make Bankrbot require an authenticated wallet-owner instruction or narrowly delegated signed request; a public Grok reply must be treated as untrusted text.

Conclusion

AIDEFEND  places the decisive controls at wallet-owner authentication and the signing adapter: exact transfer approval and a tested amount limit must precede any on-chain action. Public agent-to-agent text cannot grant financial authority.

Last updated: