Kodem runs on Windows now

Security for AI is being built for the demo stack. A container, a Linux node, a Python agent built on a popular framework, a model behind an API. That is the environment most new AI security products were designed around, and it is a small fraction of what runs in an enterprise.

The rest looks different. .NET services on Windows Server. Line-of-business applications that predate Kubernetes and still settle trades, schedule shifts, or run a plant floor. These systems were never rewritten, and they are not going to be. What is changing is that agents are now being wired into them.

Today Kodem's In-Host Sensor runs on Windows. The same runtime evidence we collect from Linux and Kubernetes now comes from Windows Server hosts, and it feeds the same analysis, the same issues, and the same workflows.

Windows is where a lot of the application layer actually lives

Ask a security team at a bank, an insurer, or a manufacturer what fraction of their application estate runs on Windows and the answer is rarely small. These are not edge cases. They are the systems the business would notice first if they stopped.

A tool that covers Linux only leaves that half of the estate as a questionnaire. The team can list what they think is deployed, but they cannot say which packages are loaded, which functions ran, or whether an agent is running inside a process that nobody labeled as agentic. The inventory is a declaration, not an observation.

That gap was tolerable when the Windows side was stable and the interesting risk was in the new container stack. It stops being tolerable the moment someone adds a model call and a tool registry to a .NET service, because now the Windows side carries the newest risk with the oldest visibility.

The evidence has to come from the running process, whatever the OS

Kodem's position has not changed. Manifests describe intent. Network traffic describes what crossed a boundary. Neither tells you what is actually loaded and able to run inside a process. Runtime intelligence reads that directly: which packages are loaded, which functions executed, and what the application is wired to do.

On Linux, the In-Host Sensor does this with eBPF and memory analysis. The Windows sensor is built for the Windows kernel and process model rather than ported from Linux, and it delivers the same categories of signal: OS-level events, in-application flows, and environment metadata. Analysis runs inside the sensor. Nothing is injected into the application process and no third-party code runs inside it, on either operating system.

That last point is the one Windows platform teams ask about first. A sensor that requires instrumenting the .NET runtime, or restarting a service that has been up for 400 days, is a sensor that does not get deployed.

What changes for a .NET application on Windows

The outcome is the same one Kodem customers already have on Linux: a shorter, truer list of things to fix, with the evidence attached.

Dependencies. Runtime-powered SCA covers C# and VB.Net through NuGet. A vulnerable package in the lockfile becomes a confirmed yes or a confirmed no for each running service, based on whether that package was loaded. For most .NET estates, that single distinction removes the majority of the backlog without anyone arguing about severity.

Code. SAST includes C# rules and a dedicated .NET CWE set, so injection, deserialization, path traversal, and the other classes that matter in .NET are covered as first-party code findings and correlated to what runs. Details on language coverage are on the supported technologies page.

Agents. Kodem's AI Discovery reconstructs the agents running inside an application from runtime evidence: each agent, the model it binds, the tools it can call, where each tool came from, and the repo and image it ships from. A .NET service with a model call and a tool registry is an agentic application, whether or not anyone called it one, and it belongs in the same inventory as the Python agent in the container next to it.

None of this requires a second product, a second console, or a second set of issues. Windows hosts show up in the same inventory as Kubernetes nodes, and findings from both land in the same triage queue.

One application layer, Linux or not

The market is being asked to buy two security stacks: the AppSec tools it already owns and a new set of AI security products for agents. Kodem's view is that the split is false. Agents run inside applications, in the same processes and the same memory, so securing them is the same problem with a higher bar for evidence.

Windows support closes the other half of that argument. It is not enough for the evidence to cover both halves of the application, classic and agentic. It has to cover both halves of the estate. Windows support means the same mechanism now reaches the workloads most enterprises run their business on, and the ones they were quietly told to leave out of scope.

Secure what you build. Secure what you deploy. Linux or not. Agentic or not.

If you run .NET on Windows Server and want to see what is actually loaded inside it, start with open source security or talk to a security engineer about a pilot on one Windows host.