What does AI monitoring give a DeFi protocol if the exploit still happens?

AI monitoring watches a protocol's transactions and raises an alert when they look unusual. It shortens the time to the team's response, but it does not fix a bug in the code or bring back funds that have already left. At NEAR Intents the SHIELD layer flagged suspicious withdrawals from a treasury contract, the service was paused and the bug was patched within an hour. By then the attacker had taken about 3.87 million USDT.

What happened at NEAR Intents?#

According to Crypto Briefing, on September 30 and October 1, 2026 a critical bug in the smart contracts allowed about 3.87 million USDT to be drained from a treasury contract on BNB Chain. The funds left in several withdrawals over two days.

The SHIELD security layer flagged the suspicious activity. The team paused the service and shipped a patch within an hour. Deposits and withdrawals on 11 networks, including BSC and Polygon, were halted for about 12 hours.

On October 2 NEAR Intents General Manager Alex Shevchenko said the suspected exploiter had been identified, gave them 48 hours to return the funds, and published return addresses for Bitcoin, EVM and Solana. The funds were returned in full, and the investigation was closed on October 4. The protocol pledged to compensate affected users.

How does this kind of monitoring work?#

The system watches the flow of transactions and compares it with the normal pattern: what amounts are withdrawn, how often, to which addresses, and in what order the contract is called. A deviation from that pattern becomes an alert.

Two things can happen next. In one setup the on-call team receives the alert and decides whether to stop the protocol. In the other, the monitor has the authority to pause a contract with no human involved. Crypto Briefing does not say which setup NEAR Intents uses or what data SHIELD was trained on.

What did monitoring do in this case, and what did it not do?#

It caught the attack while it was in progress. The bug was in the code before the first withdrawal, but monitoring checks behavior and does not read code. The source does not say at which withdrawal the alert fired or how much time passed between the alert and the pause. The only known figure is that the patch shipped within an hour.

The return of the funds was unrelated to monitoring. The money came back because the team identified the suspected exploiter and set a deadline.

Why does an automatic pause carry its own risk?#

The pause affected every user: for about 12 hours they could neither deposit nor withdraw on 11 networks. A false alarm would have had the same effect with no attack behind it. The more sensitive the monitoring, the more often such stops occur.

The right to pause a protocol is also a point of control. Whoever holds it can stop every participant's transactions. This is covered in the article on admin keys and timelocks.

What limits and risks should be kept in mind?#

• SHIELD's design is not disclosed. Its rate of false alarms and missed attacks cannot be assessed.
• Monitoring needs time. If an attacker takes everything in one transaction, the alert arrives after the withdrawal.
• The return of funds here depended on the exploiter being identified. One case says little about how exploits usually end.
• The terms of user compensation are not described in the report.
• Monitoring does not replace a code audit: it reacts to the consequences of a bug.