Windows NT vs Linux Security: Why AI Agents Reopened the Kernel Debate

Laurie Kirk is a Google researcher who runs the LaurieWired YouTube channel. Windows Latest reports that she previously spent four years as a reverse engineer at Microsoft. In a public LinkedIn post she called the NT kernel "an engineering marvel" that "still puts Linux to shame in many ways." She went on to argue that AI agents make the difference matter more in 2026 than it ever did. She also imagined a history in which Microsoft shipped an "Open NT" that companies could fork.

Kirk is talking about architecture, not the Windows 11 desktop. This is not about the Start menu, ads in the shell, or Copilot buttons. Her claim is narrower: how an operating system represents resources and decides who may touch them.

What Kirk actually argued​

Her LinkedIn post makes four main claims:

• NT is object-based and was security-first from the start. She describes NT as being more like an object-oriented language, with a strong security model from day one, "whereas Linux is very…not."
• Linux security feels bolted on. She names SELinux, capabilities and namespaces as good features that feel added later "because…well they were."
• AI agents expose the problem. She says that if you try to answer "What exactly is this AI agent allowed to do?" on standard Linux, you have to look across UIDs, GIDs, ACLs, cgroups, policies, SELinux and filesystem modes, with no "singular coherent graph of capabilities."
• A kernel designed from scratch in 2026 would not look like Linux. In her view it would look closer to NT, "or even a BSD fork."

She also says plainly that this is a "controversial take." It is an opinion from a practitioner, backed by expertise. It is not a benchmark or a formal security evaluation, and it should be read that way.

Section summary: Kirk is praising NT's founding design ideas and questioning whether Linux's layered security suits autonomous software. She is not saying Windows 11 is a better product overall.

What "object-based" means in NT​

Microsoft's own documentation fills in the detail here. Microsoft avoids the term "object-oriented" in the C++ sense and describes Windows as object-based. That is the more accurate way to read Kirk's analogy.

Microsoft's developer documentation gives two main reasons Windows uses objects and handles to control access to system resources:

1. Stability of interfaces. If the object interface stays the same, Microsoft can change what happens underneath without forcing apps to be rewritten.
2. Security. Each object has an access control list (ACL). The system checks that ACL whenever an application creates a handle to the object.

The security descriptor is the core structure. According to Microsoft Learn, a descriptor can hold:

• The owner and primary-group SIDs (security identifiers)
• A DACL, which lists the rights allowed or denied to specific users and groups
• A SACL, which sets which access attempts produce audit records
• Control bits that change how the descriptor is interpreted

In practice, you sign in and get an access token that carries your identity and groups. When you ask for an object, Windows checks your token against the object's ACL. If you're allowed in, you get a handle with the granted rights attached. The SACL is the part Kirk points to when she talks about "centralized audit trails": auditing is built into the same structure that grants access.

There's an important caveat. A shared model does not mean one identical permission scheme for everything. Microsoft's documentation says each securable object type defines its own specific access rights. A file, a registry key and a process all use the same framework, but their rights are different.

Section summary: NT uses one consistent pattern for everything: identity token, object, ACL, handle, audit. That consistency is what Kirk finds elegant. It does not, on its own, make Windows secure.

Linux's answer: many composable tools​

Kirk's list of Linux mechanisms is accurate, but each one does a different job:

Landlock is the strongest counterexample to any claim that Linux can't contain untrusted code. The Linux kernel documentation says it arrived in Linux 5.13 and lets any process, including unprivileged ones, restrict its own access to the filesystem and, from ABI version 4, TCP ports. Rules apply to the thread and all its future children. Once a thread is landlocked, its policy can't be removed; it can only be made stricter. For a program that wants to lock itself down before running code an AI model just generated, that is close to what you'd want.

The same documentation partly backs Kirk's point, though. It says namespaces help build sandboxes but "are not designed for access-control." It also lists file-related actions Landlock can't restrict yet, including chmod, chown and ioctl. Applications also have to check which Landlock ABI version the running kernel supports and adjust their rules to match, so the protection you get depends on the kernel.

Critics in Kirk's comments pushed back hard. One commenter, Ken C., argued that the add-on design is "not a side effect but rather the whole point" of Unix philosophy. Windows Latest also reports that some commenters see optional SELinux as a benefit for high-performance computing workloads that can't afford its overhead.

Section summary: Linux can contain an agent. The real disagreement is whether combining eight tools is harder to reason about and audit than a single object model.

Why AI agents raise the stakes​

The agent angle is what makes this more than a nostalgic flame war. A human administrator clicks one thing at a time. An agent can run thousands of actions in minutes, execute code it just wrote, and chain permissions together. Asking "what can this software do, to which resources, on whose behalf?" is no longer an academic question.

Microsoft is working on exactly this. At Build 2026 it announced Microsoft Execution Containers (MXC), which the Windows Developer Blog describes as a cross-platform, policy-driven execution layer for agents across Windows and WSL. Developers declare what an agent can access, like files and networking related policies configured in Intune, and MXC enforces those boundaries at runtime.

The session-isolation part lines up closely with Kirk's argument. Microsoft says it separates the agent's execution from the user's desktop, clipboard, UI and input devices, and critically, binds the agent to a strong user identity. Microsoft also says fast process isolation has been adopted by GitHub Copilot CLI. So agents on Windows get their own identities, tokens and ACL checks. That is the NT model applied to a new kind of principal.

Some caveats:

• Microsoft itself calls it an early preview of the Microsoft Execution Containers (MXC) SDK.
• Developers Digest reports that the documentation says no MXC profiles should be treated as security boundaries currently, as policies may be overly permissive during this phase.
• Reports on the rollout differ. Cloud Native Now says MXC will ship first in Windows 11 version 24H2 (Enterprise and Pro editions), with Windows Server 2027 following later in 2026. Admins should check the current status against Microsoft's own channels before planning around it.

Separately, Microsoft's Windows security documentation describes an experimental agent workspace in Windows 11. There, agents run under dedicated standard accounts that start with limited permissions. The feature is off by default during the preview. Insiders who want to try it can find the toggle at Settings > System > AI components > Agent tools > Experimental agentic features. During the preview, agent access is limited to known folders such as Documents, Downloads, Desktop and Pictures, plus resources available to all local accounts.

None of this shows that Microsoft agrees with Kirk about Linux. MXC also runs across WSL, and Developers Digest describes Linux and macOS backends too. What it does show is that Redmond is asking her question and answering it with SIDs, sessions and policy.

Section summary: Windows is extending its identity-and-ACL model to cover AI agents. The tools are real, but they're in preview. How well they work compared with Linux sandboxing hasn't been proven.

The "Open NT" counterfactual and the cost of forks​

Kirk's alternate history imagines Microsoft releasing, in the early 2000s, a partly open NT. It would not be GPL-style open, but open enough that a large company could "swap out a memory allocator for their own." Her example is an early Amazon building an "AmazonNT" for EC2 with its own scheduler or network stack, while Microsoft kept "a stable baseline" for security and compatibility. She admits Microsoft "sorta did this with limited source access," but says that access was too restrictive.

Windows Latest reports the sharpest reply came from David Airlie, a longtime Linux kernel graphics maintainer. He argued that forks are "too expensive over time to maintain," and that companies that fork Linux usually end up working upstream because of cost. Think about what that means in practice. Every monthly Microsoft security fix would have to be merged and retested against Amazon's custom scheduler. Before long, the fork would need its own full kernel team. Linux avoids that because shared changes flow back into one common codebase, and that development model is a big reason Linux won the server and cloud market.

Section summary: Open NT is an interesting thought experiment. But ongoing maintenance costs are a strong objection to any heavily modified kernel fork, whatever the license.

NT's baggage is fair game too​

Kirk's critics were right to point out NT's own history of compromises. In the same comment thread, Ken C. questioned how to get deterministic performance from non-realtime NT without buying excess hardware. He also said his words for the registry "are not fit for a professional venue." Another commenter noted that Microsoft moved graphics code into kernel space for speed, which meant a bad graphics driver could crash the whole system. Windows security has always depended as much on drivers, default settings and decades of compatibility work as on the kernel's design. That's why Patch Tuesday exists.

The verdict​

Neither side wins outright. As a matter of architecture, NT has a coherent model: typed objects, access checks through handles, token-based identity and built-in auditing. Kirk's argument that this suits agents is reasonable. Linux has a flexible and very successful ecosystem of composable controls, including self-sandboxing through Landlock, which Windows still doesn't have in quite the same form.

For Windows admins, the practical point is that the permission model introduced with NT 3.1 in 1993 is now being reused to contain AI agents. Before you let any agent loose on your machines, check what identity it runs under, what it can reach, and whether its actions are logged. That's true on Windows and Linux alike.