You ship an exclusion to a live detection rule — how do you find out later what it hid?

## The request A detection on cross-process memory reads keeps firing on a developer-laptop fleet, and the cause is settled: a named engineer profiles services they own, with a tool your team has no authority to remove. You have accepted that an exception is warranted. What arrives next is a request in ordinary English — "just exclude the profiler on the dev fleet" — and your job is to turn it into a change that stops the noise without removing your ability to find out, later, what it stopped. That last clause is the whole difficulty, because of one property of exclusions that is easy to state and easy to forget. ## A suppressed match is silent by construction Noise announces itself. Every false alert costs an analyst time, so a noisy rule generates pressure until somebody fixes it. An exclusion has the opposite feedback: when it suppresses something, nothing happens. No alert, no ticket, no complaint, no queue growth. Nothing in the system tells you that the exception is now covering an intruder rather than a profiler, and no moment arrives at which you are asked to reconsider. So the cost has to be made visible deliberately, at the time you write the change, through two decisions: **where** the exclusion is enforced, and **what you write down** about it. ## Where you enforce it decides what survives The same logical exception can be implemented at four different points, and they are not equivalent. | Enforced at | The alert | The record | | --- | --- | --- | | The sensor or agent's collection filter | never raised | never generated | | The forwarder or ingest pipeline | never raised | dropped before indexing | | The detection rule's own condition | never raised | indexed and searchable | | The alerting layer's suppression list | not delivered | indexed, and usually the match too | The bottom two leave you evidence; the top two do not. That is the difference between a rule you tuned and a hole you cannot examine — and it is why a request that sounds identical to everyone ("stop this alert firing") has radically different consequences depending on who implements it. Someone under pressure to reduce ingest cost reaches for the collection filter, because it saves money as well as noise. From a detection standpoint it is the most expensive option on the list: it removes visibility from every rule over that data, present and future, not only from the rule that was noisy, and it removes it for hunting too. Prefer the rule's own condition. It keeps the exception next to the logic it modifies, it leaves the underlying telemetry intact, and it is undone by editing one line rather than by re-deploying an agent policy and waiting for data to start arriving again. ## Write it so a stranger can bound the gap The second decision is documentary and it is cheap. Ship the exception as a change in version control, so it carries a diff, an author and a date, and record alongside it the scope (which condition, which assets), the owner, and the alert that justified it. The date is the part people leave out and the part that gets asked for. When something goes wrong on that fleet, the question is not philosophical — it is "what were we not alerting on, on those hosts, between 4 March and today?" An exception with a start date and an explicit scope answers that in one sentence. An exception typed by hand into a console, with no history behind it, cannot be dated at all, and the honest answer becomes "we do not know" — which is the answer that turns a bounded incident into an open-ended one. ## Finding out what it hid Together those two decisions give you a procedure rather than a hope. An intrusion is confirmed on a host in the excluded population. You take the rule's logic with the exception removed, and you run it over the retained telemetry for the exception's lifetime. Whatever it surfaces is what the exception was swallowing; a clean result narrows the intruder's likely path and is worth recording in writing either way. The limit is retention, and it is a hard one. If telemetry is kept for thirty days and the exception has been live for eight months, seven of those months cannot be examined by anyone, ever. That is not a reason to skip the check. It is a reason to state the un-searchable window as an explicit assumption in the incident's scope rather than glossing over it, and a reason to prefer exceptions whose lifetime is shorter than the window over which you could audit them. ## What none of this buys you Auditability is not safety. A dated, rule-level, well-scoped exception still removes coverage for as long as it lives, and reconstructing what it hid is something you do after the damage. What it buys is the ability to answer the question honestly and to bound the incident — which, when the alternative is a shrug, is a great deal.