What Is Kernel-Level Enforcement Security?

Updated October 24, 2026.

Kernel-level enforcement security checks each attempted change to a protected server at the kernel, before it executes, against a verified record of that server’s authorized state. A change inside the record proceeds. A change outside it doesn’t run. It asks whether the change was authorized, not whether it looks malicious, so it needs no signature or threat intelligence. Mimic Networks builds its platform on it.

This page covers the question kernel-level enforcement asks and how Mimic asks it at the kernel. It sets kernel-level enforcement beside EDR, application allowlisting and AI guardrails, then says what it doesn’t do.

What question does kernel-level enforcement ask?

Most security controls ask some version of one question: does this look like an attack? Signatures, behavioral analytics and anomaly models all try to recognize malicious activity, then alert, block or respond. That works when the attack resembles something seen before. It’s harder when the attacker uses valid credentials or signed tools already on the system. MITRE ATT&CK documents both: adversaries use valid accounts to get in and stay in (T1078), and proxy execution through signed binaries, often files already native to the operating system (T1218).

Kernel-level enforcement asks a different question: was this change authorized? It doesn’t try to recognize the attack. It checks whether a change to a protected server is part of that server’s known-good baseline, the record of what the server does in normal, approved operation. A change that isn’t in the baseline doesn’t run, whether it came from ransomware, a misused admin account or an AI agent acting outside its scope.

Kernel-level enforcement security checks each attempted change to a protected server at the kernel against that server’s authorized state, and stops a change outside it at the point of execution.

It isn’t kernel self-protection. The Linux kernel documentation defines that as “the design and implementation of systems and structures within the Linux kernel to protect against security flaws in the kernel itself” (kernel.org). One hardens the kernel. The other uses it to decide.

The idea has a long history in allowlisting. NIST defines an application allowlist as “a list of applications and application components that are authorized for use in an organization” (NIST SP 800-167). Kernel-level enforcement applies the same test to changes, not just to which applications may launch.

Mimic Networks calls the model known-good enforcement. Kernel-level enforcement is where it’s carried out.

An attempted change on a protected server

Detection asks

Does this look malicious?

Compares activity with signatures, behavior patterns and models.

Recognized: alerts, blocks or responds.

Not recognized: no action from this control.

Kernel-level enforcement asks

Was this change authorized?

Compares the change with the server’s baseline, its record of normal, approved operation.

In the baseline: the change proceeds.

Outside it: stopped at the point of execution.

EDR sensors run kernel components too. The difference is the question, not the layer.

Figure 1. Two questions about the same change. The text below covers both.

Don’t EDR tools run in the kernel too?

Yes. Many endpoint security products load drivers in the Windows kernel. Microsoft explains that kernel drivers give security products “system wide visibility,” and that “a second benefit of loading into kernel mode is tamper resistance” (Microsoft). CrowdStrike describes the Falcon sensor’s csagent.sys as its “file system filter driver, a type of kernel driver” (CrowdStrike). On Windows, Mimic’s enforcement runs as the same kind of driver.

So the layer isn’t what separates the two. An EDR sensor in the kernel watches for activity it can recognize as malicious. Kernel-level enforcement checks each change against what the server is authorized to do. They answer different questions, which is why they run side by side.

How does kernel-level enforcement work?

Mimic carries it out in five steps, set out on the known-good enforcement page: profile the authorized state, check each change before it executes, stop what falls outside the baseline, record each attempt and keep the baseline current. Three parts matter most at the kernel.

The baseline

During onboarding, Mimic profiles each protected server in its approved state and records the files, processes, services, registry keys and settings it uses in normal operation. That record is the baseline, and it becomes the enforcement policy. It describes the server, not the threat, so it doesn’t need an update when a new variant appears.

The check

Each attempted change to a protected file, process, service, registry key or setting is checked against the baseline. Mimic decides inline, before the change executes. When a change falls outside the baseline, Mimic stops exploitation at the point of execution. Each blocked attempt is recorded with the process behind it and what it tried to change, and teams review the record in DashCam, Mimic’s console.

The substrate

On Windows, enforcement runs as a file system mini-filter driver. Microsoft describes minifilters as optional drivers that “attach to the file system software stack” and notes that, depending on the driver, “filter can mean log, observe, modify, or even prevent” (Microsoft Learn). On Linux, enforcement runs through eBPF, which “can run sandboxed programs in a privileged context such as the operating system kernel” (eBPF.io). The enforcement logic runs in a WebAssembly sandbox implemented in Rust, from a single module on both. Each WebAssembly module “executes within a sandboxed environment separated from the host runtime using fault isolation techniques” (WebAssembly). The driver that hosts the sandbox is still kernel code.

On Windows, Mimic’s enforcement driver passes Microsoft’s Hardware Lab Kit tests and carries Microsoft’s dashboard signature, which Windows Server 2016 and later require (Microsoft Learn). No reboots required, for deployment, policy changes or upgrades. Enforcement overhead is tunable.

How Mimic checks a change

A process attempts a changeTo a protected file, process, service, registry key or setting.
Mimic sees it in the kernelThrough its enforcement driver on Windows and eBPF on Linux.
The logic checks the baselineIn a WebAssembly sandbox implemented in Rust. Mimic decides inline, before the change executes.
Proceed or stopIn the baseline, it proceeds. Outside it, Mimic stops it at the point of execution.
DashCam records itEach blocked attempt, with the process behind it and what it tried to change.

Figure 2. The check on a protected server. The same steps are written out in the section above.

Why enforce at the kernel?

Because that’s where the change happens. On Windows, file operations pass through the file system stack, where a minifilter can see each one before it completes and, in Microsoft’s words, “even prevent” it (Microsoft Learn). On Linux, eBPF programs run inside the kernel itself (eBPF.io). A control at that point can decide on a change before it executes, rather than report it afterward.

Timing matters because attackers often don’t wait for a patch. Of the 491 vulnerabilities newly named as exploited in the first half of 2026, attackers were already exploiting 141 when those flaws went public, per the Zero Day Clock, read 24 October 2026. In 2023, the majority of the most frequently exploited vulnerabilities were first exploited as zero-days, according to CISA, the FBI, the NSA and their partner agencies (CISA). A check that doesn’t depend on recognizing the attack doesn’t wait for a signature or a patch.

How does kernel-level enforcement differ from EDR, allowlisting and AI guardrails?

Each control asks its own question at its own moment. The table sets the four side by side.

What each control asks, and when
Compared on	EDR	Application allowlisting	Model-layer AI guardrails	Kernel-level enforcement
The question it asks	Does this activity look malicious?	Is this application allowed to run?	Is this prompt, output or tool call allowed?	Was this change authorized?
What it checks	Process and system behavior against signatures, patterns and models	Which applications and components may execute (NIST SP 800-167, Microsoft App Control)	Prompts, model outputs and the tools an agent may call	Each change to a protected server’s files, processes, services, registry keys and settings
When it acts	When it recognizes a threat: it alerts, blocks or responds	When code tries to run	Before the model responds or the tool call runs	At the point of execution
What it must know in advance	What malicious activity looks like	The approved application inventory	Policies for content and tool use	The server’s authorized state, not the attack

They work together. CISA recommends “application allowlisting and/or endpoint detection and response (EDR) solutions on all assets to ensure that only authorized software is executable and all unauthorized software is blocked” (CISA). Kernel-level enforcement adds a third question about each change on a protected server: was it authorized?

For AI agents, Mimic AI Guardrails governs what agents do inside the environment, enforced at the kernel. Prompt filtering is a model-layer control, and the two work together.

What doesn’t kernel-level enforcement do?

It protects servers, not laptops or workstations: Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later.
It doesn’t replace detection, patching, backups or identity controls. CISA’s advice still applies: patch internet-facing systems first, require phishing-resistant MFA and keep offline, tested backups (CISA).
It’s only as precise as the baseline. A finance server and a domain controller carry different baselines because their normal operation differs.
In Maintenance Mode, Mimic suspends enforcement and keeps monitoring. Plan those windows like any other change.
It doesn’t run on network appliances. Patching and hardening those stays with the controls built for them.

What does kernel-level enforcement do against real techniques?

Three labeled scenarios, each built on a technique MITRE ATT&CK documents and tied to a CISA advisory. Each shows what the technique does, what a detection-first control does about it (from CISA or the vendor’s own documentation) and what known-good enforcement does. They’re scenarios, not customer outcomes.

Scenario 1, not a customer outcome

Deleting shadow copies before encryption (T1490)

The technique. Before encrypting, attackers commonly delete the recovery data a server would use to roll back. MITRE ATT&CK lists volume shadow copies among the recovery features adversaries remove (T1490). CISA and the FBI report that Akira’s encryptor “uses PowerShell commands to delete Volume Shadow Copy Service (VSS) copies on Windows systems” (AA24-109A).

What a detection-first control does. CISA’s response checklist tells teams to look for anomalous use of built-in Windows tools such as vssadmin.exe and wbadmin.exe, and calls their misuse “a common ransomware technique to inhibit system recovery” (CISA). A detection-first control watches for that misuse and acts when it recognizes it.

What known-good enforcement does. Deleting a protected server’s shadow copies isn’t part of its baseline. Mimic checks the change against the baseline and stops it at the point of execution. CISA’s backup advice still applies: keep offline, encrypted backups and test them (CISA).

Scenario 2, not a customer outcome

Turning off a security tool (T1685, which replaced T1562.001)

The technique. MITRE ATT&CK’s Disable or Modify Tools technique, which replaced T1562.001 in April 2026, covers adversaries who “disable, degrade, or tamper with security tools,” including by stopping services, killing processes and changing configuration files and registry keys (T1685). CISA and the FBI report that “Ghost frequently runs a command to disable Windows Defender on network connected devices” (AA25-050A).

What a detection-first control does. Security tools defend themselves. Microsoft’s tamper protection keeps settings such as real-time protection turned on, and “attempts to modify Microsoft Defender Antivirus settings through the registry are blocked” (Microsoft Learn). CrowdStrike says its sensor uses its kernel-mode presence “to continue to operate even if an attacker would tamper with its user-mode service” (CrowdStrike).

What known-good enforcement does. Stopping a protected service or changing its registry settings is a change outside the server’s baseline. Mimic checks it like any other change and stops it at the point of execution.

Scenario 3, not a customer outcome

Installing a new service for persistence (T1543.003)

The technique. Adversaries “may install a new service or modify an existing service to execute at startup in order to persist on a system,” as MITRE ATT&CK puts it (T1543.003). The August 2026 update to CISA and the FBI’s Medusa advisory lists a command that installs conhost.exe as a service with a Cloudflared token (AA25-071A).

What a detection-first control does. Windows logs event 4697 when a service is installed. Microsoft recommends monitoring for it “because a new service installation should be planned and expected,” and says “Unexpected service installation should trigger an alert” (Microsoft Learn). The guidance is to watch for the new service and alert on it.

What known-good enforcement does. A new service isn’t in the server’s baseline. Mimic checks its creation against the baseline and stops it at the point of execution.

What sources do the scenarios use?

Each source below was read on 22 October 2026 unless its date says otherwise. Dates are the dates each page shows.

MITRE ATT&CK: T1490 Inhibit System Recovery (updated 12 May 2026)
CISA, FBI and partners: AA24-109A, #StopRansomware: Akira Ransomware (updated 13 November 2025)
CISA: #StopRansomware Guide (September 2023)
MITRE ATT&CK: T1685 Disable or Modify Tools (updated 11 Sep 2026)
CISA, FBI and partners: AA25-050A, #StopRansomware: Ghost (Cring) Ransomware (19 February 2025)
Microsoft Learn: Tamper protection overview (updated 9 Sep 2026)
CrowdStrike: Tech Analysis: CrowdStrike’s Kernel Access and Security Architecture (9 August 2024)
MITRE ATT&CK: T1543.003 Create or Modify System Process: Windows Service (updated 12 May 2026)
FBI, CISA and MS-ISAC: AA25-071A, #StopRansomware: Medusa Ransomware (updated 18 August 2026)
Microsoft Learn: 4697(S): A service was installed in the system. (updated 7 Sep 2021)

FAQ

What do security architects ask about kernel-level enforcement?

What is kernel-level enforcement security?

Kernel-level enforcement security checks each attempted change to a protected server at the kernel, before it executes, against a verified record of that server’s authorized state. Ring 0 is the processor’s most privileged level, where the operating system itself runs. Authorized changes proceed. Mimic stops a change outside the record at the point of execution. It needs no attack signature or prior knowledge of the threat. Mimic Networks builds its platform on it.

How is kernel-level enforcement different from EDR?

EDR recognizes threats by signature or behavior, then alerts, blocks or responds, and its sensors run kernel components too. Kernel-level enforcement asks a different question: was this change authorized? It checks each change to a protected server against that server’s baseline and stops what falls outside it at the point of execution. Mimic runs alongside existing EDR, XDR, SIEM, SOAR and BCDR tools rather than replacing them.

Why does enforcement happen at the kernel?

Because that’s where a change to a file, process, service, registry key or setting actually happens. On Windows, a file system mini-filter driver sees file operations before they complete and can prevent them. On Linux, eBPF runs checks inside the kernel itself. Deciding there lets Mimic stop a change outside the baseline at the point of execution, rather than report it after it has run.

Does kernel-level enforcement need to know the attack in advance?

No. It checks whether a change was authorized, not whether it resembles a known threat. A zero-day exploit, a new ransomware strain or an attack run through signed tools with valid credentials still has to make a change on the server, and that change gets the same test as any other.

Is kernel-level enforcement the same as kernel self-protection?

No. The Linux kernel documentation describes kernel self-protection as the design of systems within the kernel to protect against security flaws in the kernel itself, through measures such as memory protections and module signing. Kernel-level enforcement security uses the kernel as the place to check changes to a protected server against its authorized state. One hardens the kernel. The other uses it to decide.

What happens to legitimate administrative work?

Approved updates are part of the baseline’s lifecycle, so legitimate operations continue as the environment changes. For planned administrative work there’s Maintenance Mode. In Maintenance Mode, Mimic suspends enforcement and keeps monitoring, so plan those windows like any other change. Outside those windows, an administrator’s change gets the same check as anyone else’s: was it authorized?

Which systems does Mimic’s kernel-level enforcement protect?

Servers: Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later. On Windows it runs as a file system mini-filter driver and on Linux through eBPF, with the enforcement logic in a WebAssembly sandbox implemented in Rust, from a single module on both. Laptops, workstations and network appliances are outside its scope, so the controls built for them stay in place.

Is Mimic a kernel driver, and what does the CrowdStrike outage mean for it?

On Windows, yes. Mimic’s enforcement runs as a file system mini-filter driver, kernel code like other security drivers. CrowdStrike traced the July 2024 outage to a content update that caused an out-of-bounds memory read in its driver, and Microsoft estimated 8.5 million Windows devices were affected. Mimic’s enforcement logic runs in a WebAssembly sandbox, but the driver around it is still kernel code. Ask any kernel vendor, Mimic included, how updates are tested and staged.

What does Microsoft’s move toward user-mode security mean for Mimic?

Microsoft said on 18 November 2025 that it had released a private preview of its Windows endpoint security platform, which “shifts AV enforcement from the kernel to user mode.” The same post says Microsoft is extending its “driver resiliency playbook” beyond antivirus and “will continue to support third-party kernel mode drivers.” It gives no date for general availability. On Windows, Mimic’s enforcement runs as one of those third-party drivers, a file system mini-filter driver.

Does kernel-level enforcement slow servers down?

Enforcement overhead is tunable. Mimic decides inline, before the change executes, without a separate scanning or review step, and changes that match the baseline proceed. No reboots required, for deployment, policy changes or upgrades. Mimic doesn’t publish a latency figure, so test it on your own workload first, as you would any control that runs on production servers.

What sources does this page use?