Binance's internal AI tool: what the report says, and what it leaves out

On 3 November 2026 Binance published its initial findings on the 29 October incident. If you are searching for what the Binance hack internal AI tool actually did, the honest answer is that the report does not say. What it does say is enough to draw one conclusion that holds whichever way the public argument goes: the tool was not malicious, its authority was.

We build software that decides what agents are allowed to do, so we read the report with that bias and we say so. This post is a reading of what Binance published, step by step, in its own words where possible. The gaps in the report stay gaps here.

Facts from Binance's initial findings of 3 November 2026, subject to their independent review.

What the report says, in order

Binance names the engineers A, B and C. We keep that. All times are UTC as given in the report.

June. Supply chain. Engineer A, on the wallet DevOps team, installs a tampered package from a public package manager while looking for an AI coding tool. Binance detects it, replaces the device and rotates the related credentials. The attacker now knows A's role and A's colleagues.

September. Social engineering. Engineer B is approached through a job platform, interviewed twice, and asked to run an "assignment" repository on a work computer. The code replaces a component of the developer toolchain and opens a channel to the attacker. Endpoint protection does not catch it.

20 October. The pivot. From B's computer the attacker, in Binance's words, "used an internal AI tool to gain control over" engineers A and C, and "soon discovered" a container deployment permission token on A's computer.

29 October, 17:15 to 19:56. The signing service. The attacker logs on to C's computer, uses A's stolen credentials, deploys a container and triggers a script. The wallet signing service accepts 50 transactions that set up on-chain delegations, giving an attacker-controlled contract partial execution rights over a hot wallet.

29 October, 20:05 to 23:56. Outflows. Funds leave hot wallets in several assets. An internal alert fires on the large transfers and withdrawals are suspended. The report notes that suspending withdrawals "could not stop all unauthorized asset movements", because the delegations operated independently of the withdrawal infrastructure.

30 October, 00:10. Revocation. Binance clears the delegation. Because the wallet used a multi-party signing arrangement, the report says, "there was no single private key that could be used to immediately revoke" it, and a procedure had to be built first.

3 November. The report. The tool and its access controls rebuilt, devices replaced, credentials decommissioned, an independent review commissioned, a security research fund and industry initiatives on AI security announced.

Binance states about USD 6.34 billion impacted, about USD 2.85 billion frozen or intercepted, and 98 percent of impacted token assets replenished by 31 October. Binance cites an FBI release attributing the attack to North Korea. We repeat that as the FBI's view, not ours. This was a company targeted by a state actor that absorbed the loss for its users, and the report is a careful document.

Six controls failed. Four were about authority.

Reading the timeline as a list of controls, six failed. Two are detection failures: the tampered package and the implant that endpoint protection missed. The other four are not about detecting anything.

1. A tool whose reach exceeded the person using it. B's session, in the attacker's hands, reached two colleagues' environments through the internal tool. Whatever B's job was, it was not that.
2. A credential valid for whoever held it. The deployment token on A's computer worked nine days later, from a different machine, for a different person.
3. A signing service that did not check the actor's live authority. The report does not say what the signing service checked. It says the service accepted 50 transactions from a script in a container deployed with a stolen token. Whatever it checked, it was not whether the party behind that token was allowed to sign at that moment.
4. A grant one party could not withdraw quickly. The delegations kept working after withdrawals were suspended, and revoking them needed a procedure that did not yet exist.

Our first draft counted three. The fourth is easy to miss because it happened after the money moved, but it is the same failure in a different place: authority was granted faster than it could be taken back.

This is the reading we think survives the argument about whether "AI did it". Elliptic, quoted by Yahoo Finance on 2 November, said that "nothing we have seen shows an AI agent making decisions". Binance's own report lists "compromised internal AI tooling" among the techniques. Both can be true. Nobody needs the tool to have decided anything. It only needed to be reachable from a compromised session and to have more reach than that session should have had.

Binance's remediation is mostly rebuilding and more detection. Detection is worth having. It tells you sooner that authority was abused. It does not change what a stolen credential is allowed to do.

Three shapes the tool could have taken

The report says the internal AI tool was used to gain control over two engineers and says nothing about how. We do not know what the tool did, what it was connected to, whose credentials it ran under, or whether it took actions or only surfaced information. Three shapes fit the text, and each is a different way of giving a tool more authority than the person using it.

The tool held standing credentials of its own. An assistant with its own service account, reachable from any employee session, with access beyond the operator's own. Its authority was broader than any one user's and did not narrow to the person driving it.

The tool acted as the operator but reached shared infrastructure. An assistant that could run commands, query internal systems or touch other engineers' environments for whoever invoked it. B's session inherited reach it should never have had, with no scope for the task.

The tool surfaced the map and the keys. A coding or knowledge assistant with access to repositories, wikis, chat history or secrets that showed where A's token was and how to reach C. Read access with no purpose binding and no record of what was asked, so the reconnaissance left no trace until the money moved.

In all three the tool was compromised the way agents usually are: not by changing its code, but by changing who was at the keyboard. The same holds when the compromise arrives through the tool's inputs, as a hidden instruction in a document it reads. The UK National Cyber Security Centre made this point in December 2025: prompt injection may never be fully mitigated, so the work is limiting what a confused tool can do, not only detecting that it was confused. A tool keeps whatever authority it was built with, and the systems around it keep trusting it.

Five questions to ask of any internal AI tool

None of this is specific to an exchange. Most organisations rolled out internal assistants this year, and most gave them reach faster than that reach was designed. Each question below has a yes-or-no answer an engineering lead can get in a day.

1. Whose authority does it run under? If the answer is its own service account, it can reach more than the person using it, and so can anyone holding that person's session.
2. Does its reach narrow to the task? If the tool can touch the same systems whether it is fixing a typo or deploying a container, it has a role, not a task scope.
3. What does it hold when nobody is using it? Standing credentials, cached tokens and long-lived keys are the material the next attacker uses.
4. Can a stolen credential drive it? If possession of a token is sufficient to act, the token is the authority. If a named action in a live session, checked by policy, is required, the token is a string.
5. Who can withdraw its authority, and how fast? If the answer involves designing a procedure during the incident, the grant was wider and longer-lived than the task needed.

Copy the list. It works whether or not you use anything we build.

What a session model would and would not have changed

We should be precise here, because the easy version of this post is a vendor claiming it would have prevented the hack. It would not have.

A session model, where every action a tool takes runs under a short-lived permission derived from the person who asked and narrowed to the task, does nothing about the first two failures. A tampered package and an implant on a work computer are endpoint and supply-chain problems. A fake recruiter works on people, not on sessions. An attacker holding an engineer's live sign-in can act as that engineer for as long as the sign-in lasts, within that engineer's scope. And nothing can be refused at a door the service does not sit behind. If the signing path is not inside the boundary, there is nothing to deny.

What it changes is the distance between a compromised laptop and a hot wallet. In Binance's account that distance was one internal tool, one token and one unchecked signing call. Under a session model the tool's reach on 20 October would have been B's own work and nothing wider, so the attempt to reach A and C is refused and written down nine days before any money moved. The deployment right lives in a session, not in a file on a laptop, so there is no portable token to find. A signing step published behind an approval gate in a predefined workflow waits for a person, so a script in a container holds nothing that signs.

Three refusals, each recorded as it happened, instead of one alert after the outflows. That is the whole claim, and it is conditional on the tool and the signing path sitting behind the door.

What to take with you

• Count the failures by kind. In this report, two were detection and four were authority. Fix lists that are all detection leave the four alone.
• A tool's authority should be a function of the person whose task it is, narrowed to the task, and nothing it holds on its own.
• A credential that works for whoever holds it is the authority. Prefer a named action in a live session, checked at the time.
• Put the check at the last point where authority can still be denied. For a wallet, that is the signing step.
• Grant narrow and short-lived, so there is less to withdraw when it goes wrong.

This is the problem Ares is built for. Each agent and tool behind it gets a narrow, time-limited badge per task, derived from the person who asked. Badges, handoffs and expiries go into a record nobody can quietly edit. Each action is checked by name before it runs, and each refusal is written down with its reason. It changes the distance between a compromised laptop and a hot wallet only where the tool and the signing path sit behind the door. Run a scenario in the sandbox and read the refusals in the record of your run.

Facts from Binance's initial findings of 3 November 2026, subject to their independent review. If the review changes the account above, this post will carry a dated update.