The theft involved approximately $6.3 billion across ten blockchains, much of it moved in roughly 20 minutes. But the sequence Gabi described unfolded over several months.

In June, an engineer on Binance’s wallet infrastructure team downloaded a tampered Homebrew installer while trying to install an AI coding tool. Binance detected the incident, replaced the device, and rotated the relevant credentials. The attackers nevertheless obtained information about the engineer’s role and colleagues, and that knowledge helped set up the next stage.

In September, another engineer was approached through a legitimate recruitment platform. A fabricated hiring process, complete with an HR interview and a supposed company CEO, culminated in a coding assignment. Running that assignment on a work computer introduced malicious software into the environment.

The compromise then spread. An internal AI tool provided a route to two more engineers, and the attackers obtained a token that permitted container deployment. On October 29, they used that access to run a script that reached Binance’s internal wallet signing service.

As Binance’s preliminary findings explain, the attackers initiated transactions outside the normal withdrawal process. They had reached the infrastructure that could authorize transfers.

For Gabi, that distinction was important:

“The keys did exactly what keys do. What failed was the thing in front of the key that decides what deserves a signature. … The policy lived in the process, and the attacker just walked around it.”

His analysis of the signing-service compromise examines that boundary in greater detail: protecting key material does not, by itself, establish whether a request to use it should be trusted.

On Ethereum, the attackers obtained an additional form of authorization through EIP-7702, which allows an account to delegate execution to code. That authorization existed on-chain. Suspending Binance’s withdrawal infrastructure therefore did not automatically remove it, allowing malicious activity to continue after withdrawals had been paused. Containment required revoking the authorization itself.

The discussion turned to the relationship between cryptographic protection and operational control. Multi-party computation, or MPC, distributes signing across participants rather than relying on a single complete private key. But a protected signing arrangement still needs rules governing what it will sign, who can request a signature, and how dangerous permissions can be revoked during an incident.

Michael questioned how transfers of that scale could proceed without delays or additional approvals. He also acknowledged that controls might have existed higher in the system, beyond the point where the attackers gained access.

That said, the speakers did not have a complete picture of Binance’s internal configuration. The unresolved question was precisely which safeguards were absent, bypassed, or ineffective at the signing layer.

Gabi’s broader lesson was that custody security must account for the entire authorization process, including emergency actions.

It is easy to read about a malicious coding assignment and assume that an experienced engineer should recognize the danger. The conversation challenged that assumption by looking at the circumstances in which people are persuaded to act.

Naturally, a job opportunity creates pressure to cooperate. A scheduled call with a familiar business contact creates an expectation of trust. Attackers build their requests into those situations.

Michael revisited an experience discussed in the previous Casper and Halborn security X Space. A video meeting appeared to involve a known business acquaintance. An apparent audio problem then prompted him to click something to fix it.

The example gave practical weight to the discussion: technical experience does not eliminate the possibility of being deceived.

For organizations, employee awareness must be backed by controls that limit what a compromised device or identity can reach. Approved communication channels, restrictions on untrusted software, and clear procedures for suspicious requests all matter. So does designing systems around the possibility that someone will eventually make a mistake.

Gabi’s recommendations focused on whether controls would hold up during a real incident.

Signing policies should reject unnecessary authorization types by default. Exceptions should be narrow and deliberate. Emergency procedures must account for the possibility that attackers act while approvers are asleep or unavailable.

Gabi warned against concentrating the people or devices required for authorization in the same location, where a single disruption could make them unavailable together.

A documented response plan is a starting point. Teams also need to rehearse what happens when a malicious actor reaches sensitive infrastructure: whether access can be cut, permissions revoked, and recovery actions authorized quickly enough.

The internal AI tool used in the Binance attack raised a related question. Organizations are introducing agents and automation into workflows, sometimes without a clear inventory of their permissions. Teams need to understand which environments those tools can access and whether one compromised user can use them to reach another.

AI also offers opportunities for defenders. Gabi argued that security teams can use it to test systems more effectively, provided that automated analysis is combined with practical testing and employee training.

For Casper, the discussion connected directly to transaction authorization, agentic payments, and the security work surrounding AstralBeam.

Michael highlighted Casper’s native multisignature functionality, which places signature requirements at the protocol level. He pointed to custody integrations as an example of how providers can use that capability as part of their security architecture.

The location of a control is crucial. A safeguard enforced by the protocol operates at a different layer from an approval process implemented within an application. That makes protocol design an important part of the wider discussion about where authorization boundaries should sit.

The same questions apply when software agents receive permission to make payments.

Michael described Casper’s work around x402 and agentic commerce in terms of bounded authority: specifying how much an agent can spend, over what period, and in which environments.

“You can authorize an agent to spend funds on behalf of an account, but how do you implement the limits? It cannot be a blank check. … You want to be able to give it some governance and some rules, as in: you can only spend certain budgets per time period, $100 a day, and you can only spend it in this particular environment.”

These were presented as active areas of work in Casper’s implementation and its involvement with the x402 Foundation. The aim is to make useful automation possible while defining the limits of what an agent can authorize.

‍

AstralBeam, which connects Casper to Ethereum, Base, Polygon, and Robinhood Chain, provided another concrete example.

At the time of the X Space, Michael described the bridge as approaching its Mainnet launch, with security review by Halborn. He highlighted governance, time locks, and thresholds as considerations incorporated into its design.

Bridges are attractive targets because of the assets they handle. Their security therefore depends on examining how components behave when requests are unexpected, permissions are misused, or assumptions fail.

Michael described that approach in his closing remarks:

“It definitely takes an approach of starting with everything that goes wrong before you build for what can go right. I think that is the primary focus engineers in any security-sensitive environment have to take these days, which is ‘fail closed.’ Anything that is not the design behavior should not be possible.”

• Recommended Article: Killing the Honeypot: How AstralBeam Delivers Secure Cross-Chain Infrastructure for RWAs

The Binance discussion returned repeatedly to that principle. A compromised laptop should have limited reach. A signing service should enforce clear boundaries. An emergency response should work when normal operations have already failed.

Those are questions for every organization responsible for digital assets, and questions that need practical answers before the next incident.

Listen to the full conversation between Casper and Halborn on X.

‍