Endpoint security has a structural problem that no amount of signature updating fully solves: the defender is always reacting to what the attacker already did. The classic endpoint agent watches the operating system for events, compares them against a catalog of known-bad patterns and hand-written rules, and blocks or quarantines on a match. That works well against the malware you have seen before. It works poorly against the operation you have not, because by definition there is no signature for it yet. A newly published patent application takes a different swing at that gap. Instead of matching events against a fixed ruleset, it puts a reinforcement-learning agent on the endpoint and lets it learn which response to take.

The hero record is US20260172451A1, "Cybersecurity Reinforcement Learning Agent," published June 18, 2026 and assigned to CrowdStrike, Inc. The application describes an endpoint cybersecurity reinforcement-learning (RL) agent that interfaces with the host operating system as an antimalware driver. That placement matters technically: a driver sits low in the stack, close to the kernel, where it can both observe OS-generated event notifications and act on them. The agent receives an event notification from the OS, determines a responsive cybersecurity action using reinforcement learning, and then implements that action back through the OS. The disclosure frames the payoff as faster identification of new or novel suspicious events and operations than conventional approaches manage.

An endpoint cybersecurity reinforcement learning agent uses reinforcement learning to implement cybersecurity actions. The endpoint cybersecurity RL agent interfaces with a host operating system as an antimalware driver. The endpoint cybersecurity RL agent receives an event notification generated by the OS and determines a responsive cybersecurity action using the reinforcement learning.— Cybersecurity Reinforcement Learning Agent, US20260172451A1

Why reinforcement learning, and not just another classifier

It helps to be precise about what "reinforcement learning" buys here, because most machine learning already deployed in endpoint products is supervised classification: train a model on labeled benign and malicious files, then score new ones. That answers "is this thing bad?" Reinforcement learning answers a different question, "given this situation, what should I do?", and it learns the answer from the consequences of its own actions rather than from a static labeled set. In the RL framing, the endpoint is an environment, each OS event notification is a state observation, the agent's defensive responses are actions, and the outcomes feed back as a reward signal that shapes the policy over time. The agent is not just labeling events; it is selecting responses and being tuned by whether those responses turned out well. The application's own phrasing, that the agent determines a responsive action "in response to the event notification," is the state-to-action mapping that defines a learned policy.

That distinction is where the disclosed approach sits in the state of the art. Behavioral detection on the endpoint is not new, and neither is feeding OS telemetry into a model. The state of the art has long correlated event chains and modeled system state to spot suspicious sequences. What the application adds is the decision loop: a learner whose objective is to choose actions that generalize to operations it was never explicitly shown. The CPC classifications on the record map cleanly to that description, G06F 21/53 (executing untrusted programs in a protected, isolated environment), alongside H04L 41/16 (using machine learning for network management), and the network-security cluster H04L 63/20, H04L 63/101, and H04L 63/1425 for security policy and anomalous-activity detection. Read together, those classes describe an on-host learner that observes, decides, and enforces a security policy.

Where it fits in a broader on-endpoint AI push

The agent does not appear in isolation. In the same June 18 publication batch, the same assignee published US20260170133A1, "AI/ML Model Assessment," which describes a service that assesses machine-learning and AI models for cybersecurity threats, specifically by dynamically emulating a Python pickle file associated with a model to reveal whether it behaves normally or abnormally and is therefore safe or unsafe to use. That is the defensive flip side of the same trend: as security tooling leans harder on ML, the model artifacts themselves, including notoriously unsafe serialization formats like pickle, become an attack surface that needs its own inspection. One application puts a learner inside the defense; the other inspects learners for malice.

Step back to the recent cluster and the engineering through-line is consistent. The assignee's published-application history runs from foundational on-host plumbing, a kernel-level security agent that observes events, filters them, and routes them to consumers that act, and an application describing a real-time situational model of monitored-device state, through to higher-order detection logic such as cardinality-based activity-pattern detection over event streams. The new RL agent is recognizably the next layer on that stack: the earlier records build the sensing and event-routing substrate on the endpoint; this one describes a decision-maker that sits on top of that substrate and learns its responses. An application on applying machine-learning models to a binary search engine over an inverted byte-sequence index shows the same lineage on the file-analysis side, ML pushed progressively closer to the live endpoint.

An informed reader should hold two things in tension about the engineering tradeoffs the disclosure raises. On one side, the architecture is a genuine answer to the novel-attack problem: a policy learned from outcomes can, in principle, respond sensibly to an event sequence it has never seen, where a signature simply has no entry. Running it as an antimalware driver also keeps the decision local, which matters for latency-sensitive response and for endpoints that are not always connected to a cloud backend. On the other side, reinforcement learning on a production endpoint is hard precisely because the reward signal is hard: in a live security setting, a wrong action can mean a blocked legitimate process or, worse, a missed intrusion, and the agent has to learn without treating real user machines as a sandbox to experiment in. The isolation framing implied by G06F 21/53, executing the suspect operation in a protected environment, is one plausible way to gather outcome signal without paying full production cost for a bad action, though the published abstract describes the agent and its OS interface rather than spelling out the training regime.

The necessary caveat is also the load-bearing one for reading this correctly: US20260172451A1 is a published application, not a granted patent, and it is a description of an invention, not a shipping feature. It tells us how the disclosed approach is meant to work and where it sits in the field, not what has been built or what claims will ultimately issue. For a technology reader, that is the right altitude anyway. The interesting fact is not who filed it but what it describes: an endpoint defense that learns its responses by doing, placed at the driver layer where it can both watch the operating system and act on it, aimed squarely at the operations that no signature has caught yet.