Cloud workload security has spent the last few years pulled between two approaches that each give up something. Agentless scanning reads a snapshot of a cloud environment from the outside, cheap to deploy and hard to evade, but blind to what a workload actually does once it is running. Runtime agents sit inside the workload and see execution as it happens, which is exactly what a snapshot misses, but they are heavier to deploy and operate and they generate a firehose of events that has to be stored, filtered, and correlated somewhere. A patent application published July 2, 2026 describes a design aimed squarely at the seam between those two worlds: a runtime sensor that is deliberately lightweight, that acts locally on what it sees, and that hands its observations to a structure most engineers think of as a build artifact rather than a detection tool.

The hero record is US20260189464A1, "Endpoint Detection and Response Based on Aggregated Runtime Execution Data," assigned to Wiz, Inc. As described, a sensor is provided to a resource in a cloud computing environment and configured to detect an event from a data-link-layer communication. When an event fires, the sensor matches it against a rule; the rule specifies a mitigation action to take if a condition is met; the sensor initiates that action; and, critically, the data of the event is written into a software bill of materials. That last step is the one worth slowing down on, because it changes what an SBOM is for.

The system and method for performing cybersecurity threat detection on a resource in a cloud computing environment are presented. The method includes providing a sensor to the resource; configuring the sensor to detect an event in the resource from a data link layer communication; matching the event to a rule, the rule specifying a mitigation action if a condition is met; initiating the mitigation action in accordance with the rule; and including data of the event in a software bill of materials (SBOM).— Endpoint Detection and Response Based on Aggregated Runtime Execution Data, US20260189464A1

An SBOM used as a runtime event ledger

A software bill of materials is conventionally a static inventory: a list of the components, libraries, and dependencies that went into a piece of software, produced at build time and consulted when a new vulnerability lands so a team can ask "do we ship the affected library?" The disclosed method uses the same structure for something different. As detailed in the dependent claims, the data recorded for each event can include an identifier of the resource, an identifier of the application executing during the event, a URL request, an identifier of a software library or binary accessed during the event, a hash value, and a timestamp. In other words, the SBOM stops being a frozen picture of what was built and becomes a running record of what actually executed, accessed, and communicated at runtime, indexed by the same component identities the static SBOM already tracks.

That design choice is what enables the more interesting behavior the application describes: correlation across events. One dependent claim describes detecting an identifier of the resource in the event data held in the SBOM, inspecting that resource for a cybersecurity object, detecting a further event recorded in the SBOM, and then initiating a remediation action based on a toxic combination in response to the object and the other event appearing together. The remediation options named are the familiar containment levers, implementing a security patch, modifying permissions, applying access controls, blocking malicious IP addresses, or disabling compromised accounts, but the trigger is the notable part. A single event may be unremarkable; a specific object present alongside a specific later event is what the method treats as dangerous. Storing the events in a shared, structured ledger is what makes joining them possible after the fact rather than only in the instant.

Two further details point at an engineering posture rather than a single feature. Detection at the data-link layer, the second layer of the network stack, places the sensor low enough to observe communication before much higher-level context is available, which suits a sensor meant to be broad and cheap rather than deeply application-aware. And the application describes configuring the sensor to terminate detection after a predetermined period of time or after a predetermined number of detected events, an ephemeral-sensor pattern that fits a cloud environment where workloads themselves are short-lived and a permanently resident agent is often the wrong shape. The sensor gathers, records to the SBOM, and can step back out.

Where it sits in the field

The same assignee published a second application in this drop that describes the other half of the picture. US20260189596A1, "Techniques for Agentless Detection of Sensitive Data on Managed Databases," describes building a security database that holds a representation of the cloud environment as a graph of nodes, generating a data-file node, classifying whether a file contains sensitive data such as personal, health, or payment-card information, and acting on the location where that data is found. Read together, the two filings sketch a system with a graph model of the environment on one side and a runtime event ledger feeding it on the other, the static map and the live telemetry meeting in the same data store.

Against the wider July 2 publication batch, the runtime-correlation idea is recognizably part of a broader field motion. US20260189600A1 describes threat detection across a collective of client networks that generates an alert on a rule match and initiates an automated response across every member of the collective. US20260189576A1 describes a distributed edge-native system that computes risk scores from a graph linking users, devices, and sessions and pushes updated policy to enforcement nodes. And US20260187247A1, assigned to Check Point Software Technologies, describes threat extraction and sandboxed threat emulation for downloaded files. The common thread across these separate filings is the same one the hero record leans on: detection is moving from single-point matching toward correlated signals evaluated against a model of the whole environment. The hero application's contribution to that motion is specific, using the SBOM itself as the substrate the correlation runs over.

The load-bearing caveat is the usual one, and it matters for reading this correctly. US20260189464A1 is a published application, not a granted patent, and it is a description of an invention rather than a shipping feature. It tells us how the disclosed approach is meant to work and where it fits in the field, not what has been built or what claims will ultimately issue. For a technology reader the interesting fact is the design idea itself: an ephemeral, data-link-layer sensor that folds its observations into a software bill of materials so that a benign object seen once and an event seen later can be joined into the combination that actually warrants a response.