I spent last week at AI Engineer World’s Fair in San Francisco watching something click into place. The industry finally stopped asking ‘can agents do this?’ and started asking ‘how do we let agents do this safely?’ That shift matters more than you might think.
The conference itself was proof. Two years ago, ‘evals’ and ‘context engineering’ weren’t conference tracks. Neither was ‘sandbox and platform engineering.’ Now each one has dedicated sessions, its own vocabulary, and a booth hall full of companies built to solve each single problem. We’re watching an entirely new software development lifecycle take shape in real time.
The Laptop is Now Your Production Environment
Here’s what I realized: most developers are already running AI agents today, but they’re doing it on their personal machines with the same minimal security posture they’d use for a local Node.js dev server. That was fine when the agent was just a chatbot. It’s different now.
Rowan Christmas from Docker ran a live demo that made this concrete. He spun up a coding agent on his laptop with nothing special: no sandbox, no unusual permissions, just read access to his filesystem. Within minutes, it had pieced together surprising detail about his online banking activity just by observing what was passively visible. The agent wasn’t malicious. It didn’t need to be. Read access plus untrusted content plus the ability to act across your system is already dangerous by design.
This is what Simon Willison calls the ‘lethal trifecta’: any useful agent accumulates all three by default. No prompt or policy document fixes this. The fix has to live one layer down, at the runtime.
Three Layers of Trust, Not One
I keep thinking about the framework Docker presented: an agent is only as trustworthy as the boundaries around it, and those boundaries live in three distinct places.
First, what it builds on. A hardened container image with minimal dependencies and known-good supply chains. This is old security thinking applied to new problems, but it matters more now because agents can actually read and modify your codebase.
Second, where it runs. A sandbox with defined filesystem, network, and tool boundaries. This is where microVMs come in. Docker’s approach starts on the laptop because that’s where most people actually run agents today, not in some cloud-first fleet architecture. Each session gets its own isolated boundary.
Third, what it can reach. MCP servers, credentials, external APIs. This is the ‘shadow MCP’ problem: developers install tool servers faster than security can review them, turning each unapproved server into a direct line to your data.
Miss any one of these three and the other two won’t cover for you. A hardened image is useless if the agent can still read your whole filesystem unsandboxed. A locked-down sandbox doesn’t matter if the agent can call an unvetted MCP server.
Governance Becomes a Developer Tool
What struck me most was how Docker positioned this: not as a security mandate that slows down development, but as infrastructure that enables it. Docker AI Governance is about centralized control over how agents execute, what they can reach on the network, which credentials they can use, and which MCP tools they can call.
This matters because the alternative is either no governance (which means most organizations won’t let agents run unsupervised, capability be damned) or heavy-handed policy that destroys developer velocity. You need something in the middle. Something that lets your whole company run AI agents safely, whether they’re on a laptop or in CI or running in the cloud.
I’ve been watching AI tooling evolve for a couple years now, and this is the layer that usually gets missed. We obsess over model capability and developer experience at the application layer, but the runtime is where trust actually gets built.
What This Means for How We Build
The bigger implication is that agents are reshaping what ‘infrastructure’ means. For the last decade, infrastructure meant servers and containers and orchestration. Now it means runtime isolation, credential management, network policy, and tool governance.
Teams moving fast on agents aren’t moving fast because they’re ignoring security. They’re moving fast because they’ve solved the security question first, at the layer where it actually matters. That’s the next step for the rest of us.
The question isn’t whether agents will read and write your codebases, install dependencies, and call APIs unsupervised. They will. The question is whether you’ll have built the boundaries to let them do it safely.