aixbt autonomous crypto agent drained of 55.5 ETH via injected dashboard prompts
An attacker who accessed the aixbt trading agent's dashboard queued malicious prompts that caused the agent to transfer 55.5 ETH (about $104,000 to $106,200) out of its on-chain wallet.
What happened
On 18 March 2025, at approximately 2:00 AM UTC, an attacker gained access to the dashboard of aixbt, an autonomous crypto agent, and queued two fraudulent prompts instructing the agent to transfer funds. The agent acted on the instructions, draining 55.5 ETH from its Simulacrum wallet, the system that lets the agent perform on-chain actions from social-media interactions. The stolen ETH was valued at roughly $104,000 to $106,200 depending on the ETH price at the time of reporting. The attacker operated under the now-deleted X account "FungusMan" / "0xhungusman". Developer rxbt stated the exploit did not compromise aixbt's core systems and was not a failure of the AI itself, saying safeguards were in place. In response, the developer reported the hacker's address to exchanges, swapped access keys, migrated servers, and suspended dashboard access. Following the news, the AIXBT token fell roughly 15.5% to 20%, to about $0.09 to $0.0938.
What the agent did
The aixbt AI agent executed attacker-supplied dashboard prompts and transferred 55.5 ETH from its Simulacrum wallet to the attacker. The on-chain transfer was carried out automatically by the agent acting on the queued instructions, not by a human clicking send.
The irreversible effect
55.5 ETH (about $104,000 to $106,200) was moved on-chain to the attacker and was not recovered; the developer could only report the receiving address to exchanges and rotate access after the fact.
Root cause
The agent's dashboard was an authenticated control surface from which queued prompts could trigger fund transfers. Once the attacker gained dashboard access, malicious prompts were executed by the agent without an independent check on outbound transfers, so a credential/access compromise translated directly into unauthorized on-chain movement of funds.
How a maker-checker control would have refused it
The harmful transfer was executed by the AI agent itself in response to attacker-queued prompts, so this is a genuine automated action rather than speech. A maker-checker control could plausibly have blocked it: if outbound transfers proposed via the dashboard (the maker) required approval by a separate party or key (the checker) before execution, the fraudulent prompts would have been queued but not settled on-chain, and a human reviewer could have rejected transfers to an unknown address. As it stood, whoever controlled the dashboard could both propose and effectively execute a transfer, collapsing maker and checker into one compromised surface.
Runnable reproduction
A runnable reproduction for this entry is in progress.
Accuracy and corrections
This entry describes a publicly reported incident and is compiled from the primary sources listed above. Where an account is a legal allegation rather than an established finding, the entry labels it as such. Summaries can still contain errors. If you can document a correction, email hello@makerchecker.ai and we will review and correct it, with the change noted, within 14 days.
See it for yourself
Reading is one thing. Watch it block an agent.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.