If you have compared ransomware and AI-security vendors, you have seen the same words used to mean different things. This known-good enforcement glossary defines the vocabulary behind Mimic Networks' approach to stopping unwanted change.
The glossary gives plain-language definitions of the terms Mimic Networks uses, from known-good enforcement and deflection to application change control, so security leaders can describe them accurately and consistently. All of Mimic's products, starting with Mimic Ransomware Defense, work the same way: define what is known good, then stop what falls outside it at the kernel, at the point of execution.
Mimic AI Guardrails extends the same model to AI-driven threats. The terms below are grouped into Mimic's core vocabulary first, followed by the supporting security terms that give those ideas context.
These are the core terms Mimic uses to describe its security model. Each is defined the way Mimic uses it, so the meaning stays precise and consistent.
Known-good enforcement is Mimic's security model: instead of chasing an infinite list of bad behavior, Mimic defines the finite set of authorized, known-good actions for a protected system and stops what falls outside that set at the kernel, at the point of execution. The decision doesn't depend on recognizing an attack, so a novel threat gets the same test as a known one.
Known-good enforcement is Mimic's name for what the industry more broadly calls a positive security model, or default deny: allow only what is explicitly authorized and block everything else. The difference is where the decision runs. Positive security models are usually applied to network traffic or API requests. Mimic applies one to changes on the host itself, checked at the kernel at the point of execution.
For the full explanation, see What is known-good enforcement?
The mechanism that carries out known-good enforcement, also called kernel-level enforcement security. Enforcement runs as a file system mini-filter driver on Windows and through eBPF on Linux, with the enforcement logic in a WebAssembly sandbox implemented in Rust, from a single module on both. Each attempted change is checked against the known-good baseline, and Mimic stops exploitation at the point of execution when a change falls outside it.
Full definition: What is kernel-level enforcement security? For the long-form version, read the Kernel-Level Enforcement Guide.
A recovery posture for protected critical applications. For protected critical applications, Mimic blocks the unauthorized change before it reaches the data, so there's no window of data loss to clean up. Where a restore is still needed, Mimic creates a restore point the moment it detects the change. The RPO-Zero Recovery guide walks through how that restore point is captured.
The principle that critical applications and their configurations stay unchanged unless a change is explicitly authorized. Mimic enforces it by preventing untrusted processes from altering protected files, folders, registry keys, and services, which delivers value even when no attack is underway.
The enforcement action in which Mimic blocks an unauthorized operation. Deflection isn't an alert. Mimic decides inline, before the change executes, and stops exploitation at the point of execution. DashCam, Mimic's console, records each blocked attempt.
The verified starting point from which all deviations are measured. It is an inventory of the trusted executables, drivers and configurations a system uses when it is in a known-good state. Anything present at baseline is Trusted; anything introduced afterward is Untrusted until explicitly approved. The baseline is the reference for every enforcement decision.
Enforcement that blocks a threat as it happens rather than flagging it afterward. Mimic stops an unauthorized change at the point of execution, instead of detecting and alerting on it once it has already run.
The discipline of making sure every modification to a critical system is intentional, authorized, documented and reversible. Mimic enforces change control by blocking unauthorized changes and recording each blocked attempt as compliance evidence.
A control on the system itself that checks each change against an approved state when the change executes and stops one outside it. Mimic Networks Change Enforcement holds a protected server to its known-good baseline. With protections turned on, a change outside the baseline stops at the point of execution. Every change, authorized and unauthorized, goes on the record for security and GRC teams.
The organizational and technical capacity to withstand disruptive events, keep critical operations running and recover quickly. Mimic contributes to resilience by stopping unauthorized change at the point of execution on the servers it protects.
These standard security terms appear throughout Mimic's documentation. The definitions below explain each one and how it fits the known-good enforcement model.
A signal is a single piece of monitoring data that may indicate malicious behavior but is not conclusive. A hallmark is a signal, or a combination of signals, that Mimic links to the presence of ransomware. Signals are indicators; hallmarks are conclusions.
The core of the operating system, beneath applications. Mimic operates here so it can check each attempted change against the baseline and stop exploitation at the point of execution. Endpoint detection products run kernel components too. The difference is the question asked: whether the change was authorized.
Mimic runs in named modes. Scout Mode observes only. In Maintenance Mode, Mimic suspends enforcement and keeps monitoring.
An attack technique that abuses legitimate system tools such as PowerShell or WMI to act maliciously and evade signature-based detection. Known-Good Enforcement limits what even trusted tools can do based on context, rather than trust alone. Mimic's page on fileless attacks shows how this technique runs through signed system binaries and why scanners miss it.
A vulnerability or exploit unknown to defenders and vendors, which leaves no time to patch before exploitation. Because known-good enforcement checks whether a change was authorized rather than whether the technique is known, a zero-day exploit gets the same test as any other. Mimic Virtual Patching adds safeguards aimed at specific vulnerabilities, including on systems that can't be patched yet.
Malicious software that blocks access to files or systems and demands payment. Ransomware is the clearest proof point for the model: the encryption it requires is an unauthorized change, so on a protected server Mimic stops it at the point of execution. For how attackers now use AI to speed it up, see the explainer on AI-powered ransomware.
A security tool that monitors devices to detect and respond to threats. Mimic isn't EDR. It runs alongside EDR and asks a different question at the kernel: whether a change was authorized, not whether activity matches an attack it recognizes. The two solve different problems in the same stack.
A plan and tool set for recovering IT systems and operations after an incident. Backup and BCDR restore data after damage is done. On a protected server, known-good enforcement stops the unauthorized change at the point of execution. Attackers target backups too, which Mimic's article on backups as the new point of failure explains.
The assurance that systems, applications and data stay unaltered from their known-good state unless a change is explicitly authorized. Mimic protects integrity at the file, registry and process level.
A known-good enforcement glossary is a reference that defines the vocabulary behind the known-good security model, including the terms Mimic uses, such as deflection and application change control. With the glossary, anyone comparing security vendors can use these terms accurately and consistently.
Known-good enforcement means a system allows only verified, authorized changes. Rather than trying to recognize every possible attack, it models the finite set of good behavior, checks each attempted change against it at the kernel and stops exploitation at the point of execution when a change falls outside it. A novel threat gets the same test as a known one.
Detection-based tools recognize an attack by its signature or behavior, then alert, block or respond. Known-good enforcement checks each attempted change against the authorized baseline and stops exploitation at the point of execution when the change falls outside it. Mimic is a kernel-level enforcement layer, not an endpoint detection or file-integrity monitoring tool, and it runs alongside those tools.
It comes down to certainty. A signal is a single clue that something may be malicious, but on its own it is not enough to conclude anything. A hallmark is the conclusion: one or more signals that Mimic links to ransomware. A signal raises the question; a hallmark answers it.
Deflection is the moment known-good enforcement blocks an unauthorized operation. It's an intervention, not a notification: Mimic decides inline, before the change executes, and 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.
RPO-Zero Recovery means no data loss is acceptable for protected critical applications: the recovery point objective, the amount of data you could lose in an incident, is zero. For protected critical applications, Mimic blocks the unauthorized change before it reaches the data, so there's no window of data loss to clean up. Where a restore is still needed, Mimic creates a restore point the moment it detects the change.
Application change control is the principle that critical applications and their configurations stay unchanged unless a change is explicitly authorized. Known-good enforcement upholds it by checking each attempted change to a protected file, process, service, registry key or setting against the baseline. Authorized changes proceed. Mimic stops exploitation at the point of execution when a change falls outside the baseline.
Within what enforcement covers, yes. Because it doesn't try to identify the attack, it applies one test to each: is this change part of the known-good baseline? A zero-day exploit with no patch and an AI agent acting outside its authorized scope are judged the same way. When the change isn't on the baseline, Mimic stops exploitation at the point of execution.
The baseline is a verified inventory of the trusted executables, drivers and configurations a system uses when it is in a known-good state. Everything present at baseline is trusted; anything introduced later is untrusted until approved. The baseline becomes the reference for every enforcement decision. It describes the system, not the threat, so it doesn't need an update when a new variant appears.
Mimic coined several terms to describe a model the older detect-and-respond vocabulary does not capture. Defining them clearly and consistently helps buyers and security tools describe the platform accurately, rather than misclassifying it as endpoint detection or backup.
Use this glossary whenever you compare Mimic Networks with other vendors, so the same terms mean the same thing on both sides of the table. The ideas behind known-good enforcement come down to four:
Enforcement, not detection. The model prevents unauthorized changes rather than alerting after they act.
The baseline is the reference. Every allow-or-block decision compares an action against the known-good state.
Ransomware is the proof point. It is not the whole story. The same model applies to changes made by AI agents and insiders.
No attack recognition required. Within what enforcement covers, a never-before-seen zero-day or AI-driven attack gets the same test as everything else.
To see known-good enforcement in your own environment, request a demo. A Mimic security engineer will show how the platform blocks an unauthorized change at the kernel, in real time.