Binance Didn't Lose a Key. It Lost Authority.

On 29 October, starting at 20:05 UTC, Binance's hot wallets on ten blockchains were emptied of $6.34 billion. Most of it left in about twenty minutes. The FBI has attributed the operation to TraderTraitor, the North Korean unit behind the 2025 Bybit theft. Binance covered 98% of affected user assets from its own funds and published its initial findings on 3 November.

This is a review of what went wrong, for people who run identity and security programs rather than exchanges. It is not one catastrophic mistake. It is five months of smaller oversight errors that nobody saw as a single chain, and one of them is sitting in most companies right now. Each stage below separates what Binance and the analysts have said from what we infer, with a confidence level on every guess.

An internal AI tool had reach across the wallet team, and that reach was neither monitored nor controlled as the trust boundary it was.

No private key was stolen. The signatures that emptied the wallets were valid because the attacker had reached the signing service that produces them. That is a consequence. The cause sits further up the chain, on a laptop, in a tool few organizations have thought about as a trust boundary.

Five Months of Preparation, Twenty Minutes of Theft

June: a tampered installer maps the wallet team

Fact. Engineer A, Wallet DevOps, searched for a popular AI coding tool, landed on a page that had him install a tampered Homebrew. Binance detected it, replaced the device and rotated every related credential. The attacker left knowing A's role and his wallet-team colleagues.

Guess (medium confidence). The spring 2026 malvertising wave faked Homebrew pages and Claude Code and Gemini CLI installs, and SANS ISC documented one such ad delivering the MacSync stealer in May. Stolen Slack or Jira sessions would explain the org chart.

Note the word "rotated". In October a live container-deployment token was still sitting on A's computer, and it is the one that mattered.

September: a fake recruiter lands malware on a work laptop

Fact. A "Project Director" reached Engineer B on a job platform. "HR" and a "CEO" interviewed him over video and chat, and B ran the take-home assignment on his work laptop. Binance's file-operations log shows the setup script swapping Homebrew's pyenv for a copy 70 bytes larger, relinking it, opening a command channel and wiping its traces. No privilege escalation was needed, since Homebrew's directory belongs to the user. Endpoint protection saw nothing.

Guess (medium confidence). The platform was LinkedIn, the chat app Telegram, and the toolkit TraderTraitor's fake-interview kit of the BeaverTail lineage. Why pyenv? Every Python call runs through it, so the implant persists without root and without a new process to flag.

20 October: an internal AI tool bridges two teams

Fact. In Binance's words, the attacker "used an internal AI tool to gain control over" Engineers A and C from B's computer. The report does not say what the tool is or how a session on one laptop yielded control of two others. Binance has since rebuilt the tool and its access controls.

Guess (medium confidence). Binance's own workforce release says 72% of staff use its internal workflow-execution agent, and an April job listing describes "hundreds of sandboxed agents" with tool execution in the brief. Read together: an agent platform that executes tools in engineers' environments with the invoking user's authority. Authenticated as B, the attacker drove it. No exploit and no prompt injection are claimed. It worked as designed. Mace AI reads the tool as having had more access than the engineer using it. That is their interpretation, not a finding.

Remember to this stage. It is the one that transfers.

29 October: a container reaches the signer, and the wallets empty

Fact. Between 17:15 and 19:56 UTC the attacker logged onto Engineer C's computer, used A's stolen token to deploy a container, and triggered a script that reached the internal wallet signing service. From 20:05 the hot wallets drained: XRP Ledger, Solana, Optimism, Bitcoin, Tron, then Ethereum at 20:24, with a second wave on Avalanche and Polygon at 23:05, after withdrawals had been paused. On nine of the ten chains these were ordinary, valid, signed withdrawals.

Guess (medium confidence). It worked from C's machine because the deploy token was bearer-style, bound to neither device nor session. The container then ran beside the signing nodes as a trusted workload, and the signer checked who was calling rather than what was being signed. Halborn's follow-up asks the open question precisely: how did the service decide that a container deployed with an engineer's platform token was a valid client?

Ethereum, $3.79 billion of the total, used a trick worth one paragraph. The attacker had the signer sign an EIP-7702 delegation, which makes an ordinary account run attacker code whenever it is called. The hot wallet became a sweeper: everything it held left in one transaction, and a $200 million top-up Binance sent in at 21:44 was swept within a minute, saved only by Tether's blacklist. Revoking the delegation took until 00:10, which Halborn attributes less to MPC than to the absence of a rehearsed path for it. Same lesson as everywhere else in this story: the signer signed what it was handed.

Five Hops, Four Boundaries, No Alert

Two of the five hops ran through endpoint protection, and neither was stopped in time: the June installer was caught after the attacker already had the wallet team's names, the September implant was not caught at all. Worth knowing, but not the lesson. Endpoint tools miss things. The question is what happens next.

What happened next is that every other control worked, separately. The AI tool obeyed an authenticated user. The token was valid. The container was deployed by a valid token. The signer signed valid requests from the right network. An IAM system, a secrets store, a container platform's audit trail, a signing log: five hops, four boundaries, five logs, and not one alert that said this is the same actor, three machines deep, holding a deploy token that is not his. Each boundary asked "is this request well-formed, and is the caller allowed?" and got yes. None of them could ask the question that mattered: under whose authority is this happening, and should that authority reach this far?

CoinEx's Haipo Yang listed three avoidable mistakes: no dedicated devices for production access, one credential enough to run production and MPC signers that did not verify what they signed. All true, and all symptoms of one condition. The AI tool was treated as an application, something a user logs into, rather than an identity. With a distinct identity, the tool acts under a specific policy, has a clear owner, and leaves a record of what it did and on whose behalf. So when B's session asked it to reach into A's and C's environments there was nothing to evaluate: no agent to attribute the request to, no owner whose scope could bound it, no policy able to say an agent acting as B does not operate in A's environment without A knowing. Vectra put it well: the tool let attackers walk between teams. That is a trust-boundary crossing. It was logged as a feature.

What Would Have Broken the Chain

An agent cannot quietly outgrow its owner if both live in one identity system. Keep people in the IdP and agents in a platform with its own accounts and tokens, and nothing ties the two together: the agent's reach grows with every integration, and nobody is placed to notice when it passes the reach of the person it acts for. Make the agent an identity in the same system as the engineers, under the same policy and in the same log, and its authority derives from its owner's and is checked when it is used. My colleagues have made the pieces of this argument before: every agent action needs an owner, access is not authority, agents are not service accounts, and agent access has to be controlled when it is used. The Binance chain is what happens when none of those hold.

If we replay 20 October with the agent treated as an identity, the result is quite different:

1. 1.The request. Authenticated as B, the attacker asks the agent to act in A's environment.
2. 2.Not in B's scope. The agent has its own owner and policy, and reaching another engineer's environment is not something it may do unasked.
3. 3.The owner's phone lights up. A sees the agent, the action, the resource, the scope and the risk, with a time limit on the decision.
4. 4.Refused, or simply expired. The chain breaks nine days before the theft, and one log records who tried, under whose authority, and what was decided.

Had A approved, the agent would have received short-lived, task-scoped access for that one request, never A's deploy token. Halborn, reviewing Binance's report, says the same in a security firm's words. Internal AI tools “belong in the threat model, today”: give each “its own identity and least privilege”, “deny it standing access to credentials and to anything that signs”, “log every action it takes on a human's behalf”, and test “that one compromised user cannot reach another through it”.

What It Would Not Have Stopped

The first two stages are people and endpoints. The infostealer and the interview malware land the same way with or without identity governance, the zero-day still walks past EDR, and TraderTraitor keeps trying, 57 times this year by Binance's count. What changes is the blast radius once the laptop is lost: an owned laptop no longer owns the wallet team, and nothing downstream holds a standing secret to pick up and reuse. One more limit is on us: a control that can be routed around is not a control. If the governed path is slower than the ungoverned one, engineers will wire around it within a quarter.

Authority, Not Keys

Binance has rebuilt its signer and its AI tool, and replaced the machines. Those fixes sit where the damage became visible. What made the chain possible sits earlier, and it is two identity problems every company running agents now has.

Standing credentials: a deploy token sat on a laptop and worked from another machine because nothing bound it to a device, a session or a task. When the fastest actor on your network is an agent that will use whatever it finds, a credential that outlives the request is a liability by design. Access should be minted for one task and gone when it ends.

Agents governed as applications: a tool with reach across the wallet team had users and logs, but no owner, no scope and no policy evaluated at the moment of use. Whoever owned one engineer owned everything it could reach.

These are the two problems we set out to solve at NewCore: people and agents in one identity system, with no standing access, a named owner behind every agent, and a team boundary crossed by decision rather than by accident.

Binance did not lose a key. It lost control of who was allowed to act as whom. Identity was invented for exactly that problem. It now has to solve it for agents too.