An attacker logs in with a stolen domain admin credential. Every tool in your stack sees a legitimate administrator using approved tools. What stops that person from killing your backup agent, disabling your EDR (Endpoint Detection and Response), or encrypting a critical application?
Most ransomware defenses can’t answer that question well. Detection tools look for known bad behavior, and identity controls confirm that the credential is valid. Immutable storage protects backup data, but the agents, services, and configurations that run your protection remain exposed to anyone who holds the right keys.
Mimic takes a different approach to kernel-level ransomware protection. It builds a profile of each protected system’s known-good behavior and blocks any change outside that profile at Ring 0, the operating system kernel, regardless of who requests it.
To understand how that works in production, Techwrix spoke with Bob Blakley, Mimic’s co-founder and Chief Product Officer. This review covers Mimic’s Ring 0 architecture, deployment model, differentiation from EDR, and a real-world use case, followed by our assessment of where the platform fits.
Also Read: Top 12 MSP Backup Solutions for 2026: Multi-Tenant, Ransomware-Ready, and Priced for SMB Margins
About Mimic and Bob Blakley
Mimic is an enterprise security platform founded in 2023 and headquartered in Palo Alto, California. In February 2025, the company raised a $50 million Series A led by GV (Google Ventures) and Menlo Ventures, with participation from Ballistic Ventures, Team8, Wing Ventures, and Shield Capital.
Mimic’s product line includes Ransomware Defense, AI Shield, AI Governance, and Virtual Patching, all built on one kernel enforcement engine.
Bob Blakley co-founded Mimic with CEO Derek Smith and serves as Chief Product Officer. He previously served as an Operating Partner at Team8, Global Director of Information Security Innovation at Citi, Distinguished Analyst at Gartner and Burton Group, and Chief Scientist for Security and Privacy at IBM. He was also the general editor of the OASIS SAML specification.
Key Takeaways
- Mimic enforces a known-good baseline at Ring 0 using a file system mini-filter driver on Windows and eBPF (extended Berkeley Packet Filter) on Linux.
- It evaluates whether a change is authorized, so an attacker with valid admin credentials still can’t alter a protected application.
- Enforcement logic runs in a WebAssembly sandbox written in Rust, designed so a fault in Mimic’s code can’t crash the host.
- Legitimate maintenance runs through declared change windows, with API hooks for CI/CD pipelines and ticketing integration.
- Mimic’s core bet, in Blakley’s words, is that it can keep pace with how often your critical applications change.
Why Valid Credentials Defeat Traditional Ransomware Defense
Ransomware operators increasingly skip custom malware. They log in with stolen credentials and use the same administrative tools your IT team uses every day. Carl Mosby, Mimic’s Marketing Director, told Techwrix that nearly every successful ransomware breach the company studied happened with an EDR product already deployed, which led the founders to look for a different enforcement model.
Techwrix: Why can’t detection tools stop an attacker who already holds valid administrative credentials?
Bob Blakley: “We observe everything the applications we protect actually do and build a profile of their known-good behavior. Then we make sure that no change process can modify that behavior without our permission.
So if a ransomware binary tries to encrypt a file belonging to the application, we block it. If a privileged system administrator, maybe somebody with a stolen credential, tries to kill a process belonging to the application, we block that too. We can block human behavior using approved tools with privileged identities.
The effect is that we can freeze the application in its good operating state. A ransomware actor using binary ransomware, living-off-the-land (LOTL) tools and command-line access, or a bring-your-own-vulnerable-driver attack can’t change how the application functions and can’t damage its resources.”
That distinction matters for your backup and security tooling. A credential check confirms who’s acting. Mimic’s enforcement checks what the action does to a protected system, and blocks it when the change falls outside the approved profile.
Ring 0 Architecture: How Kernel-Level Ransomware Protection Works
Ring 0 is the most privileged level of the processor, where the operating system kernel runs. Every file write, registry change, driver load, and process action passes through it. Enforcing at this layer lets Mimic decide whether a change happens before it executes.
Figure: Mimic kernel-level ransomware protection architecture across Windows and Linux
The kernel components
Techwrix: Mimic describes itself as operating at Ring 0. What does that mean in practical architectural terms, and which operating system components make it possible?
Bob Blakley: “The Mimic platform is based on a kernel agent that runs on the Windows and Linux operating systems hosting the applications we protect. On Windows, that’s a file system mini-filter driver. You’re probably aware of the Windows kernel driver architecture. As a Windows kernel driver, we have to participate in that structure, so we install at the altitude of an anti-malware utility, the same way an EDR or antivirus package would.
The Linux architecture is different. Linux has an existing interface called eBPF, which is increasingly inaccurately named. It was originally a network utility, but it’s expanded to cover a very broad range of kernel functions. Linux has architected access to eBPF in such a way that we can do all the same things we do on Windows with a kernel driver.”
Why the sandbox matters
Kernel code carries real risk. A faulty kernel update can take down every machine it reaches, and security teams haven’t forgotten the July 2024 CrowdStrike outage.
Techwrix: How does Mimic avoid becoming the cause of an outage itself?
Bob Blakley: “In both cases, our kernel agent logic runs in a sandbox environment we’ve developed using WebAssembly. The idea is that we don’t want to create an outage ourselves. A malfunction in our code shouldn’t prevent the customer’s application and system from running properly. We obviously had [the CrowdStrike incident] in mind, but we were thinking about this before it happened. We come from an enterprise security and availability background, and we knew we’d need to fail-safe.
The Wasm sandbox lets us run Rust code in the kernel. It provides a strong isolation layer from other processes on the box, so if our code blows up, it blows up inside the sandbox and doesn’t interfere with anything else. The sandbox also lets us control resource allocation to our process, so it can’t exhaust the CPU cycles or memory of the system we’re running on.”
Also Read: How Traffic Capture and Replay Make Sandbox Testing More Accurate Than Traditional API Mocking
How the known-good baseline is built
Techwrix: How does Mimic establish its known-good baseline?
Bob Blakley: “On top of the kernel agent, we observe all of the behavior of the applications we protect and build a profile of known-good behavior. That means which files and directories the application touches, which processes it starts and stops, which processes it executes to perform its logic, which registry entries it reads and writes, and so forth. Once we have that known-good behavior, we use it to ensure no change process can modify the application without permission from us.”
Figure: Mimic establishes its known-good baseline
Blakley summarized the design logic in Mimic’s kernel-level enforcement guide: there’s effectively infinite bad behavior to catalog, so Mimic models the finite set of good behavior instead. A finance server and a domain controller get different baselines because their legitimate behavior differs.
| Baseline element | What Mimic records |
| Files and directories | Which paths the application reads and writes |
| Processes | Which processes it starts, stops, and executes |
| Registry | Which keys it reads and writes (Windows) |
| Services | Which services it depends on and how they’re configured |
Tamper Resistance and Its Limits
Any security agent is a target. If attackers can switch it off first, everything downstream fails, including your EDR and backup agents.
Techwrix: How does Mimic protect itself from tampering if an attacker has already gained administrative or domain-level access?
Bob Blakley: “The key word there is ‘already.’ Ken Thompson, in his Award lecture, demonstrated pretty conclusively that if a bad guy gets onto a system before any good guy does, he can create a form of malicious persistence that can’t be detected and removed. So we rely, as everybody else does, on the assumption that we get to the system before the first bad guy.
Once we’re on the system, we can see attempts to inject new functionality into its privileged architecture and block them. We can prevent the kinds of attacks that unhook EDR agents from the kernel on a Windows system, which is a prevalent form of EDR bypass, because we’re watching attempts to change the privilege structure of the system. We do the same for our own agent. We watch to make sure nothing is deactivating it.
We also have a variety of proprietary techniques that allow independent components in the system to monitor one another. A von Neumann architecture system can fundamentally only do one thing at a time. If multiple elements are watching each other, an attacker has to choose which one to kill first, and the others can see that. The best you can probably ever do is guarantee you’ll see it and report it. You probably can’t guarantee you’ll always prevent it, but it’s still a strong form of protection.”
Techwrix: Are there circumstances where an attacker could still bypass Mimic?
Bob Blakley: “Because of how Windows is designed at the BIOS and boot level, a software component on the system, like a kernel driver, can never in principle defend against an adversary with physical access who reboots the box into safe mode and deletes its components. That’s not an architectural flaw in Mimic, or in an EDR, or in any other component. It’s an inherent characteristic of Windows, which needs to be able to repair itself when corruption can’t be reversed any other way.”
That candor is useful for your threat model. Mimic’s protection assumes clean installation and no physical access, the same assumptions that apply to any host-based security agent. Physical security and secure boot controls still carry that risk.
Deployment and Change Governance
A control that blocks privileged administrators also blocks your own administrators. How Mimic handles legitimate change decides whether it survives contact with a real operations team.
Techwrix: How does the platform accommodate legitimate administrative activity, such as patching, agent upgrades, policy changes, and emergency maintenance, without creating operational friction?
Bob Blakley: “Since we block the behavior of humans using approved tools with privileged identities, we also block normal administration of the applications we protect. Obviously, you don’t want that all the time. Sometimes you actually do want to administer the applications. So we’ve implemented a dual-control mechanism that allows a legitimate administrator to declare their intent to make a change during a recognized change window.
The enterprise notifies us that a change window is beginning, using a credential that’s valid in the Mimic ecosystem. You essentially log on to us and say, ‘We’ve got a change happening here. We’re going to upgrade SAP from version 4.1 to 4.2.’ At that point, we switch from active enforcement mode to maintenance mode. As we always do, we keep a detailed forensic record of everything that happens during the window. When the update is complete, we reprofile the application to capture any new behavior that belongs in the known-good profile, then switch back to active mode.
Different enterprises have different opinions about how much friction they want in that process. We accommodate that with a manual mechanism you can run from the command line or the user interface, and with an API, so the CI/CD automation runners an enterprise uses to implement changes can trigger the Mimic change notification process directly.”
Carl Mosby added that some customers adopt Mimic primarily for change governance. Mimic integrates with ticketing systems such as ServiceNow so change approvals can be automated while keeping the gates each organization wants.
Also Read: How to Build an AI Governance Framework for Enterprise IT
What Happens When Mimic Blocks a Change
Mimic treats any attempt to disable a security agent, alter its configuration, or tamper with its data as another unauthorized change. That’s how it extends protection to the EDR and backup agents running on the same host.
Techwrix: What does a customer gain when ransomware defense is active and an attacker reaches a protected system?
Bob Blakley: “What you gain is essentially an assume-breach, last-line-of-defense control. It prevents damage to the resources belonging to an application, even if all of the other controls in the enterprise are defeated, and a ransomware actor gets the ability to be resident on the system and initiate an attack against an application.”
The backup trigger is the most relevant point for backup and recovery teams. Immutable storage protects backup copies. Mimic’s role is to prevent the host, its agents, and its configuration from changing, and to provide your backup platform with a clean recovery point when an attack starts. Ask Mimic which backup platforms it has validated this integration with before you plan around it.
Beyond Ransomware: AI Guardrails and Virtual Patching
The same enforcement engine now covers two newer risks: AI agents with privileged access and vulnerabilities that arrive faster than patches.
Figure: Mimic known-good enforcement capabilities
AI guardrails
Techwrix: How does ransomware defense extend to AI agents?
Bob Blakley: “Last year we realized that defending against human ransomware actors using hands-on-keyboard techniques and living-off-the-land tools was exactly the same problem as preventing an improperly prompted or hallucinating AI agent from damaging the system. An AI agent is essentially the equivalent of a human actor you’ve given privileged credentials to on purpose and pointed at the administrative interfaces of the system. Because we could stop humans from damaging the system through that vector, we could also prevent the legitimate AI agents you’ve installed in your enterprise from damaging it the same way.”
Also Read: Best 5 Agentic Container Security Platforms
Virtual patching
Techwrix: What led Mimic to build virtual patching?
Bob Blakley: “When Anthropic announced Glasswing, we got a flood of calls from CISOs in our network. They expected many more vulnerabilities to be reported, and they didn’t believe vendors could patch them quickly enough. Even if vendors could, they didn’t believe their own staff could apply the patches fast enough while still doing testing, validation, and change windows.
We’d been building a known-good profile of the application and blocking anything that tried to reach across its boundary and modify that behavior. It occurred to us that if we turned that inside out and watched the application itself depart from known-good behavior because a vulnerability was being exploited, we could block outbound access and keep it from damaging resources belonging to the rest of the system.
When a new vulnerability is identified or reported to us, we profile the exploit. Because we know what known-good behavior looks like, we can look at the difference between it and the exploited behavior, find the points where the exploit code path can be intercepted, and create logic that blocks it. That’s just a piece of policy, like the policy we use against ransomware. We can develop a virtual patch within about 24 hours and deploy it in minutes across our fleet of protected systems, without rebooting the operating system, changing the application binary on disk, or even stopping and restarting the application.”
Here are some capabilities and the risks they address:
| Capability | Risk it addresses |
| Ransomware Defense | Encryption and damage by attackers already on the system |
| Change governance | Erroneous or malicious changes from admins and automation |
| AI guardrails | Misprompted, hallucinating, or overreaching AI agents |
| Virtual Patching | Exploitation between vulnerability disclosure and vendor patch |
By implementing these strategies, organizations can significantly enhance their security posture.
How Mimic Differs from EDR, Allowlisting, and File Integrity Monitoring
Mimic sits closest to three categories you probably already run. The difference comes down to the question each control asks and when it acts.
| Control | Question it asks | When it acts | Gap against a credentialed attacker |
| EDR / XDR | Does this activity match a known-bad pattern? | During or after execution | Signed binaries and admin tools can pass clean, and the agent itself can be unhooked |
| Application allowlisting (e.g. WDAC, AppLocker) | Is this executable approved to run? | At launch | An approved admin tool can still modify protected files, services, or configuration |
| File integrity monitoring | Did a protected file change? | After the change | Reports damage that already happened |
| Immutable backup storage | Can this backup copy be altered? | At the storage layer | Leaves agents, retention settings, and host configuration exposed |
| Mimic known-good enforcement | Is this change inside the approved profile? | Before the change executes | Depends on a clean install and an accurate, current baseline |
Three points stand out for security architects:
- Source independence: Mimic judges the change itself. Ransomware, a malicious insider, a misconfigured script, and an AI agent all face the same check.
- Placement beneath other agents: Mimic states that it runs in the kernel beneath endpoint agents and treats attempts to disable them as unauthorized changes. That adds a layer of protection for EDR and backup agents on the same host.
- An additive layer: Mimic doesn’t remove the need for detection, SIEM, or immutable backups. It adds a prevention control at the point where those tools can be bypassed.
Mimic isn’t the only vendor pursuing kernel-level prevention, so compare how each product builds its baseline, handles legitimate change, and fails safe during your evaluation.
Use Case: How REI Protects Active Directory
Active Directory (AD) is one of ransomware’s favorite targets because controlling it gives an attacker control over identity across the estate. Outdoor retailer REI chose Mimic to protect its AD domain controllers.
Here are some details about the case study:
| Area | Detail from the case study |
| Environment | Large hybrid IT estate spanning stores, warehouses, and digital operations, all dependent on AD |
| Challenge | Protect on-premises AD against ransomware in a stack where new tools often clashed with existing ones |
| Deployment | Mimic’s agent learned each asset’s profile automatically and built a tailored protection policy |
| Validation | REI’s own security team ran internal testing and red-teamed its environment, including detonating real ransomware strains in a mirrored test environment |
| Result | Mimic flagged unauthorized changes in REI’s AD environment soon after deployment |
REI CISO Mike Hughes said in the case study that Mimic had already alerted his team to rogue AD changes they would otherwise have missed.
The REI deployment shows a practical adoption path. Start with the system whose compromise hurts most, such as domain controllers, prove the model with your own red team, then extend enforcement to other critical applications.
Also Read: Top 25 Zero Trust Security Tools for Hybrid Cloud
Risk Reduction and Trade-Offs
Every control introduces its own failure modes. Techwrix asked Blakley where the risk moves after deployment, and what Mimic still has to prove.
Techwrix: What risk metrics change for a customer after deploying Mimic?
Bob Blakley: “It depends on which features the customer activates. With change governance, you reduce the risk of erroneous changes from automated processes, errors and omissions during authorized changes, and malicious changes from privileged administrators or attackers. The additional risk you take on is a breakdown in the mechanism that takes us out of line to allow a change or puts us back in line afterward. That could mean an outage of the change management process itself, or a lapse in protection if we don’t go back into enforcement.
With AI guardrails, you mitigate improper prompting that leads to an administrative error, hallucinating agents, and agents exceeding their authority by making changes outside the declared scope. With virtual patching, the primary risk you reduce is exploitation during the window between a vulnerability’s discovery and the application of a vendor patch.”
Techwrix: What’s the strongest assumption behind Mimic’s product strategy that the market still needs to validate?
Bob Blakley: “That we can keep up with the pace of change of an IT estate. Fundamentally, we operate by regulating change. If there’s a relevant change every millisecond, meaning a change in the application’s operational logic or the set of resources it touches, we clearly won’t keep up. If there’s a change every six months, we clearly will. So the question is the base rate of change in an IT estate, at least for the applications that matter, and whether it gives us the slack time we need to regulate that change.”
That answer gives you a clear evaluation criterion. Mimic fits best on stable, business-critical systems such as domain controllers, ERP platforms, and backup servers. Applications that deploy many times a day will need tight CI/CD integration to avoid constant change windows.
Pros and Limitations
When considering the effectiveness of a security solution, it’s important to weigh both its benefits and drawbacks. Here’s a closer look at the pros and limitations of the system.
| Pros | Limitations |
| Blocks unauthorized change regardless of credential validity | Public material covers Windows and Linux servers only; confirm hypervisor and container coverage |
| Needs no signatures or prior knowledge of the attack | Relies on clean installation before an attacker gains a foothold |
| WebAssembly sandbox and Rust implementation reduce kernel crash risk | Can’t prevent physical-access attacks through safe mode reboots on Windows |
| Protects EDR and backup agents on the host from being disabled | Fit depends on how often protected applications legitimately change |
| Change windows integrate with CI/CD pipelines and ServiceNow | Adds an operational dependency: a failed return to enforcement leaves a protection gap |
| One engine covers ransomware, AI agents, and virtual patching | Pricing isn’t published; contact Mimic for a quote |
While the system offers robust preventive capabilities, it’s important to consider its limitations and assess how they may impact your specific security needs.
Who Should Evaluate Mimic
Mimic fits organizations that already run mature detection and backup tooling but worry about what happens when an attacker holds valid credentials.
This solution provides an additional layer of security, ensuring that even with valid credentials, potential breaches are mitigated effectively.
| Role | Why Mimic is worth a look |
| CISO | Adds an assume-breach prevention layer and a forensic record of every attempted change for audit and board reporting |
| Infrastructure and platform leads | Protects domain controllers, ERP, and other stable critical systems without replacing existing agents |
| Backup and recovery teams | Guards backup agents and host configuration against credentialed tampering and can trigger event-driven snapshots |
| Vulnerability management teams | Virtual patching covers systems waiting on vendor fixes or running end-of-life software |
| AI platform owners | AI guardrails constrain what privileged AI agents can change on protected systems |
Organizations that fit this profile should consider implementing Mimic to enhance their security posture and safeguard their critical assets.
Also Read: 12 Best Ransomware Protection & Recovery Solutions for 2026
Questions to ask during your evaluation
- Which of your backup, EDR, and hypervisor platforms has Mimic validated?
- How long does initial profiling take for your critical applications?
- How does the dual control mechanism prevent a compromised Mimic credential from opening a change window?
- What alerting and fallback exist if an application fails to return to enforcement mode?
- How often do your target applications change, and can your CI/CD pipeline declare those changes automatically?
Verdict
Mimic addresses a gap most ransomware stacks leave open: an attacker who looks legitimate because the credentials are legitimate. Its kernel-level ransomware protection evaluates the change itself, so a stolen domain admin account can’t quietly disable your agents or damage a protected application.
The architecture holds up to technical scrutiny. The WebAssembly sandbox directly answers the kernel stability concern, and Blakley is candid about the limits, from clean installation to physical access. The main open question is operational. Your results will depend on how often your critical applications change and how well your change process feeds Mimic’s change windows.
Recommendation: Worth shortlisting for enterprises protecting stable, high-value Windows and Linux servers, especially Active Directory and backup infrastructure.
If you’re evaluating Mimic, take these steps:
- Pick one high-impact system, such as a domain controller or backup server, for a proof of concept.
- Measure your change frequency on that system before deployment.
- Connect Mimic’s change window API to your CI/CD pipeline or ServiceNow workflow during the pilot.
- Red-team the protected system with stolen-credential and living-off-the-land scenarios.
- Confirm backup platform integration and the RPO-Zero snapshot trigger with your own backup vendor.
As AI accelerates both exploit development and privileged automation, controls that ask whether a change is authorized will become a larger part of ransomware defense. Mimic is an early, serious attempt to put that question at the kernel.
