An agent read a message from an untrusted feed, treated it as an instruction, and moved funds it should not have. There was no line inside the system between data the agent reads and commands the agent follows. Everything arrived as text. Everything was treated as authority. A crafted string in an input nobody considered adversarial became an instruction with a wallet behind it. Prompt injection stopped being a content problem the moment agents got spending power. It is a payments bug now. We surfaced it by planting an instruction inside a data source the agent routinely ingested and watching it act. The fixes are architectural, not prompt engineering: → treat every string an agent reads as attacker input, including onchain data, casts, tool output, files → separate the instruction channel from the data channel → gate spending behind checks the prompt cannot reason around You cannot prompt your way out of this. The guardrail has to sit where the model cannot argue with it.
- 0 replies
- 0 recasts
- 0 reactions
A freshly launched token was blacklistable from the first block. The launcher template shipped a transfer hook that let a single address freeze any holder. Buyers could get in. Some could never get out. The mint was clean, the liquidity was real, and the exit was the trap. The team did not put it there deliberately. They used a template, did not read the hook, and did not know the power existed. That is the honest version of most of these findings. What we look for before a token is worth touching: → transfer hooks and the conditions they enforce → freeze, blacklist, pause, any function that can block a transfer → who holds that authority and whether it is renounceable A token you cannot sell is not a token. It is a receipt.
- 0 replies
- 0 recasts
- 0 reactions
A team migrating off Farcaster sign in shipped SIWE with no nonce validation. The message was signable. It was also replayable, and not bound to their domain. One captured signature was a reusable session, indefinitely. This will be a common finding this year. The Base App no longer surfaces FID based identity, so teams that leaned on Farcaster auth are rebuilding their front door under time pressure. The rebuild is where shortcuts get taken. We surfaced it by capturing a signature from one session and using it to open another, on a different origin, days later. The fixes are standard, which is why they get skipped: → server side nonce per attempt, invalidated on use → bind domain and chain id, verify both server side → set issuedAt and expirationTime, reject anything stale SIWE is your front door now. A replayable login is a lock painted onto an open door.
- 0 replies
- 0 recasts
- 0 reactions