0.5 What It Cannot Do

Most courses put the limits at the end, as caveats. This one puts them here, because every limit below produces a result that looks like an answer, and an analyst who meets them for the first time in the field meets them as a wrong finding rather than as a boundary.

The machines it never reaches

The deployment's coverage is the population it reaches, which is not the population that exists.

Machines are rebuilt without the agent. New ones are provisioned by a process nobody updated. Laptops go into drawers. A build change breaks the installation and nothing announces it. Contractors, acquired companies and personal devices were never in scope in the first place.

None of that produces an alert, and the console's client count is reassuring precisely because it counts what enrolled rather than what exists. A hunt reaching every client your server knows about still says nothing about the population the agent never touched, and that population is disproportionately where a foothold survives unnoticed, because it is the part of the estate nobody is looking at.

The course's answer is a comparison against a source of truth outside the platform, run as a recurring task rather than a one-off. It is unglamorous and it is the difference between a coverage figure and a coverage claim.

Worth noting that the comparison runs in both directions. Machines in your inventory with no agent are the gap everybody expects. Machines with an agent and no inventory entry are the more interesting finding, since an endpoint your organization does not know it owns is a question for somebody outside security and occasionally the start of one for you.

Clients enrolled          812   <- the number the console shows
Machines you own            ?   <- lives in an inventory, not here
#
The gap between those two rows is invisible from inside the
platform, and it is the population a foothold survives in.

The evidence that has already gone

The agent reads the machine as it is now. That has two edges.

Volatile state has a deadline. Process memory, network connections, logged-on sessions: each exists until the thing holding it ends. A connection list is a snapshot of open sockets at the instant you asked, so a process beaconing every five minutes is invisible between beacons, and a single collection proves nothing about its absence.

Durable evidence has a horizon. Logs rotate, caches evict, databases prune. Each artifact keeps a different amount and a busy machine ages evidence out faster than a quiet one, which means two hosts can answer the same question differently for reasons that have nothing to do with the intrusion.

The second is the more dangerous because it is invisible. A host whose evidence begins after the intrusion started cannot be excluded as the origin, and its first observation is not a fact about the incident but a fact about its log sizes. Module 6 turns collecting that horizon alongside the finding into a habit, and the reason it needs a whole section is that nothing in the interface suggests it matters.

The first has an answer and the second mostly does not. Volatile evidence can be caught by collecting early, or recorded continuously by the monitoring Module 7 covers, so the deadline is one you can beat. A horizon that already passed before you arrived cannot be recovered by any technique, which makes it a limit to state rather than a problem to solve.

The questions the endpoint cannot answer

An endpoint knows what it did. It does not know what crossed the perimeter, what a cloud service recorded, or what another organization's systems logged.

The most consequential instance is data movement. Whether a file left the environment is a question about transmission, which lives in network, proxy and service records rather than on the host. An endpoint can show that a file was read, that a process held a connection, and that bytes were sent; establishing what those bytes were is somebody else's evidence.

The same boundary applies to anything about identity beyond the machine. What an account could reach, whether it was used elsewhere, whether the credential appears in a breach corpus: all of that lives in a directory or a service, and the endpoint contributes one piece of it. Module 6 treats the account as the pivot with the most reach precisely because answering it properly means leaving this tool.

Reports routinely assert otherwise, which is why Module 6 names it among the four claims that need most care. The supportable version says what was checked, over what period, on which hosts, and where the remaining question has to be answered.

The useful move when you hit this boundary is to state it and hand the question on. "The endpoint cannot establish whether the file was transmitted; that requires the proxy records for this host between these times" is a finding. Continuing to collect endpoint artifacts hoping one contains network payload is not.

What it is second best at

Two situations where this tool is capable and something else is correct.

A single machine that is the whole case. Live collection is defensible and routine, and where the standard being applied is a verified bit-for-bit copy of a seized drive, an image is what the standard asks for. If one laptop is the matter, image it.

Anything about deleted content. The parts of a disk holding a removed file are not what a live agent reads. Where the question is what was in a document that was deleted last week, the answer lives in a disk image and a different discipline. The tool can frequently tell you that a file existed and when, from metadata and references elsewhere on the system, which is a different and often sufficient claim.

Neither is a failing. Knowing when to reach past a capable tool is what stops it becoming a habit, and a responder who images the one laptop that matters rather than collecting from it is making a better decision, not a more cautious one.

The two are also not exclusive. Collecting the volatile state from a running machine and then imaging it captures evidence the image cannot contain, and the order matters for the reason Module 4 gives: the machine has to be running for the first and off for the second.

The assumptions the interface lets you keep

This is the category the course spends most of its time on, because it is the one that produces confident wrong answers rather than obvious gaps.

The platform is deliberately tolerant. It does not stop you asking an expensive question. It does not warn you that a filter matched nothing. It does not distinguish an empty result from an impossible one, a canceled collection from a complete one in the rows themselves, or a skipped source from a source that ran and found nothing.

That tolerance is what makes it flexible enough to answer questions nobody anticipated, and the price is that judgment another tool would enforce is left to you. Four specific consequences recur:

A canceled collection returns a prefix that looks like a result, so the last row reads as the last event.

A hunt has a numerator and no denominator, so absence among responders gets reported as absence across the estate.

A misspelled column is never an error, so a query runs perfectly and matches nothing, and fleet-wide silence is enormously convincing.

An acting expression above a filter runs on every row the source produced, so the table shows what you expected while the filestore holds everything.

None of those are bugs, and none are hypothetical. Each has its own section, and each is the reason this course teaches reasoning alongside the interface rather than after it.

What they have in common is worth stating once. Every one produces a result that is internally consistent, plausibly sized, and wrong in a way the console cannot show you. That is a harder failure to catch than an error message, and it is why the course keeps returning to the same defensive habit: form an expectation before you run something, and treat a result that meets your expectation as weak evidence rather than as confirmation.

Why this section is early

Reading limits first changes how the rest of the course lands. Every capability arrives already attached to the thing it cannot do, which is how they arrive in practice. The alternative, learning the capability and meeting its limit during an incident, is how the wrong findings in this section's opening get made.

It also sets the standard for what a finding is. The recurring instruction across seven modules is to say what the evidence supports and what it does not, in the same sentence, because a claim whose limits are visible survives being questioned and one whose limits are implied does not.

That standard is not caution for its own sake. A finding stated with its population and its coverage is more useful to whoever reads it, because they learn what they can rely on at the same moment they learn the conclusion. Vague confidence forces the reader to either accept it or redo the work, and on a serious matter they will do the second.