IntentWatch

Problem - an AI agent that holds money pays whoever an invoice, a prompt or a tool result tells it to, and a bridge drain can run for hours before anyone announces it. On 30 Sep - 1 Oct 2026 the HOT Bridge treasury on BNB Chain paid 3,865,000 USDT to one address in five withdrawals over about 6 hours. The first public statement came about 13 hours after the first large one (the funds were later returned in full).

What I built - IntentWatch has three parts.

1. A detector: 16 rules over public chain data from intents.near, the HOT omni token contract and the bridge treasuries on BNB Chain and Ethereum. In a replay of the drain, the first high alert fires on intents.near 31h 40m before the first large payout. That is a best case, since the rules were written after the post-mortem. On later data the frozen rules never saw, they gave 0.15-0.29 false high alerts a day and one false pause, all reported in the README.
2. A local HTTP API and MCP server that answer allow, delay or pause for a payment route, and block, warn or allow for a NEAR receiver.
3. A guard wallet contract that holds the agent's funds and refuses transfers on flagged routes or to flagged receivers, whatever the agent was told. In a prompt-injection test, 4 of 5 attacks moved nothing.

How NEAR fits in - the first signal of the drain was on NEAR, so the rules decode intents.near events and check the Verifier's internal balances against what the token contract actually holds. The guard wallet (guard.surs51.testnet) and an incident registry (registry.surs51.testnet) are NEAR contracts on testnet. The agent's key is a function-call key that can only call request_transfer, and before each send the guard checks the route and the real receiver against the registry.