Inspect deeply.
Keep the footprint small.

One layer of a coordinated security system.

Explore Runtime Assurance: Execution Integrity, Compute Integrity Monitoring, Drift Control and Runtime Truth. This article focuses on inspection within that wider system.

Our broader design brings identity, application isolation, connection control, detection and response together. The control loop is simple: inspect, decide, act, verify. Evidence informs policy; authorized controls take action; verification confirms the outcome and records what happened.

This article focuses on how we collect and inspect evidence. Read-only probes have a deliberately narrow job. Separately authorized controls can block connections, isolate workloads or devices, revoke access, stop processes or initiate remediation. Continuous monitoring and prevention belong alongside inspection where timing matters.

A probe’s read-only boundary separates inspection from the authority to change a system. The wider design includes action, with explicit policy for automatic responses, human approval and recovery.

Inspect the system. Limit the footprint.

Endpoint detection and response needs visibility into a machine. It does not follow that every inspection needs a large, permanently privileged process or a third-party kernel module. Agentless approaches separate collection from continuous endpoint residency, with different tradeoffs in coverage, response and operational risk.

Agentless security covers several approaches: temporary inspection jobs on live hosts, remote queries, and analysis of disk snapshots or other collected evidence. Some use SSH; others use dedicated execution protocols or infrastructure APIs. The category describes an approach to deployment, not a single transport or detection engine. Live inspection and snapshot analysis expose different evidence, so coverage depends on what is collected and how it is evaluated.

Legacy EDR: Microsoft, CrowdStrike and Elastic must justify the footprint.

Microsoft Defender for Endpoint, CrowdStrike Falcon and Elastic Defend should face the same scrutiny as any other privileged software. A recognised brand does not excuse resource overhead, operational disruption or an update path capable of taking machines down.

We challenge the legacy assumption that security requires a broad, permanently resident stack on every machine. Here, “legacy” describes that architectural assumption, not a claim that these products are discontinued or technically identical. Microsoft publishes substantial system requirements, Elastic publishes a measurable endpoint footprint, and CrowdStrike's 2024 Windows incident demonstrates the consequences of a failed privileged update. The evidence and its limits are below.

The traditional monolithic approach puts a broad, continuously running security stack on every endpoint. Memory, CPU, disk activity, privileged updates and compatibility work become recurring costs across the fleet. On small servers and older workstations, that footprint can compete directly with the work the machine exists to do.

Our position: make the vendors earn the resources and privileges they ask for. Demand workload-specific measurements, staged updates, recovery procedures and evidence that the protection justifies the footprint. “It is the industry standard” is not a performance result or a safety argument.

A monolithic agent is an architectural choice, not a synonym for every installed EDR. Many products combine several techniques. Compare their actual privileges, update mechanisms, failure behaviour and coverage.

Published numbers make the cost concrete.

Sources checked 7 October 2026. Requirements, vendor performance claims and reported incidents are labelled separately. These are not results from a common benchmark.

At a planning allowance of 500 MB per endpoint, 1,000 endpoints add up to 500 GB of distributed memory capacity. On a 4 GB machine, 500 MB is roughly one eighth of RAM. That arithmetic is ours, using decimal units; it illustrates scale rather than measured consumption or guaranteed savings.

CPU costs vary substantially. Elastic's 2024 XDR white paper claims typical averages below 2% CPU and 300 MB memory. Those figures describe a different context from its current requirements table. They also show why a blanket claim that every installed agent consumes enormous CPU would be misleading. Measure the actual policy and workload, including busy periods and scan peaks.

Remove the permanent detection engine, then measure the whole system.

With no permanent detection engine on the endpoint, agentless inspection can avoid the recurring cost of keeping that engine running between scans. Active probes still consume resources; launch services, scan servers, storage and analysis also have costs. The useful measure is the footprint of the complete system across idle periods and active inspection.

Our isolated-probe approach targets that same architectural advantage: bounded inspection jobs rather than a large, continuously resident detection engine. We have not published comparable performance measurements for our implementation, so we are not claiming a measured reduction or a performance ratio.

Compare idle memory, peak scan memory, CPU-seconds per scan, scan frequency, application latency, disk I/O and central-service resources. Record detection coverage alongside them. Lower overhead is valuable only if the inspection still answers the security questions you need answered.

CrowdStrike showed what a failed security update can cost.

A widely deployed privileged component can turn one bad update into a fleet-wide problem. CrowdStrike's July 2024 incident report describes a Windows sensor content update that caused system crashes. Microsoft estimated that the update affected 8.5 million Windows devices. This was a content configuration update, not a complete agent replacement: independent packaging alone did not contain its impact. That is why we pair independent probe releases with an enforced isolation boundary. This incident demonstrates the blast radius of privileged update paths; it does not establish that every agent or Linux sensor has the same failure mode.

Small, short-lived probes can reduce persistent attack surface and make failures easier to contain. They still consume resources, parse hostile data and depend on a trustworthy execution boundary. Staged rollout, resource limits and a stop mechanism belong in either architecture.

Our approach: isolated probes, without SSH.

We run the probes via the askd protocol, rather than an SSH login or a general-purpose remote shell. Although askd can also transport SSH in other workflows, this probe workflow uses askd without SSH. The launcher authorizes a specific inspection, verifies what will execute and confines its access for the duration of that job.

• Signed, verified artifacts: approve the probe and its version before execution. Bind the authorized job to that artifact and the intended target.
• Read-only inspection: expose only the host data needed for the check. Give the probe no authority to change the inspected system.
• No network access from the probe: return bounded results through a controlled channel handled outside the sandbox.
• Self-contained binaries: avoid invoking host shell tools or loading host libraries. Package the code the probe needs in the verified artifact.
• Bounded execution: constrain time, memory, CPU, output and privileges; fail closed if isolation cannot be established.
• Auditable launches: record requester, authorization, target, artifact digest, signer, isolation policy, timestamps and outcome without recording secret values.

The design goal is no permanent EDR detection engine on the host. A trusted launch mechanism still exists and must be secured, maintained and audited. “Agentless” does not mean that nothing executes locally.

Independent teams. Independent probes. Independent releases.

A new threat should not have to wait for a whole-agent release. Our probe architecture separates a focused inspection from the endpoint stack: an independent team can build, maintain and test a probe for a particular threat, incident or environment, then submit that artifact for approval without integrating it into a monolithic detection agent.

That makes the unit of change smaller. A probe can have its own owner, test fixtures, version, signature and release schedule. Its rollout can target the machines that need the check. Updating one inspection does not require repackaging every other probe or replacing the launcher.

• Focused expertise: specialists can maintain the checks they understand, including organisation-specific threats.
• Focused testing: exercise the probe against relevant clean and malicious fixtures, malformed data and its resource limits, alongside the shared launcher contract.
• Focused distribution: approve and deliver the specific artifact needed for the job.
• Focused recovery: stop scheduling a faulty probe, revoke its approval or return to a known-good version without replacing the whole detection stack.

These are the release capabilities the architecture enables, not a claim that every publishing and rollback workflow is already production-validated. Shared interface, isolation and integration tests still matter. A broken probe can miss a threat or produce false findings, so independent release must still include review, staged rollout and monitoring.

Some resident EDR products also update detection content separately from their agent binaries. The stronger distinction is the execution boundary: a separately signed, isolated job rather than new logic interpreted inside a broadly privileged resident engine. This can shorten the path from a specialist's finding to a targeted check, without claiming that every competing vendor responds slowly.

What these boundaries do, and do not, prove.

A signature establishes provenance and integrity under a trusted signing key. It does not prove the code has no vulnerabilities. Self-contained binaries reduce dependence on potentially compromised host executables and libraries; bundled code still needs vulnerability review and updates.

The launcher is trusted in this model. This section addresses the probe’s confinement; launcher security is a separate concern. A probe cannot write to the inspected host or access the network. Its only output returns to the trusted launcher through the designated result channel. Within these enforced boundaries, even a third-party probe has no direct path to an external recipient and cannot independently exfiltrate the data it inspects.

The kernel and isolation runtime are also part of the trusted computing base. These guarantees depend on the sandbox enforcing the stated restrictions; a compromised host can distort what an inspection observes.

Using askd instead of an SSH session keeps this workflow focused on authorized probe jobs. Transport and launcher security are separate from the probe-confinement boundary described here. Their review must cover authentication, replay protection, revocation and authorization. Audit completeness and tamper resistance must be demonstrated, not inferred from having logs.

Detection and response are separate authorities.

Read-only probes collect evidence. Response controls hold separate, explicit authority to change the system. Policy determines which actions happen automatically and which require approval, with permissions scoped to the target and operation. Each response needs an audit record, verification of its effect and a recovery path where applicable.

For example, an unexpected outbound connection may be blocked by a continuous network control while an isolated probe collects evidence for investigation. Device containment or access revocation can then follow under the appropriate policy. These are workflows in the broader design; each requires its own implementation and validation.

The useful comparison is whether a design detects the threats that matter with acceptable delay, overhead and operational risk. It is not whether “agentless” wins every category.

Development and validation.

We already run probes through askd. The broader Runtime Assurance system is in development. This article examines its inspection approach; detection coverage, preventive controls and response workflows are validated separately. We will publish tested capabilities and results as those parts are established.

Validation needs to include rejected unsigned and replayed jobs, revoked signers, denied writes and network access, hostile input, resource exhaustion, cancellation, audit loss, and the detection gaps between scans. Test recovery and key rotation as well as the successful path.

Related work: our Linux isolation demonstrations and Linux for companies.