Why coding agents make local developer credentials harder to ignore

Coding agents have made an old developer security problem acute. Every enterprise that ships software still depends on machines where privileged credentials, untrusted executables, and external access all converge, and where code runs on trust.

Developer workstations have always been credential-rich environments. But the explosion of open-source ecosystems with uneven security review (package managers, IDE extensions, and now the sprawl of tools behind agentic workflows like MCP servers and skill files) has made it far easier for attackers to get untrusted code running on machines where credentials sit waiting.

Coding agents make this worse. They increasingly act on their own, without supervision. It was already hard for developers to spot dangerous code arriving from a trusted source and to apply sound secrets management practices. Now agents can sail past those guardrails, and a single prompt injection can turn one into an exfiltration tool.

The result is that a company’s entire security posture rests on each engineer’s willingness to maintain a “secure posture” that is effectively impossible to hold, while the pressure to ship fast, often on tools that are barely a week old, has never been higher.

Here is the thing. Supply chain security has often been framed around what gets into the codebase and reaches production. But attackers are far more likely to succeed earlier in the chain, where their payload meets an execution surface that is much less audited than production.

For the past five years, CI runners checked every box an attacker could want: execution rights, access to sensitive data, heavy automation, and few safeguards to stop a payload from spreading. Today, developer machines are the new favorite, especially because coding agents add a fresh, blindly trusted execution layer that is almost too easy to fool. 

A developer machine is not just where software is written. It is a node connecting source code, external dependencies, cloud infrastructure, package registries, and deployment systems. Yet they are also a supply chain blindspot.

The endpoint exception became a supply chain blind spot

Security teams have long carved out exceptions for developer workstations because they don’t behave like normal corporate endpoints. Engineers compile code, run unsigned binaries, spin up containers, and install packages as routine work. Traditional endpoint detection and response (EDR) either broke builds or flooded the SOC with noise, so many organizations settled for lighter enforcement, broad exclusions, or detect-only mode.

That left a practical problem. Strict enforcement isn’t the answer: it blocks legitimate work and generates enormous noise for little gain. Cloud development environments and enterprise browsers arrived a few years ago promising to solve this once and for all, but they never gained real traction. Most developers depend on personalized local toolchains, config files, extensions, and offline workflows that are impractical to reproduce remotely. Despite decades of moving workloads to the cloud, developer work still happens in local terminals, IDEs, filesystems, and package managers — and hardcoded credentials are still the norm.

As a result, developer laptops have become some of the most privileged and least monitored machines in the enterprise. They hold repository tokens, package-publishing credentials, cloud CLI configuration, SSH keys, identity provider tokens, etc. This creates an ownership gap that attackers are happy to walk through. 

AppSec watches the code. Identity watches the credentials. Endpoint security watches a noisy workstation. Engineering watches velocity. Nobody owns the intersection, which is exactly where the attack happens.

Credential harvesting was always the practical objective

Modern supply chain attacks tend to follow a simple pattern: get a malicious package, extension, plugin, or script to execute on a developer machine, then quietly extract whatever credentials are there. The goal is rarely to tamper with code in the repository. It is to grab a token that grants repository access, cloud access, or publishing rights.

Coding agents accelerate this. They are opaque, they execute fast, and they expand the sensitive context that accumulates locally (they are frequently wired into external systems). They invoke package managers, shells, and cloud CLIs under the developer’s existing privileges, quietly bypassing the access controls that identity and access management spent years putting in place. So the agents aren’t the root cause. The root cause is persistent local credential exposure. Coding agents simply make that exposure larger and more reachable.

Local environments still contain too many high-value secrets

Recent GitGuardian analysis found an average of 150 secrets per sampled developer machine. Private keys accounted for 38% of unique secrets, while cloud, identity provider, and secrets management credentials (including AWS IAM and HashiCorp Vault) made up another 22%. These are direct access paths that turn a compromised local tool into repository access, infrastructure control, or lateral movement.

Repository scanning, software composition analysis, CI hardening, and push protection all remain necessary. But none of them prevent credential theft while long-lived secrets sit in plaintext on developer endpoints.

The strongest defense is zero locally exposed credentials

The best way to reduce this risk is to make the developer endpoint a poor target for credential theft. That means finally retiring static secrets in .env files, long-lived tokens, and SSH keys, and replacing them with secure authentication — much as passkeys are starting to retire the stored password in consumer tech (yes, passwords still exist).

This won’t happen overnight, and no organization can strip every local secret from every workflow at once. But the direction of travel has to change. Local secret sprawl should no longer be accepted as an unavoidable cost of building software.

In practice, that means replacing static local credentials with short-lived access wherever possible. It means retrieving secrets at runtime instead of storing them in plaintext. It means hardware-backed authentication, least-privilege developer access, regular detection of local secret sprawl, and fast rotation when exposure is found. And it means judging developer tools by what they can reach locally, not just by whether they look safe as software.

The goal isn’t to make developer machines impossible to use. It’s to stop treating them as acceptable places for long-lived credentials to pile up.

Coding agents make this urgent. They enable autonomous workflows at a speed that was barely believable a year ago, which means this attack surface is more exposed than ever. It also makes one simple question much harder to ignore: if compromised code runs here, what credentials would it find?