AI-generated code is already in production. Whether we are comfortable with that or not is beside the point. In the OpenStack project, which I have helped steward for more than 15 years, we are seeing developers submit patches built with AI assistance, and sometimes patches composed almost entirely by AI tools. Some of those contributions have already landed in the past release cycle. This is happening in one of the most rigorously governed open source projects in the world. It is happening everywhere else, too.
The code generation itself is not the problem. AI is genuinely good at producing computer programs because the structure of code is sufficiently predictable and syntactically constrained to play to the technology’s strengths. The problem is what happens next. Every AI-generated patch still needs to be reviewed for correctness, security, and long-term maintainability. And when code is easier to produce, more code gets proposed, which puts enormous pressure on the human reviewers who are the last line of defense before that code ships.
When AI Agents Break Traditional Trust Models
The volume of AI-generated code is only part of the “defense” challenge. The bigger disruption is AI agents: these software systems that act autonomously on your behalf are loosely directed by humans at the outset and then left to execute. Unfortunately, in our haste to adopt AI, we are quickly and casually granting these agents permissions we would never grant to a human assistant. Think about the trust models we’ve built over decades around the principle of least privilege. We’ve learned the hard way to establish robust fail-safe measures, such as requiring two keys to launch critical operations and multiple signatures for approval workflows. And now AI agents have come along, and we’re suddenly granting full access to our email, our databases, our production environments, and saying to these AI agents, “Sure, go ahead!” When something goes wrong, we discover the damage after the fact.
The point is that the shiny features of these AI tools are well ahead of their security features. The containment, the auditing, the ability to roll back what an agent did, and the ability to grant granular permissions rather than a wildcard to do anything: these capabilities remain underdeveloped. There is a wide-open field of innovation needed here.
So what do we do about it? We apply the same engineering discipline that has made complex software systems reliable for decades, and we evolve it for an AI-driven world. The open source ecosystem already offers the building blocks. I’d like to share two examples.
Project Gating: How CI/CD Keeps AI-Generated Code in Check
The first is Zuul, an open source system designed to properly gate code changes. Zuul was originally built for developing OpenStack in 2012 and is now used by organizations including BMW, Volvo, and Workday. Zuul was created to embed good software engineering practices directly into CI pipelines. It does not simply run tests after code is merged. It tests the future state of the codebase by running proposed changes together with their dependencies across multiple repositories before anything is allowed to land. If a change would break something downstream, Zuul catches it before it reaches the main branch.
Zuul’s approach was already valuable when humans wrote all the code, and it is essential now. As AI tools accelerate the volume of proposed changes, gating systems like Zuul ensure that the pace of contribution does not outrun the integrity of the system. The more code we produce with AI, the more we need automated enforcement of the practices that keep software manageable, secure, and functional. You cannot scale human review indefinitely, but you can build the most critical checks directly into your delivery pipeline.
This is already working in practice. Monty Taylor, one of the original architects of OpenStack’s CI infrastructure, has been building with a team of AI coding agents since late 2025 using the same toolchain and workflow he has used for fifteen years. All changes go through code review in Gerrit, where AI review agents leave their feedback just like any other contributor. Zuul gates every commit regardless of who or what wrote it. Production deploys happen automatically after gated integration tests pass. As Monty put it in a recent blog post: “Agents deleting databases isn’t an agent problem, it’s a system problem.” The problems AI agents bring are not new. What matters is whether you have the systems in place to catch them.
Hardware Isolation for AI Workloads: Why Containers Alone Are Not Enough
The second example is Kata Containers, an open source project launched in 2017 to provide “the speed of containers, the security of VMs.” Kata Containers provides hardware-level isolation for container workloads. Whereas standard container runtimes share the host kernel (which means a workload that escapes its limited boundaries can move laterally across the system), Kata Containers runs each workload inside a lightweight virtual machine, giving it its own dedicated, simplified kernel. What’s great about using Kata Containers is that the performance trade-off is minimal, but the security gains are significant.
This matters enormously for AI workloads. Today, organizations recognize that their proprietary data is one of their most valuable assets, and they are using AI to process it to inform business decisions. In multi-tenant environments, you do not want the data being processed by one AI agent to leak to another, and you do not want the infrastructure provider to access your precious data either. Kata provides protection of the host from the workload, and, through confidential computing, protection of the workload from the host. Both directions matter when the data being processed is, as people like to say, the new gold.
The industry momentum behind this approach is hard to ignore. NVIDIA runs its container-based AI inference workloads inside Kata Containers whenever they operate in multi-tenant environments. Google recently launched Agent Sandbox, a Kubernetes-native framework for isolating AI agent workloads, and it integrates directly with Kata for VM-backed isolation. The Kubernetes community has adopted Agent Sandbox as a CNCF project. When organizations at this scale converge on the same architectural pattern, it is worth paying attention.
What Enterprise Teams Should Do Now
There is one more dimension to operating AI securely that is worth underscoring. Both Zuul and Kata Containers are developed under open, neutral governance, in which no single company controls the roadmap. That matters for any infrastructure investment, but especially for the tools you trust to validate and contain your AI workloads. If you are making a significant investment in running your code production pipeline through a gating system or running your AI agents inside an isolation framework, you do not want that investment to depend on a single vendor that might change its licensing, its pricing, or its strategic direction. We have seen exactly that happen repeatedly in recent years, sometimes resulting in tenfold price increases for locked-in customers. Collaboratively governed open source removes that risk.
For organizations confronting these challenges today, a few starting points stand out:
- Enforce the principle of least privilege with your AI agents the same way you would with human users; do not give them blanket access to systems and data just because the configuration is easier that way.
- Adopt tooling like Zuul that builds software engineering discipline directly into your pipelines, so that quality checks do not depend on human bandwidth alone.
- Run AI workloads under stronger isolation—using agent sandboxing and Kata Containers, for example—particularly in multi-tenant environments like public clouds, or when processing sensitive or regulated data.
- Keep good backups and disaster recovery processes. AI agents will make mistakes at least as frequently as human operators, and the ability to restore systems to a known good state will be more important tomorrow than it is today.
AI is already reshaping how software is built and operated; that train has left the station. Our onus is to build the infrastructure to operate it securely. The open source tools exist. The engineering principles exist. What is required now is the discipline to apply them and to continue developing them collaboratively in the open.
