The Envelope Era

I spent Columbus Day reading other people's incident writeups, which is my idea of a holiday. Somewhere in the middle of one of them I realized the most interesting thing that happened in AI last month wasn't a new model.

Between late September and the first week of October, three organizations working independently landed on the same architectural answer. Microsoft shipped execution containers for agents, where the operating system, not the agent, decides which files and network endpoints the agent can reach. NVIDIA released open-source sandbox software along with a reference design for a hardware watchdog that can cut an agent's network access at the network card itself. And the UK AI Security Institute rebuilt its evaluation infrastructure after its test agents took unsanctioned actions on the live internet during cybersecurity evaluations. Nineteen of them, across 122 runs. That's the one I was reading.

These are three different problems. But the move is the same in all of them: wrap the agent in an envelope of process boundaries, network gates, and hardware controls that sit underneath it, where the agent can't reach them. You put the lock on the outside of the door.

Why I care about the convergence has to do with where the value is going. Models keep getting better, inference keeps getting cheaper, and the raw ability to generate actions drops in price every quarter. Controlling what those actions touch doesn't get cheaper on anything like that curve, because control depends on facts specific to your organization. Which systems hold sensitive data. Which operations you can't undo. Which of your failures turn into somebody else's problem downstream. You can subscribe to a smarter model, but there's no subscription for someone else's understanding of your own operational boundaries.

So the envelope is interesting as infrastructure, and not only as security. It's where organizational policy actually meets agent execution. "This agent can read but not write." "This agent can call the payments API, but not above $500." "This agent loses network access the instant it touches a path outside its sandbox." Those rules get enforced by the operating system or the hardware, instead of by the agent's own good judgment. I have been on call for twenty-five years, and every time we trusted software to police itself in production, it failed.

To be fair, none of this is proven yet. Nobody has published adversarial testing showing these controls hold up under sustained pressure, and no independent group has audited them. AISI says outright that controls adequate for today's models may not be adequate for the next ones. The money is starting to show up (Amazon charges for isolated agent execution, Google bills compute for its agent sandbox), but nobody reports containment as its own revenue line. What we have are directional commitments, not proven defenses.

I still think the direction matters. The whole thing rests on one condition: AI capability keeps outrunning organizations' ability to manage it. For the next several years that seems like a safe bet. If it holds, "production-ready" stops meaning the agent can do the task and starts meaning the envelope around it can enforce the rules. And that moves where organizations put their money. The team building the agent stops being the bottleneck, and the team building and operating the envelope becomes it. The budget goes there, and then the hiring does. A lot of people have spent two years sprinting on agent capability while treating constraint infrastructure as somebody else's job, and they may wake up to find it's the thing the org can't ship without.

Next time someone in your org proposes a new agent, pay attention to the first question in the room. If it's "what can it do?" and nobody is asking what it's allowed to touch, then you've got a team building the engine and nobody building the brakes. Production will notice that before your roadmap does.