AI Is Supercharging Crypto Hacks. Here’s How to Stay Ahead

Artificial intelligence is changing how Web3 attacks are planned, executed, and scaled.

The technology is not necessarily creating entirely new categories of vulnerabilities. In many cases, it is making existing attacks faster and more effective. AI can help attackers analyze code, identify exposed infrastructure, create convincing phishing messages, automate reconnaissance, and adapt social engineering campaigns to specific targets.

The result is a security environment where a small number of highly targeted attacks can cause enormous losses.

According to the CertiK Hack3D H1 2026 report, more than $1.31 billion was lost across 344 Web3 security incidents. That figure was lower than the same period in 2025, but the comparison is distorted by the $1.45 billion Bybit hack. After excluding that outlier, losses were approximately 28% higher year over year.

Other firms use different definitions and datasets. TRM Labs called the first half of 2026 the busiest six months for crypto hacks on record, while estimating total losses below $1 billion.

The numbers do not prove that AI directly caused every incident. They do show that attackers are operating in a more automated and targeted environment. For developers, that means security can no longer focus only on whether a smart contract passed an audit.

It also needs to cover wallets, signing systems, infrastructure, dependencies, monitoring, and the people who control access.

AI is making Web3 attacks more efficient

A successful crypto attack usually requires several steps. An attacker may need to identify a target, understand its architecture, locate privileged accounts, find an exploitable contract or service, prepare a transaction, and move the funds before defenders can respond.

AI can assist with many of these tasks.

Large language models can summarize unfamiliar repositories, explain protocol logic, compare contract versions, and generate test cases. Automated tools can scan public infrastructure and identify exposed endpoints. Generative AI can produce highly convincing messages for developers, operators, and wallet administrators.

This matters because Web3 systems often expose a large amount of information publicly. Smart contracts are open source or reverse engineered. Wallet activity is visible on chain. Deployment addresses, RPC endpoints, governance discussions, and developer identities can often be connected together.

An attacker does not need to break the blockchain itself. They may only need to find one weak link in the surrounding system.

That weak link could be a compromised developer device, an overly permissive service account, an unvalidated API response, a malicious package, or a signing workflow that assumes every approved transaction is safe. That is why production teams need both a reliable RPC gateway and independent on-chain data to verify what actually happened after a request is signed.

The Liquid Network incident shows the risk of trusted infrastructure

The Liquid Network incident reported on September 6, 2026, illustrates how serious the consequences can be when a system that connects digital assets to Bitcoin is compromised.

As CryptoCompass reported, approximately 4,000 BTC, worth roughly $320 million at the time, was withdrawn from the Liquid Federation wallet. Liquid paused Bitcoin deposits and withdrawals while investigating. The associated transaction involved a peg out of approximately 3,996 LBTC.

Reports described the attackers as purported white hat hackers, but the label should not be treated as a conclusion about the incident. The key technical question is not simply who initiated the transaction. It is whether the transaction was authorized under the intended rules, whether the corresponding LBTC was properly burned, and whether the amount released matched the system’s accounting state.

A peg system depends on that relationship. Bitcoin is locked on one side, while a corresponding representation is issued on the other. When users redeem the representation, the underlying Bitcoin should be released according to strict conditions.

If the release process can be triggered without the expected burn, authorization, or accounting checks, the system may release more collateral than it can support.

That is why bridge and peg security requires more than signature validation. A transaction can be correctly signed and still be invalid from the perspective of the protocol’s economic state. Teams that custody or monitor wrapped BTC should reconcile supply against reserves with wallet and token APIs, not only with a successful RPC response.

Authorization is not the same as validity

This distinction is important for every Web3 developer.

A signature proves that a private key or authorized signer approved a transaction. It does not prove that the transaction is correct.

A valid signature does not guarantee that:

• the amount is within the user’s balance
• the asset supply remains fully collateralized
• the transaction follows the intended state transition
• the recipient is correct
• the withdrawal corresponds to a legitimate deposit or burn
• the transaction is consistent with the latest block or oracle state

Systems that rely only on authorization checks can therefore approve transactions that are technically valid but economically destructive.

Developers should validate both the signer and the state transition. For high value operations, that usually means checking balances, nonce values, supply limits, reserve levels, burn events, destination addresses, and transaction context before funds are released.

These checks should happen independently wherever possible. If the same compromised service both generates and validates a withdrawal, the system has no meaningful second line of defense. Isolate signing with something like Tatum KMS, and verify the resulting transfer against chain state before treating it as settled.

Why wallet compromise is becoming more important

Smart contract bugs remain common, but wallet and access compromises are becoming more financially damaging.

The same Hack3D data shows wallet compromise generated more than $444 million in losses during the first half of 2026 across only 33 incidents. Code vulnerabilities were more common by incident count, with 204 recorded cases, but wallet compromises produced substantially larger losses per event.

This difference matters.

A contract vulnerability may affect one function or one pool. A compromised wallet with broad permissions can sometimes move treasury funds, upgrade contracts, change configuration, or approve arbitrary transfers. That is the same lesson behind custodial vs non-custodial wallet design: blast radius is a product decision, not just a key-storage detail.

AI makes the surrounding attack process more efficient. It can help identify which wallets matter most, determine when operators are active, generate realistic messages, and adapt quickly when a target does not respond.

The attack may begin off chain, but the final loss appears on chain. Before you accept a counterparty, withdrawal destination, or new admin, run it through a malicious address check and keep an independent wallet risk view in the same flow.

Social engineering is becoming more targeted

Phishing has not disappeared. It has become more selective.

Phishing incident volume fell by more than 50% year over year in the first half of 2026, while losses declined by only around 11%. Attackers moved from broad campaigns toward a smaller number of high-value social engineering attacks. Four incidents accounted for approximately 85% of phishing losses in the period.

That pattern is consistent with how AI can be used by attackers, and with what we already see in Tatum’s State of Crypto data: a large share of malicious activity still starts with people, not with Solidity.

Instead of sending thousands of generic messages, an attacker can create a smaller number of highly personalized communications. They can imitate a project contributor, reference a real proposal, use the correct technical vocabulary, and send the message at a moment when the recipient expects an urgent action.

For engineering teams, this means security training cannot focus only on obvious spelling mistakes or suspicious URLs. Developers and operators need a process for verifying sensitive requests through a second channel.

No message should be enough to authorize a production deployment, key rotation, treasury transfer, or contract upgrade.

AI agents introduce a new class of risk

The next concern is not limited to attackers using AI against humans. Developers are also giving AI agents access to tools that can interact with blockchain systems.

An agent may be able to read balances, call APIs, create transactions, manage liquidity, or submit signed operations. That can be useful, but it creates a dangerous boundary between natural language instructions and irreversible financial actions. If you wire an agent to chain data through MCP, treat every tool as a privileged interface.

A prompt injection attack could cause an agent to treat untrusted data as an instruction. Tool abuse could make the agent call a privileged function in an unsafe context. Poorly scoped permissions could allow a mistake to become a real transaction.

Blockaid has warned that AI agent incidents could become more common in the second half of 2026, with prompt injection, tool misuse, and unauthorized signing among the expected attack paths.

Developers should assume that any external content processed by an agent may be adversarial. Transaction signing should therefore remain isolated from general purpose reasoning. An agent can prepare a transaction, but a separate policy engine should verify its destination, value, method, permissions, and expected result before signing is even considered.

Practical security lessons for Web3 developers

Validate state, not only signatures

Every important transaction should be checked against the latest system state.

For withdrawals, compare the requested amount with the user’s eligible balance, the recorded deposit or burn, the reserve balance, and any protocol limits. For contract upgrades, verify the implementation address and governance state. For treasury transactions, enforce destination allowlists and value limits.

The exact checks depend on the application, but the principle is general: authorization is only one part of validity.

Reduce the power of individual keys

Avoid giving one wallet unlimited control over funds and system configuration.

Separate operational roles where possible. A key used for routine administration should not also be able to upgrade contracts or drain reserves. High value actions should require multiple approvals, time delays, or independent review. Wallet infrastructure should make those constraints the default, not an afterthought.

If one compromised device can immediately move all assets, the system has a single point of failure.

Monitor successful transactions

Monitoring only failed transactions is not enough.

Attackers may use valid credentials and submit transactions that pass every basic validation rule. Teams should monitor unusual destinations, sudden changes in transaction size, new contract interactions, abnormal timing, permission changes, and deviations from normal user behavior.

On-chain notifications should fire on the transfers you expect as well as the ones you do not. Alerts should be connected to an actual response process. A notification that nobody reviews is not a security control.

Build emergency controls before an incident

Pausing deposits and withdrawals can limit damage, but only if the pause mechanism works and the team knows when to use it.

Emergency controls should be tested in staging and reviewed regularly. The team should understand which actions remain available during a pause, who can trigger it, and how the system can resume safely.

A pause function that depends on the same compromised infrastructure as the main system may not provide meaningful protection.

Treat dependencies as part of the attack surface

Web3 applications depend on RPC providers, indexers, cloud infrastructure, wallet libraries, signing services, package registries, monitoring systems, and deployment pipelines.

A smart contract audit does not assess all of these components.

Teams should maintain an inventory of critical dependencies, pin package versions, verify builds, restrict production credentials, and review third party integrations. A vulnerable dependency can become an indirect path to a perfectly audited contract. That includes how you consume RPC: a single poisoned node is enough if nothing independently verifies the response. A multi-node gateway with failover is a reliability feature and a security control.

Put strict limits around AI tools

AI tools should not receive unrestricted access to production wallets or deployment systems.

Use least privilege. Separate read access from write access. Require explicit confirmation for irreversible actions. Log every tool call. Validate both the input and the proposed output.

Most importantly, do not allow an AI system to decide on its own whether a transaction is safe simply because it generated that transaction.

What the Liquid incident means for bridge developers

The Liquid incident also raises a broader question about bridge design.

Bridges and peg systems concentrate risk because they connect separate environments and often control large reserves. A failure in one authorization flow can affect an amount far larger than the value held in a single user account. That is why bridge selection is an engineering decision, not only a liquidity decision.

That does not mean every bridge should be avoided. It means developers need to understand the trust assumptions behind the bridge they are integrating.

Before relying on a bridge, teams should examine how deposits are verified, how withdrawals are authorized, how reserves are reconciled, how signer compromise is handled, and how quickly the system can be paused.

They should also ask what happens if one internal component lies.

Can the accounting service claim that an asset was burned when it was not? Can a stale oracle authorize a withdrawal? Can a compromised signer approve an amount outside protocol limits? Can the system detect a mismatch before the underlying funds leave custody?

These are engineering questions, not merely governance questions. For Bitcoin-backed assets, you should be able to answer them from Bitcoin chain data and the wrapped-asset ledger at the same time.

Security needs to become an operational discipline

The most important lesson from the 2026 incident data is that Web3 security is no longer limited to finding bugs before deployment.

Teams must also assume that keys will be targeted, dependencies will fail, operators will be deceived, and automated systems will eventually produce unexpected outputs.

The strongest defenses are layered. They combine audited code with independent accounting, limited permissions, transaction simulation, anomaly detection, tested emergency controls, and clear operational procedures. That is the same posture behind enterprise-grade infrastructure and compliance workflows: assume something will fail, then make sure one failure cannot empty the treasury.

AI will continue to improve both defensive and offensive capabilities. Developers should use it to review code, generate tests, detect anomalies, and accelerate incident response. But the final security model should not depend on an AI system being correct every time.

Conclusion

The increase in Web3 security losses during 2026 is not explained by one vulnerability or one type of attacker. The ecosystem is facing a combination of code flaws, wallet compromises, infrastructure attacks, targeted social engineering, and increasingly automated operations.

AI is amplifying that environment by helping attackers move faster and personalize their campaigns. At the same time, AI agents are creating new risks when they receive access to sensitive tools without strict controls.

The Liquid Network incident is a useful reminder that a signed transaction is not automatically a valid transaction. Developers need to verify the signer, the state transition, the accounting, the collateral, and the economic limits around every high value operation.

In Web3, security is not just about preventing unauthorized actions. It is about making sure that authorized systems can only do what the protocol is actually meant to allow.