We’ve spent decades hardening production environments while leaving developer workstations as the least governed, least isolated, and most trusted machines in the enterprise. AI agents change this risk equation dramatically and with real world consequences.

real insights from real bugs

Last week, we watched two seemingly very different AI stories unfold. One story involved an AI model reportedly deleting files it wasn’t asked to touch; The other story involved an AI coding assistant uploading significantly more of a source repository than users realized, including un-redacted secrets.

Although these stories have different symptoms, they amount to the same risk. Agents are able to do more and more in non-sandboxed environments and the consequences can be severe.

For years, we’ve assumed our laptops were trusted environments. We install open source packages and SDKs directly on our machines. We run elevated command prompts to direct actions that our OS tries to protect against. We store credentials in files marked with .gitignore or arguably better in environment variables.

Our IDEs have access to everything because we were the trusted user. We didn’t send or expose those secrets. We kept close eye on what we were committing and where. We were the overseers of the security on our own machines.

All of those assumptions start to break down when our tooling is no longer passive. Now that we have autonomous agents capable of taking action, our security gaps are as wide as the Grand Canyon.

What was once a nice experimentation and convenience is become more of a critical cog in a zero trust policy organizations can leverage.

The Invisible Attack Surface

Most organizations have a reasonably good understanding of what's running in production. They inventory servers, monitor services, scan for vulnerabilities, and enforce network policies.

The developer workstation is often a different story altogether.

Over time, every project leaves behind something. Our own little accumulating fingerprints that are hard to dust for because they’ve become muddy over time. New SDKs, new dependencies on different package managers, background services, docker containers, open ports, browsers, extensions, you name it. Collectively, these additions create an increasingly opaque environment that becomes unruly to manage.

For DevSecOps teams, this presents a nearly impossible challenge. It’s difficult to secure what you can’t consistently manage or inventory. Questions like these become surprisingly difficult to answer, especially at scale:

What services are running on developer machines?
Which ports are exposed?
What credentials are needed and available?
Which applications are accessing which network resources?

Every workstation is its own little microcosm and snowflake. Very tough for central governance to see into and manage.

Developer containers flip this model on its head. Instead of trying to constantly run discovery on these evolving machines, the development environment itself becomes declarative, version-controlled and centrally managed.

We talk a lot about observability in code and systems. This is no different and becomes a central tenant for organizations looking to mitigate risk and mature their security practices.

Isolation is the New Developer enablement

Instead of giving agents access to our entire workstation, we have the capability of giving them access to a disposable and self-contained environment.

Need Node? It’s in the container. Need Python? Need Java? All in the container.

If something goes wrong, you throw the environment away.

Instead of asking the DevSecOps team for ever increasing lists of applications and ports to be allowed, we give them a configuration with exacting requirements for every use case.

Least Privilege Becomes practical

One of Zero Trust’s biggest challenges has always been usability. Developers need access to everything and permission on their machines to everything. They need admin or root level privs most of the time to get their jobs done.

Dev containers let us start asking much better questions:

Does this project really need access to my SSH keys?
Does it need Docker?
Does it need my AWS credentials?

Instead of answering “yes” because it’s my laptop, now I can create a dev container based on the use case I’m going to be running for the particular project I’m working on and throw it away when done. I can sandbox this one use-case away from the myriad of other use-cases that require different elevated permissions for different resources, for example.

Reproducibility is king

“It works on my machine.”

Dev containers finally make that sentence a thing of the past. Every engineer, every build agent, every repository, and every AI agent starts from the same image. Imagine being able to hand every new hire the same exact configured environment with little-to-no effort. How much faster would onboarding be if we could magically remove the configuration friction?

The environment becomes source-controlled infrastructure. That not only opens the doors to reproducibility but now our friends in DevSecOps can perform vulnerability scans to ensure hardened environments that are safe for use.

AI sessions become disposable

Forking and looping and work trees, oh my! But now imagine that every AI coding session can run inside an ephemeral container. True AI segmentation by models. You can start with a clean environment, spin up an agent and go to work.

This will result in no accumulated state, no forgotten credentials, no lingering processes or RAG running in the background.

If you want to perform adversarial validations, spin up a different container, grab the commit and start with a fresh, unaltered environment.

infrastructure as development

Infrastructure as code has existed for years. It’s allowed organizations to control deployed environments and promote consistency. As developers, we now have the ability and capability to do the same thing with our non-deployed environments.

One of my favorite aspects of Dev Containers is that the development environment itself becomes code and is controlled in source code. This makes changes transparent across the organization, allows all developers to raise PRs against the environment repositories and collaborate on what makes a delightful experience.

Conclusion

The recent AI incidents aren’t evidence that AI is unsafe. Instead, these are evidence that our assumptions about development environments are outdated.

We don’t allow production workloads to run directly on laptops. We isolated deployed environments for safety. We don’t give applications unrestricted network access. So why do we still develop software that same way?

Dev Containers are an architectural shift toward treating developer environments with the same care and discipline we’ve spent decades applying everywhere else.

As AI adoption increases, more exploits will be found that expose the gaps we have by not adopting these practices. The goal post has moved from making development more convenient through the use of Dev Containers to a critical security posture. What used to be a nice to have is going to become one of the most important security decisions engineering organizations make.

key takeaways

The trusted developer workstation is no longer a sound security assumption. As AI agents become active participants in the development process, our workstations should be treated as untrusted execution environments rather than privileged machines.
Development containers bring Zero Trust principles closer to the developer. By isolating tools, dependencies, credentials, and network access, they reduce the blast radius when something goes wrong.
Reproducible environments are a security feature, not just a productivity feature. Version-controlled development environments eliminate configuration drift, simplify onboarding, and provide consistent behavior across developers, CI/CD pipelines, and AI-assisted workflows.
Least privilege should apply to development just as it does to production. Every project should have only the permissions, credentials, and network access it actually requires. Treat development environments the same as deployed environments.

The future of secure software development starts before code is ever deployed.

Organizations that modernize the developer workstation today will be better positioned to embrace increasingly autonomous AI tools tomorrow. Developer containers aren’t the destination, they are the journey toward applying Zero Trust principles to the entire software development lifecycle.

The Trusted Developer Workstation Is a Relic: Why Dev Containers Belong in a Zero Trust World. By Jen Parker