Block AI threats.

An autonomous system taking actions outside what its operator intended, usually not through malice but through misreading a task, being manipulated, accumulating errors across steps, or drifting from the original objective. It generally holds valid credentials and uses approved tooling, so its activity looks legitimate to identity controls and endpoint detection. What makes an action rogue is not who took it but whether it was authorized.

By evaluating the change rather than the identity behind it. Credential validity is the wrong control point, because an agent with legitimate access can still take an action nobody sanctioned. Mimic checks each attempted change against the scope the agent declared and the system's known-good state, and blocks anything outside it at the kernel before it executes, whatever account requested it.

Guardrails generally operate at the model layer, filtering prompts and constraining what an agent is permitted to generate or request. Kernel-level enforcement operates at the system layer and governs what actually changes when the agent acts. The two are complementary rather than competing. Model-layer controls can be talked around, while a kernel decision evaluates the resulting change regardless of how the agent arrived at it.

Every agent declares its intended scope before it acts, and no declaration means no access. That scope is mapped against a known-good blueprint of the files, processes, registry keys and services the agent is authorized to touch. An action falling outside the declared scope is blocked at the kernel, regardless of credential validity or which tool the agent used to attempt it.

Blocking one action at a time is weak against an adaptive agent, which simply varies its next attempt. Trajectory interception watches the sequence of changes an agent is making against the known-good state and identifies when the direction of that sequence is heading somewhere unsanctioned. The sequence is stopped rather than each step being individually denied while the agent routes around them.

The difference between what an agent was asked to do and what the system looks like once it has finished. An agent can complete its stated task and still leave changes nobody asked for: altered configurations, new files, modified permissions. Comparing post-task system state against the declared intent surfaces those as violations, which action-by-action monitoring during execution tends to miss.

It addresses the consequence rather than the technique. Detecting and filtering malicious prompts at the model layer is a moving target. Kernel enforcement does not need to know how an agent was persuaded: if the resulting action falls outside its declared scope and the system's known-good state, it does not execute. That holds whether the instruction came from a user, a document or an injected payload.

It keeps its valid credentials and its approved tool access, which is exactly why identity-based controls do not contain it. Enforcement holds the agent to its declared scope regardless. The actions an attacker would need it to take, such as writing to protected directories, altering services or establishing persistence, fall outside the known-good state and are blocked at the kernel before they execute.

Applying the same authorization test to AI agents, human administrators and automation scripts alike. The question is whether the change was authorized, not who initiated it. This matters because agents commonly run on service accounts or delegated administrative credentials, which identity-based controls treat as trusted by default. Taking identity out of the decision closes that gap.

Enforcement that does not depend on which agent framework, orchestration platform or utility initiated an action. As organizations run agents from several vendors at once, tool-specific controls need separate policy for each, and a new framework arrives ungoverned. Enforcing below the tool layer means a framework deployed tomorrow is held to the same known-good state without anyone authoring new policy.

From a record captured as enforcement happens rather than assembled afterward from separate logging tools. Mimic logs a complete, sequenced account of the kernel-level actions an agent took, in order and with timing. Because it accumulates during operation, reconstructing an incident is a retrieval rather than a forensic exercise, and the record exists before anyone asks for it.

Regulators increasingly expect an organization to show what an autonomous system was authorized to do, what it actually did, and how deviation was controlled. That is difficult to produce retrospectively, because the evidence has to have been captured while the agent was running. A record generated by the enforcement layer itself covers all three without a separate documentation exercise.

They are the same enforcement question in two contexts. Virtual patching closes exposure from a vulnerability while no vendor fix exists. Agent enforcement closes exposure from an agent acting outside its sanctioned scope. In both cases the impact requires an unauthorized change to a protected system, and in both cases that change is evaluated at the kernel without needing prior knowledge of the specific technique.

The decision has to happen in the same operation as the change rather than in a review queue. Mimic evaluates each attempted change against the known-good state at the kernel and either permits or blocks it there, so there is no approval step and no interval during which the agent waits. Authorized actions run at full speed. Unauthorized ones do not run.

Enforce boundaries at the system layer rather than the model layer. Model-layer controls govern what an agent says and requests, they are worth having, and they can be talked around. A system-layer control governs what actually changes. Requiring each agent to declare its scope, then blocking anything outside it at the kernel, holds regardless of which agent acted, which tool it used, or whose credentials it held.