The Binance hack is a warning: developer workstations hold the keys to your business

On October 30, Binance disclosed that attackers had stolen an estimated $6.3 billion in cryptocurrency from its hot wallets, one of the largest thefts on record. Its initial investigation suggested the attack may have started with a compromised DevOps engineer's laptop, which allowed an attacker to access a service container and submit unauthorized withdrawal transactions.

Binance has since identified additional points of breach, and the investigation is ongoing. Binance hasn't said how the laptop was compromised. But the potential role of a developer workstation illustrates a security problem that extends far beyond cryptocurrency exchanges.

Most companies don't hold billions in crypto hot wallets. But nearly every company gives developer laptops access to source code, cloud accounts, and production pipelines. The question for security leaders is whether one compromised machine could become their own billion-dollar incident.

Developer machines hold the keys to your business. And increasingly, AI coding agents inherit that access.

You can have firewalls, network segmentation, identity controls, and sophisticated cloud security monitoring. All of those protections matter. But they aren't enough if an attacker can compromise a trusted development environment and use its access to reach critical systems.

For security teams, protecting the code developers produce is only half the challenge. They also need to secure the environment that produces it.

Developer workstations are a privileged attack surface

Developer laptops aren't ordinary corporate endpoints. To build, test, and deploy software, developers need access to source code repositories, cloud environments, CI/CD pipelines, package registries, and internal services. Their machines often hold SSH keys, API tokens, authentication sessions, and other credentials that connect those systems, which concentrates an enormous amount of trust in a single device.

An attacker who compromises that device may be able to act through legitimate credentials, execute commands using existing permissions, or access systems the organization already trusts. And the compromise doesn't necessarily need to involve stealing production credentials. Abusing an authorized workflow can be enough.

Prevention still matters, but security teams also need to contain the blast radius. A single compromised laptop, session, or agent should only be able to reach a narrow slice of the business, so one breach can't escalate into a business-critical event.

Traditional application security largely focuses on the software artifact: finding vulnerabilities in source code, identifying risky dependencies, and preventing insecure applications from reaching production.

Those controls remain essential. But they don't necessarily stop malicious code running on a developer's machine, a compromised extension reading local credentials, or an unauthorized command executing in a trusted development session.

These attacks can happen long before a pull request is opened or a CI/CD security scan runs.

The developer workstation is part of the software supply chain, and it needs to be secured like one.

Coding agents inherit that access and act on it autonomously

Now consider what happens when a developer gives an AI coding agent access to that same environment.

Coding agents don't just suggest code. They read and modify files, execute shell commands, install dependencies, invoke MCP tools, and interact with external systems. Depending on their configuration, they may have access to the same credentials, repositories, and infrastructure as the developer running them.

They also act with far more autonomy. A developer might manually evaluate a dependency before installing it or recognize that a command looks suspicious. A coding agent can make dozens of those decisions while completing a single task, at machine speed, usually without a human reviewing each action.

That autonomy gives attackers new ways to exploit trusted development environments. A malicious dependency can execute code during installation and attempt to steal credentials. A compromised MCP server or skill can expose sensitive information or introduce unsafe behavior. A prompt injection hidden in a repository file or tool response can try to convince an agent to execute commands unrelated to the developer's original request.

And an agent can inadvertently amplify the damage by following those instructions using the permissions and tools it has been given.

This is why securing coding agents cannot rely entirely on prompts, permission settings, or asking the model to recognize malicious behavior. Those safeguards have value, but they aren't independent enforcement boundaries.

A powerful model is not the same thing as a safe system. Security controls need to govern what an agent can actually do, not just what it has been instructed to do.

Those controls also need to follow agents wherever they run. Teams increasingly run coding agents in cloud sandboxes, CI pipelines, and background task services, often with their own tokens and repository access. A control that only exists on a managed laptop won't cover them.

The next developer workstation might belong to someone in marketing

There's another reason this attack surface is growing: software development is no longer limited to engineering teams.

AI coding agents make it possible for almost anyone to build software. Marketers are creating applications and automating campaigns. Sales teams are building integrations and internal tools. Finance teams are writing scripts to analyze data and automate reporting.

We see this in our own environment. When we rolled out Package Firewall internally, 21% of package firewall events came from outside engineering.

These employees may never have opened an IDE before. Now they're running coding agents, installing open source packages, and connecting tools to corporate systems.

They also may not have the same experience evaluating dependencies, recognizing suspicious commands, or understanding what happens when they give an agent access to local files and credentials.

For security teams, that changes the scope of the problem. It's no longer sufficient to secure a known set of engineering laptops or apply controls only to repositories managed by the development organization. Every employee using a coding agent may become part of the software development environment.

And because those employees are often building small internal tools rather than production applications, their activity may never pass through the established security processes designed for software engineering teams.

Banning employees from building with AI won't hold, and it would give up real productivity gains. A better approach puts guardrails directly into the workflow, at the moment a package is installed or an agent takes an action, so everyone doing development work gets the same protections without having to become a security expert. Friction should show up only where the potential damage justifies it.

Securing the development environment requires two layers of protection

Protecting developer workstations and coding agents requires controls that operate before risky actions execute, not just tools that identify problems afterward.

1. Govern the actions coding agents take

Security teams need visibility into which coding agents are running across the organization, which models they use, and which MCP servers, skills, and other tools they can access.

Visibility is only the starting point. When a coding agent attempts to execute a shell command, read a sensitive file, or call an external tool, there needs to be an opportunity to evaluate that action against security policy before it happens.

For example, an agent might legitimately need to read application source code to fix a bug. That doesn't mean it should be allowed to read an employee's SSH private keys or export environment variables containing cloud credentials.

Similarly, an approved MCP server doesn't mean every operation it exposes should be permitted.

Credentials deserve the same scrutiny. An agent session should get the narrowest access its task requires, not every token and authenticated session sitting on the developer's machine. If an attacker hijacks that agent, they reach far less than the developer could.

Native hooks in coding agent execution environments provide a way to enforce these boundaries. They can inspect consequential actions as agents attempt them and apply deterministic policies to allow, block, or audit the behavior.

This puts security enforcement inside the agent loop, rather than depending on the model to decide whether its own actions are safe.

The distinction matters: the agent can determine how to complete a task, but it doesn't get to determine which security boundaries it can cross.

2. Stop malicious software before it reaches the workstation

Open source dependencies are another critical entry point. Developers and coding agents routinely download packages from public registries such as npm and PyPI. Some are installed explicitly. Others arrive through transitive dependencies, automatic updates, or development tools that fetch packages behind the scenes.

Coding agents raise both the volume and the risk. They install packages on their own, often without anyone checking the name or version, and they sometimes request packages that don't exist: names attackers can register in advance and fill with malware.

A malicious package doesn't need to make it into a production application to cause damage. Installation scripts can execute immediately on a developer workstation, potentially accessing credentials, source code, and other sensitive resources.

That makes scanning application dependencies after a build insufficient. Security needs to intervene at installation time.

Package firewalls provide that control by evaluating packages and versions before they reach the workstation. Policies can block known malware, restrict high-risk packages, and enforce cooldown periods so newly published versions aren't automatically installed before they can be evaluated.

The same principle extends beyond traditional package managers. VS Code extensions, for example, can execute with the developer's permissions and may update automatically. MCP servers and development tools can introduce additional dependencies and executable code.

These components form a software supply chain for the development environment itself, even when they never appear in an application's dependency manifest.

Securing that supply chain prevents malicious software from gaining a foothold in the first place.

And when package protections operate alongside coding agent governance, security teams can do more than block an unsafe install. They can also prevent an agent from attempting to bypass the security controls that blocked it.

Secure the code factory, not just the code

The Binance investigation is a reminder of how much damage attackers may be able to cause by compromising trusted development environments. The full attack sequence is still being established, but the broader architectural challenge is already clear.

Coding agents are becoming the new perimeter. Securing them means governing the intent they act on, the supply chain they consume, the code they generate, and the commands they execute, wherever they run: on a developer's laptop or in the cloud. That's what we're building at Endor Labs.

Our Coding Agent Governance capabilities give security teams visibility into agents, MCP servers, skills, and the actions they take. Native hooks enforce policies before agents execute risky commands, access sensitive files, or invoke unauthorized tools.

Our Package Firewall protects developer workstations and coding agents from malicious dependencies and VS Code extensions, stopping threats before they're installed.

We've seen firsthand how important this has become. During our own Package Firewall deployment, most package installs happened inside coding agent sessions, including instances where agents tried to work around blocked installations.

That's the reality security teams need to prepare for: more people building software, more autonomous agents making decisions, and more privileged access distributed across the organization.

The goal is to let every developer and coding agent work quickly without putting the business at risk.

Securing software now means securing the code, the agents that write it, and the workstations where they run.