A sanctioned 40 GB partner transfer fired an exfiltration rule. Why is closing it 'false positive' wrong?

## What the record establishes, and what it does not The audit entry is unambiguous about mechanics: a named account in the records team copied 812 files totalling roughly 40 GB to an external tenant, using the client the organisation itself deploys and sanctions, and a content classifier matched the files as case material. Every field the rule keyed on is populated correctly and means what the rule's author thought it meant. The record is equally clear about what it cannot tell you: **whether anyone was allowed to do this**. Authorisation is not a field in a SaaS audit trail. It lives in a contract, a ticket, an approval from a records manager. The telemetry can only establish that the action happened. So the case splits cleanly. *Did the rule read the data correctly?* Yes. *Was the activity permitted?* Also yes, once you check the contract. That combination has exactly one honest code: **benign true positive**. ## Why the wrong label is not a harmless shorthand A detection is not a piece of software anyone watches. It is a rule that emits alerts into a queue, and the dispositions written on those alerts are the entire record of how it performs. Everything downstream - the review that decides whether the rule survives, the argument about whether the SOC is drowning, the engineer's decision about which rule to fix first - reads those codes. Write *false positive* on a correct firing and you have made three false statements at once: 1. **About the rule.** Its history now says it misreads data. It does not. 2. **About the estate.** Someone reading the closures learns nothing about the fact that this organisation legitimately moves large volumes of case files to partners - which is a real, useful fact about the environment. 3. **About the fix.** The obvious remedy for a false positive is to change the logic: exclude the sanctioned sync client, drop the classifier condition, raise the byte threshold above 40 GB. Each of those carves a hole exactly the shape of the authorised behaviour - and an adversary who uses the sanctioned client, or stays under the new threshold, now walks through it silently. That third point is the whole danger. The mislabel does not merely misfile a case; it argues for a change that removes coverage, and it argues for it with evidence that looks legitimate. ## The counter-error The opposite mistake is to reach for *benign* whenever an explanation exists. Benign is a verified claim. To hold it you need the authorisation named and confirmed by someone who can grant it - the contract reference, the records-team manager, the destination tenant matching the partner in that contract. "The user said it was fine" is a lead. An intruder operating a legitimate account through the sanctioned client produces the same story, and the story is cheap. If the queue is deep and the authorisation is unverified, the case is open, not benign. ## How to state the verdict A well-formed benign closure is short and checkable: the rule fired correctly on a bulk transfer to `partner-legal.example`; the transfer matches contract reference C-2291; confirmed with the records-team manager; destination tenant matches the contract; disposition **benign true positive**. Every clause is something a later reader - another analyst, an auditor - can re-test. ## Volume is a different argument If that transfer happens weekly, the rule is going to keep firing, and analysts will keep spending real time on it. That is a genuine problem, but it is a **scoping** problem - the environment does the behaviour legitimately - and it is answered by recording the expected activity with an owner and an expiry, not by declaring the rule wrong. Keeping those two arguments apart is what makes the disposition data worth anything: *is the rule accurate?* and *is the rule well scoped to this estate?* are separate questions with separate remedies, and the false-positive code answers only the first.