Attackers Are Using AI. Our Defenses Must Change.

Attackers are already using AI to find our weak spots. If defenders keep working at the old pace, within the old security boundaries, the next breach may begin somewhere we thought we had already checked.

On November 3, Binance published preliminary findings from its major security incident. The account describes a path from fake interviews and compromised development tools, through internal systems and deployment credentials, to wallet signing. This is much more than an isolated story about a stolen private key.^[1]

A few days ago, I published a call for the crypto industry to rebuild its defenses. The new information makes the next question more urgent: what should we actually change? When attackers can use AI to read code and connect weaknesses, how can defenders use the same tools to rebuild?

We have had to confront those questions ourselves. As ArcBlock's founder, I do not want to discuss only other people's incidents. This article includes our own reassessment.

How a compromised device reaches wallet signing

According to Binance, a fake interview led an engineer to install a project on a work computer in September. Malware replaced the local Python version manager, pyenv. In October, attackers used compromised devices and an internal AI tool to reach colleagues' environments. One person's deployment credentials and another's device ultimately provided a path to signing operations.^[1]

The replacement happened on the victim's machine; it does not establish that the upstream pyenv project was compromised. Nor does the report prove that AI autonomously carried out the entire attack. What matters here is how development tools, job roles, and deployment permissions combined into a path to assets.

The next step is particularly revealing. Through EIP-7702, the attackers delegated account execution to malicious code. Shutting down the usual withdrawal and hot-wallet services did not cancel that on-chain authority. Binance subsequently revoked it on-chain.^[1] Taking a server offline and withdrawing an account's existing authority are different operations.

That distinction is why I think we must revisit system boundaries. Engineers need development tools. DevOps needs deployment permissions. Signing services support the business. Each permission has a reason to exist. Together, do they let a compromised environment acquire far more power than its original role requires? Is the last constraint on moving assets genuinely independent of those environments?

Our own Blocklet Server environment was attacked recently. We detected the attack in time, with no financial loss. The attacker found a subtle authorization-boundary weakness and obtained privileges they should not have had. In our subsequent analysis, the path looked sophisticated enough that we suspected AI-assisted code analysis. That is our technical assessment, not a confirmed attribution of the attack method.

The experience prompted us to use AI to revisit our blockchain, cryptography-related implementations, and open-source dependencies. We found a troubling set of potential issues. Our previously published Blocklet Server security hardening advisory documents some improvements to credential permissions, input validation, and logging.

Each candidate finding needs verification: is the attack path reachable, what privileges does it require, and could the model be wrong? A potential issue may not directly cause a loss. But these findings already force us to ask what our earlier reviews never covered.

James Reason's Swiss cheese model offers a useful way to understand the risk. Imagine defensive layers as slices of cheese with holes. A later layer may stop what an earlier one misses. When a path passes through several gaps, local weaknesses can combine into an incident.^[2]

This illustrates how risks can combine, not Binance's internal architecture. Some vulnerabilities are serious enough on their own. Layered defenses help prevent one gap from becoming a failure of the whole system.

One worrying change is AI's ability to read large amounts of code quickly and look for connections between scattered weaknesses. In a campaign disclosed in 2025, Anthropic reported attackers using AI for reconnaissance, vulnerability discovery, and lateral movement. It also documented model errors and false conclusions.^[3] We do not need to believe AI is infallible before changing how we defend our systems.

Audit again, and reconsider what earns our trust

Reading a large codebase and tracing permissions across modules once demanded enormous amounts of time and experience. AI coding agents can now do an initial pass and keep doing it. Defenders have the source, the operating environment, and the design context. We should be better placed than outsiders to verify what they find.

The difficult part often starts after discovery.

A piece of code may support years of compatibility. An old key format may already be embedded in users' backups. A permission that clearly ought to be removed may be shared by several services. AI can help find the problem; it cannot spare a team the cost of migration. Years of accumulated work still matter, but the parts we find hardest to change may be exactly what an attacker wants to study.

I want to see continuous AI-assisted auditing along real permission boundaries: examining inputs, dependencies, and state changes; turning suspicions into reproducible cases; and having people and independent tools verify them. Fixes need regression checks that demonstrate the old problem stays fixed. A long report of supposed vulnerabilities means little without reproduction, remediation, and verification.

The auditing agent needs boundaries too. Reading source and reproducing a finding should be isolated from production keys and deployment permissions. Code comments, dependency instructions, and test output are material to examine, not authority to expand its permissions. An auditing tool with unrestricted access through production would recreate the very attack path we are trying to remove.

This also makes me reconsider a familiar claim in crypto: open source is safer because countless eyes are watching.

Open source creates an important opportunity for scrutiny. Making code available and having people continuously examine and repair it are different things. Attackers can now read that same source with a specific objective and AI assistance. Waiting for a helpful stranger to happen upon a problem becomes an increasingly passive defense.

Source visibility alone is not a security guarantee. Public source and source disclosed only to customers or designated auditors both need reproducible audits.

Restricted source disclosure, common in enterprise systems, deserves a serious discussion too. It can limit direct access to source and give teams room to coordinate a fix. There are costs: fewer independent reviewers, greater dependence on the vendor, and attackers who may still learn through reverse engineering, leaks, or exposed interfaces. Closing the source does not make vulnerabilities disappear.

AI gives users more ability to inspect software themselves, provided they can obtain the material they need. Whatever the disclosure model, the questions should become more specific. Which version was examined? Can the finding be reproduced? Has the fix reached the running system? A certification badge, a polished audit report, or a public repository cannot answer those questions by itself.

A wallet needs more than a harder-to-steal key

Hardware-wallet maker COLDCARD warns affected users that a firmware update can correct future seed generation without repairing an already affected seed. In a separate incident, Ledger described modified devices reentering distribution and capturing recovery phrases during setup. The entry points differ. Both show why security must cover generation, delivery, backup, and recovery, beyond the hardware boundary.^{[4] [5]}

When randomness fails, users may be at risk without voluntarily disclosing a private key. A response that leaves someone who already knows there is a problem racing to move every asset with the old key is fragile.

We are putting more design work into passkeys, mature secure-hardware capabilities, key rotation, and recovery. ArcBlock's blockchain already supports native passkey accounts in v1.19.x. Having a signing capability available is still a long way from completing a more reliable wallet system.

Passkeys are worth adopting. They prove identity with cryptographic keys and bind sign-in verification to the correct website, reducing certain phishing risks and drawing on established device-security capabilities. But passkeys can be synced or device-bound. We cannot assume every key stays forever inside one chip. Account recovery, lost devices, and what the user is actually approving still need careful design.^[6]

Successfully unlocking a device does not mean approving a sensible transaction. Even if a key is never exported, compromised software can steer someone into signing the wrong request. That is why I would not describe wallet improvement simply as replacing seed phrases with passkeys.

Enterprise security has useful lessons about the complete key lifecycle: generation, use, permission limits, rotation, revocation, and recovery. A long-lived account should not have to share the fate of one permanent key. An everyday payment key can have a small allowance. Large operations require a separate, independent authorization. The everyday key must not be able to rewrite its own recovery rules. These mechanisms carry design and usability costs. Products need to handle those costs rather than pass them all to users with an instruction to protect their seed phrase.

Individuals and exchanges should be able to share some foundational wallet capabilities: clear rules for who can move which assets, how much, where, and how to revoke that authority after an incident. A consumer's spending wallet and an exchange's hot wallet need different policies. They should not each have to invent an opaque permissions system from scratch.

The practical question is simple: once we know a key or environment is compromised, can we still apply the brakes?

Traditional payment systems have incidents too, but they treat limits and intervention as part of the business. Visa Transaction Controls can apply rules during authorization. Swift's Stop and Recall provides a process for stop-payment and recall requests. The latter depends on applicable conditions and cooperation; it does not promise recovery of every finally settled payment.^{[7] [8]}

Blockchains cannot simply import banking's power structure. We should still learn from its preparations: limits, delays, pauses, revocation, and fresh authorization after recovery. Bitcoin scripts and Ethereum contracts already provide some relevant tools. What is missing is a widely usable, easy-to-configure, rehearsed experience. Ordinary native BTC and ETH transfers also have no issuer with a universal freeze switch.

USDC offers a different comparison. Under specified conditions, its issuer can prevent an address from sending or receiving USDC, but cannot reverse a completed transfer.^[9] Freezing can restrict further movement while introducing dependence on the issuer. That is a different allocation of power from a user's own preselected loss-limiting rules.

My preference is for users to choose their constraints in advance: a waiting period for large transfers, independent confirmation for a new recipient, and an emergency pause that can stop spending without redirecting the assets. Who can trigger it, how it is lifted, and how abuse is prevented all need a publicly documented design. An administrator who can take the assets at will merely moves the risk elsewhere.

Crypto Frontier: build where the rules can be verified

These improvements need smaller, clearer rules underneath them.

Enterprise systems often express access control through rules or a dedicated policy language. Separating what an operation may do from complex business logic makes independent review easier. A policy language is still implemented in software; a bad rule is still dangerous. The useful lesson is to reduce the amount we must trust and prevent everyday business operations from casually rewriting their own constraints.

Ethereum has access-control, timelock, and pause tools. The Ethereum Virtual Machine, or EVM, which executes its contracts, has security foundations.^[10] Applications still have to use those tools correctly. Someone who can replace the contract performing a check, or hand execution to code outside the same restrictions, may defeat the protection. Which asset policies could become uniform, independent constraints instead of something each wallet or protocol has to assemble again?

The 2017 Parity incident remains a painful historical lesson. A shared program library was destroyed; several wallets still existed but could no longer move their funds.^[11] EVM behavior and tooling have changed since then. The specific vulnerability cannot simply be projected onto today's systems. The underlying question survives: does my last line of protection depend on the same code that can fail or be replaced?

Consider a design worth discussing. An everyday key can make small payments only to previously confirmed addresses. Changing the allowance or recipient list requires approval from two of three separately held management keys, followed by a one-day wait. An emergency pause can stop spending, but resuming payments requires a separate, prearranged verification process. The everyday key cannot lift it on its own.

Here, independence has a concrete meaning: stealing the everyday key does not let the attacker change the rules and empty the account. The limits are concrete too. If the management keys are not genuinely separated, or enough managers are compromised together, the protection can fail. Different assets, delegations, approvals, and transfer paths must all obey the same restrictions. Protecting only the payment button in the interface is insufficient.

AI can help flag suspicious requests, recommend additional verification, or trigger a pause within previously granted authority. It should not become an unexplained final arbiter with arbitrary control over assets. Blockchain nodes must apply the same rules to agree on a ledger. An answer that changes with the model or its context cannot simply become the judgment every node must accept.

That is what Crypto Frontier means to me: building the next verifiable line of defense along the boundaries where existing defenses have failed.

Of the seven proposals in my earlier article, this one concentrates on two: bounding asset authority and making wallet recovery safe. Reducing trading services' control over user assets, disclosing only necessary information, isolating and replacing failed components, enabling users to verify on-chain evidence, and sharing detection and response experience extend that line outward. The earlier article discusses them in full. We do not need to finish all seven before improving one.

Identity standards can help. W3C's Decentralized Identifiers, or DIDs, describe identities and how to verify them. Verifiable Credentials, or VCs, carry claims whose source can be checked. A credential establishing someone's qualifications still needs an authorization policy to determine what they may do now and within which limits.^{[12] [13]} Similarly, a wallet verifying evidence that a transaction was recorded on-chain reduces blind reliance on a remote service. It cannot recognize every scam for its user.

These problems belong to more than one blockchain. Protocol standards, enterprise security, and traditional payments contain lessons worth testing against crypto's constraints. We should keep what works rather than ignore it because it comes from a different technical tradition.

After my earlier article, people shared it, bookmarked it, and got back in touch. Some media outlets requested interviews. Those responses tell me that many people care about this problem. Relatively few have offered to join the work so far. I think that is normal. Agreeing with a direction and committing to long-term construction are different burdens.

We will keep doing the part we can: using AI to examine existing systems, fixing confirmed problems, testing new wallet and authorization mechanisms, and sharing experience that can responsibly be made public. We will distinguish what works today, what we are exploring, and what we still cannot answer.

Attackers have brought AI to our door. We should use it to reexamine the foundations, repair existing systems, and build the next line of defense. Crypto's new Frontier has to grow from that work.

1. Binance: preliminary findings and response update, November 3, 2026. The report dates the incident October 30 in UTC+8; this is the same event recorded as October 29 UTC in the earlier article. The investigation continues. ↩
2. James Reason, Human error: models and management, BMJ, 2000. Full text archived by PMC. ↩
3. Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign, November 13, 2025. The incident account and attribution come from the vendor's disclosure. ↩
4. COLDCARD: Current Security Status, accessed November 3, 2026, including its affected-seed migration guidance. ↩
5. Ledger: Response to the Hardware Implant Attack. The description of the incident's scope comes from the vendor's response. ↩
6. FIDO Alliance: Passkeys. ↩
7. Visa: Getting Started with Visa Transaction Controls. ↩
8. Swift: Stop and Recall API. ↩
9. Circle: Understand Circle's stablecoin blocklisting process. ↩
10. OpenZeppelin Contracts: Pausable. ↩
11. Parity Ethereum: original issue from the 2017 shared-wallet-library incident. ↩
12. W3C: Decentralized Identifiers v1.0. ↩
13. W3C: Verifiable Credentials Data Model v2.0. ↩