This week brought another story of a new operating system written almost entirely by AI agents. The source describes a project that landed in the newsroom's email inbox: yet another OS "coded from scratch" with today's LLM and AI capabilities. Most of these experiments are open-source, but this particular project presents itself as closed, with one justification: security.

The pace at which these announcements appear is now a structural fact. The question is not whether one of these systems will become the next Linux; the point is that generative models have lowered the cost of producing plausible system code to the point where creating an OS has become a nearly weekly artifact. But an operating system is not a demo: it manages memory, permissions, drivers, process isolation. Security is not a property added at the end; it is the way these components are designed and verified.

Closure is not proof of security

The choice to keep the code closed in the name of security deserves careful attention. In traditional software, closed code can protect implementation details and reduce the known attack surface, but it does not automatically make a system more secure. On the contrary, it hides the possibility of verifying what the code actually does. In a context where code is generated massively by AI agents, the problem shifts: no human has written every critical path line by line. Audit becomes more important, not less. Closing the source in the name of security can be a legitimate position if accompanied by independent review, but used alone it risks turning into an argument to avoid scrutiny.

The knot for those evaluating local stacks and sovereignty

For organizations evaluating on-premise or self-hosted deployments, the news signals a change in the terms of trust. When an operating system comes from an automated generation pipeline, verification cannot stop at the binary: it requires tracing the model's provenance, the data used for fine-tuning, and the environment in which the agents operated. A closed AI-generated OS shifts the burden of proof: those who adopt it must trust the vendor's word without being able to inspect the choices made by the agents. This has second-order implications for data sovereignty and TCO: the lack of code access may reduce immediate costs, but it increases the risk of dependency and undiagnosable incidents.

It is no coincidence that most of these projects are born open-source. The community experimenting with AI-generated OSes appears to prefer transparency, both to learn and to correct. The closed exception in the name of security therefore becomes a test: if closure is accepted by the market, the idea that a critical AI-generated component can be distributed without the possibility of audit becomes normalized. If instead the demand for transparency prevails, security will have to be demonstrated with different tools: attestations, reproducible builds, evaluation reports. In either case, the phenomenon shifts the center of gravity from code review to model governance.