# Binance heist is stark example of AI governance gaps and basic security failures > Source: > Published: 2026-11-05 21:57:37+00:00 A chain of avoidable technical and human security failures enabled the largest crypto heist on record, [the theft of approximately $6.34 billion from Binance](https://www.csoonline.com/article/4243225/a-compromised-devops-laptop-caused-the-6-3b-binance-breach.html). The improper monitoring and access scoping of an internal AI tool played a major role in helping the hackers, and should serve as a warning for enterprise CISOs to take AI governance seriously. Binance’s [initial findings report](https://x.com/binance/status/2117626126214504729), published Nov. 3, describes a months-long, multi-stage campaign against its wallet-infrastructure engineers that resulted in malware being installed on developer machines in two separate incidents, only one of which was detected. The attackers were then able to pivot through an internal AI tool to additional developer systems, obtain an access token, and deploy a container on Binance’s infrastructure before executing the rogue withdrawals. While Binance describes this attack as highly sophisticated, there were multiple security failures involved that could have been avoided, from weak or absent access controls to overly broad privileges, poor credential hygiene, and employee security awareness lapses or policy violations. “Developer workstations have [quietly become some of the most privileged assets](https://www.csoonline.com/article/4127693/software-developers-prime-cyber-targets-and-a-rising-risk-vector-for-cisos.html) in the enterprise, carrying deployment tokens, signing access, and now AI tools that can act across internal systems on an employee’s behalf,” warns Joe Brinkley, director of offensive security research and community at security firm Cobalt. “Once an attacker controls that machine, an AI tool with broad internal reach becomes one more trusted path they can use.” He adds: “Security teams should treat engineers with production or signing access as a high-value attack surface, test the path from workstation to production the way an adversary would, and scope AI tool permissions as tightly as any service account.” [The FBI has attributed the Binance breach to North Korea](https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack), identifying the hacking unit as TraderTraitor, which other researchers consider part of the broader Lazarus operation that [has stolen billions of dollars from cryptocurrency platforms over the past decade](https://www.csoonline.com/article/3831315/bybits-1-5b-hack-linked-to-north-koreas-lazarus-group.html). Binance’s own report relays the FBI’s conclusion and notes that throughout 2026, the company’s security team detected and prevented 57 suspected North Korea–linked cyber threat cases. This suggests Binance has the Lazarus APT in its threat model, as it should, and is well aware of the group’s tools, techniques, and procedures (TTPs), which include software supply-chain compromises, the use of malware that masquerades as popular legitimate tools, [tricking developers with fake job interviews](https://www.csoonline.com/article/3479795/north-korean-cyberspies-trick-developers-into-installing-malware-with-fake-job-interviews.html), and long-horizon social engineering operations. Yet, two Binance engineers fell victim to exactly these tricks, raising questions about the company’s security awareness training as well as its technical controls. In June, a wallet-infrastructure engineer [searched the web for a popular AI coding tool and downloaded a tampered Homebrew installer](https://www.csoonline.com/article/4206851/trojanized-ai-skills-gain-1-7m-installs-in-agent-targeted-attack.html) rather than obtaining the software from a trusted source. Homebrew is a package manager and distribution channel for open-source applications on macOS. Binance’s security team detected the anomaly, replaced the device, and rotated all related credentials, but the attackers had already learned who the engineer was and who else worked on the wallet infrastructure team. It’s good that Binance was able to quickly detect the breach, but the incident raises the question of why an engineer was installing software from a search result at all. Does Binance have a policy that employees install software only from approved sources, and is this enforced with technical controls such as application whitelisting? Three months later, the attackers approached a second engineer through a job-hunting platform, posing as a project director recruiting for a company that did not exist. Two staged interviews followed: one with a purported HR representative who shared a social media account filled with personal photos and videos to build trust, and one with someone claiming to be the company’s CEO. At the end of the second interview, the engineer was told to download a coding assignment onto their work computer from a repository. The assignment included malicious code, and this time Binance’s endpoint protection tools did not detect it. The company described this as zero-day malware, but if endpoint protection tools were only capable of detecting known malware, then the whole industry has a problem. Either way, the developer’s actions raise a number of questions regarding security policies, procedures, and awareness at Binance, first among them: Why was the engineer doing job interviews and test assignments on their work computer? Why did they clone a repository directly on their system instead of using a virtual machine? If this is something they regularly do, then it points to lapses in security training or intentional policy violations. And companies cannot solely rely on employees always following policies. They need detection and enforcement mechanisms. “The engineer did multiple things wrong,” says Tim Chase, AVP for cybersecurity at human-risk management company Fable Security. “A modern risk program should have ensured he understood the modern [attack] surface of social engineering that attackers are using today.” Binance did not respond to CSO’s questions on whether it had policies in place that explicitly prohibited the developer’s actions on work computers and whether its employee training covered the fake recruitment social engineering tactic commonly used by North Korean hackers. Once the attackers had malware running on the engineer’s computer, they were able to use an internal AI tool present on it to pivot to additional machines belonging to two other engineers from the wallet infrastructure team. Binance did not clarify the purpose of this tool in its report or to CSO, but the fact that it could be used by one compromised user to access different computers [suggests its privileges were too broad or that it lacked proper access controls](https://www.csoonline.com/article/4213883/who-is-accountable-when-your-ai-agent-goes-rogue.html). This is hinted at by the company in its list of remediation steps, which included: “Rebuilt the affected internal AI tool and access controls.” On one of the additional engineering computers, the attackers found a token with permissions to deploy new containers on the company’s infrastructure. Nine days later they used this token on a different compromised engineering computer to deploy a container with a malicious script that interacted with the wallet signing service and initiated withdrawals. This series of events raises additional questions about credential hygiene and access controls because Binance’s report doesn’t describe any additional checks. Why was the token long-lived and not ephemeral for a single operation? Did deployment of containers to production involve additional validation or approval steps? Is there any authentication between the deployed container and the signing service, or was being on the same trusted network enough? Binance did not respond to CSO’s questions about any of these points. “An internal AI tool that can reach engineers’ systems holds the same kind of access as a privileged employee, and most organizations don’t govern it that way,” says Justin Beals, CEO of Strike Graph. “Expect more groups to copy this playbook against anyone holding signing keys, deployment tokens, or production access. Security leaders should treat engineers with production access, and the AI tools those engineers use, as privileged identities. That means restricting what gets installed on work machines, expiring deployment tokens quickly, and logging and reviewing what internal AI tools actually do.” Shlomi Salem, co-founder of Neo, a startup focused on AI agent security, predicted the AI attack vector days before Binance released its findings. “I wouldn’t be surprised if investigators find a poisoned package, a misused agent, or both at the start of this chain,” he said on Oct. 30 after the breach was announced. [The takeaway for organizations is that internal AI tools are now part of the attack surface](https://www.csoonline.com/article/4218440/securing-ai-agents-key-controls-and-best-practices.html) and need to be tested accordingly, Bri Frost, director of product management at Cloud Range, tells CSO. “When an AI tool can reach other systems on an employee’s behalf, an attacker who controls that employee’s machine may inherit everything the tool can do,” she says. “That changes the question security teams need to answer. It’s not only whether the model gives good answers, but what it will do, and for whom, when a request comes from a compromised session.”