Agent Blind Spots

## The question behind the question Every endpoint detection story assumes a sensor. Interviewers ask this because analysts routinely write "no EDR detections on the host" into a case note as if it were a negative finding, when for a whole slice of the estate it is not a finding at all. Knowing which hosts can never carry an agent, and saying so out loud during triage, is a basic competence. ## The classes that cannot take an agent **Appliances.** Storage arrays, load balancers, firewalls, VPN concentrators, backup appliances and mail gateways run a vendor-controlled operating system. There is often no package manager, no shell for you, and a support contract that says third-party software voids it. These devices hold administrative credentials, sit in privileged network positions and are attractive targets, and they are exactly where an agent cannot go. **Hypervisors.** ESXi is not a general-purpose Linux host: third-party code arrives as signed VIB packages, and few endpoint vendors publish one. An intruder with hypervisor access can read or copy guest disks, snapshot memory, or shut down and encrypt virtual machines without touching a single agented guest OS. What you do get is the platform's own record: forwarded ESXi syslog, `/var/log/hostd.log`, `/var/log/auth.log`, `/var/log/shell.log`, and vCenter task-and-event entries showing SSH or the ESXi Shell being enabled, a service starting, or a user logging in. **Embedded, OT and legacy.** Printers, cameras, building controls, industrial controllers and out-of-support operating systems either have no agent build or cannot survive one. "Unsupported platform" is a coverage answer nobody enjoys giving, but the honest one. **Hosts you do not own.** A contractor's laptop, a partner's jump box, an employee's personal device under a BYOD arrangement. The obstacle here is not technical but legal and contractual, and it does not get solved by trying harder. **Containers, partially.** A node-level sensor sees processes inside containers, because containers share the node kernel. What is unreliable is attribution: mapping a process to the right pod, image and namespace depends on the sensor resolving cgroup and namespace metadata, and short-lived pods often exit before anyone looks. Kubernetes control-plane audit records are a separate source, owned elsewhere. ## Present but not seeing An agent showing green in the console is not the same as an agent collecting. A Linux sensor on an unsupported kernel may fall back to a degraded mode with no process telemetry, a macOS sensor without approved system extensions or full-disk access sees far less than you expect, and a policy can assign a host to a monitor-only or detect-only profile. "Installed" is a fact about deployment, not about the event stream. ## What absence actually means Get the direction right, because this is the sentence interviewers listen for. An EDR alert proves that a rule or model in that product fired on data it received. It does not prove something malicious happened. The absence of an alert proves less still: it is consistent with a quiet host, with an agent that never saw the behaviour, with a behaviour nobody wrote a detection for, and, on an unagented host, with an intrusion that ran for months. On the unagented host, the absence is not even evidence of a gap in detection logic; there was never any data. ## What you use instead For each unagented class, name the compensating source before you need it: | Host class | What can still see it | | --- | --- | | Appliance | Its own forwarded syslog, management-interface authentication records, flow records to and from its management VLAN | | Hypervisor | Forwarded ESXi syslog and shell/auth logs, vCenter events, flow at the management network | | BYOD / contractor | VPN and NAC records, identity provider sign-ins, proxy and DNS, the SaaS audit trails it touched | | Container workload | Node-level sensor telemetry, service-mesh or ingress logs, the application's own logs | A flow record proves bytes moved between two addresses and ports and carries no payload, so it can establish contact and volume and never content. A DNS query log shows the name asked for, not what the process did with the answer. Those limits are the point: you are reconstructing, not observing. ## The outcome you should expect to describe The realistic ending for this class of host is that the activity is never found there first. An intruder living on a hypervisor or an appliance is typically discovered only when they reach back onto a monitored endpoint, and the earlier residence is reconstructed afterwards from forwarded platform logs and flow. Whether that reconstruction is possible at all was decided months earlier, by whether anyone made the device forward its logs.