Cloud-security's central UX fight is the agent. Security teams want coverage of every workload; platform and DevOps teams resist installing software on each one because agents add overhead, break deployments, and never reach everything. Agentless scanning is the architecture that tried to end that fight — coverage without the agent.

Orca Security's US11943251B2, “Systems and methods for malware detection” (issued March 26, 2024; CPC H04L 63/1433 — vulnerability assessment, G06F 21/568 — detecting malicious modification of data, and G06F 9/45558 — virtualization), describes detecting malware across cloud workloads. Read it at US11943251B2.

“A cyber security system for a cloud environment is disclosed. In some embodiments, a method is disclosed.”— U.S. Patent No. 11,943,251 source

The mechanism is spelled out in the abstract and claim 1, and the key word is block storage. Rather than running code inside the target workload, the system “utiliz[es] a cloud provider API to access a block storage volume of a workload maintained on a target account.” It reads the workload's disk — the storage volume the cloud platform already holds — instead of installing on the instance that uses it. That is the entire agentless premise expressed mechanically: the data is available through the provider's own API, so you scan the data, not the live machine.

Two design choices make it safe and scalable. First, isolation: the scan runs “at a location of the block storage volume and on a secondary system other than the target system.” The scanning happens out-of-band, on infrastructure separate from the customer's running workload, so it imposes no runtime load and cannot crash the protected instance. Second, the access model is permission-scoped: claim 1 has the target account “authorize access privileges to an account on a scanning system via a cloud provider API” — the customer grants read access through native cloud IAM rather than handing over an agent or credentials inside the box.

The system also adapts the scanner per environment. Claim 1 specifies “modifying a pre-utilized scanner at the location of the block storage volume based on information related to the target account to obtain a modified scanner.” The scanning logic is tuned to what it finds about the specific account before it runs, rather than applying one fixed engine everywhere. After scanning, the system “identif[ies] malicious code based on the scan” and “output[s]… a notification of a presence of malicious code in the target system” — from the secondary system, keeping even the alerting off the workload. The virtualization CPC tag (G06F 9/45558) and the data-modification tag (G06F 21/568) point straight at this: analyze the workload's storage and state, out-of-band, to find malicious modifications.

The dependent claims show how far “read the storage” is pushed. Scanning the block-storage volume “comprises scanning disk-backed memory” (claim 3), and that disk-backed memory “includes at least one of a page file or a cache file” (claim 4) — so the scanner can reach malware that lived in the workload's memory by reading the paged-out and cached copies on disk, recovering some of what an in-instance agent would normally see in RAM. The secondary scanning system can itself be “a virtual machine, a container, or a serverless function” (claim 5) and can even run “an operating system different from” the target's (claim 6), so the analysis environment is hardened and decoupled from whatever the workload runs. The location of the volume to scan is resolved from “the target account, a secondary system account, a cloud provider account, or a third party account” (claim 2) — the plumbing that lets one scanning tenant reach across many customer accounts through native cloud constructs.

It is worth being precise about what this method does and does not do, because the trade-offs define the category's debate. Reading block storage and disk-backed memory out-of-band gives breadth and zero workload impact, and recovering page and cache files claws back some memory-resident threats — but a snapshot is a point in time, so purely in-memory, fileless activity that never touches disk between snapshots can still slip a window that a continuous in-instance agent would catch. The filing's design choices read as a direct response to that critique: tune the scanner per account before running it (the “modified scanner” of claim 1), reach into page and cache files for memory artifacts, and isolate the analysis on a differently-configured secondary system so the scanning itself cannot be subverted by the workload it inspects. The net is a deliberately chosen point on the coverage-versus-impact curve: maximal breadth and zero friction, accepting snapshot-interval latency as the cost.

Why this is a business story: agentless was the wedge that let a new generation of cloud-security companies — Orca and Wiz most prominently — displace incumbents fast, because reading the provider's block storage through an API means full-estate coverage in hours instead of a multi-quarter agent rollout. That speed-to-value, and the fact that the scan touches storage rather than running instances, is exactly what removes the DevOps veto that stalls agent deployments. That dynamic translated into historic growth, with Wiz's trajectory drawing reported multibillion-dollar acquisition interest from Google. The agentless-versus-runtime debate is the defining strategic argument in cloud security, and this Orca grant stakes the agentless position with a concrete block-storage method.

The grounded read: agentless cloud malware detection uses the cloud provider's API to read a workload's block-storage volume and scans it out-of-band on a separate, permission-scoped system — delivering coverage without installing on each workload. Orca's 2024 grant names that approach in claim-level detail — the wedge behind the fastest-growing segment of cloud security.