Your attribute-inference test recovered a health answer for 3 of 5 subjects - how do you report severity?

## The number is the least of it "Recovered for 3 of 5 subjects" is a hit rate with no denominatorless meaning. Four things have to sit beside it before anyone can act on it, and a red-teamer who omits them will either be dismissed as alarmist or - worse - be believed and cause the wrong fix. ## 1. The precondition, stated first For each subject the test required: - a **near-complete application** for a specific identified person, correctly linked; - typically the **premium that person was actually quoted**, to match candidates against; - the ability to submit applications to the endpoint. The first two came from a purchased broker file, not from the model. So the honest headline is: *an adversary already holding a linked broker record for a person, plus that person's quoted price, converts a handful of queries into one sensitive declared field.* Severity then tracks **who can satisfy that precondition** - brokers, insiders, anyone with a prior breach of similar data - which is a scoping question the business can actually answer. Burying the precondition in an appendix produces a report that reads as *the endpoint leaks health data*, and invites a fix aimed at the wrong half of the attack. ## 2. The baseline, without which the number means nothing The attacker already held most of the record. Some of what they "recovered" may be predictable from that record alone, with no endpoint involved at all. So the report needs a second row: **what does a predictor fitted only on the auxiliary attributes say about the same field for the same subjects?** - If the baseline gets 2 of 5 and the attack gets 3 of 5, the endpoint's contribution is thin, and the exposure is largely a fact about purchasable data. - If the baseline gets 0 of 5 and the attack gets 3 of 5, the endpoint is doing the work and the finding is squarely about the model. Without that comparison the report attributes the data holding's power to the model. That is the single most common way this class of finding is overstated, and a model owner who spots it will discount everything else in the report. ## 3. The scope of the payoff Say exactly what an attacker walks away with: **one field, for one identified person, per auxiliary record they hold**. Not a class prototype, not a bulk dump, not a membership bit. That framing is what lets a privacy or legal reader reason about it, and it also caps the claim honestly - this does not scale beyond the number of linked records the adversary can buy. ## 4. The uncertainty and the failures Five subjects gives a wide interval; 3 of 5 and 2 of 5 are not distinguishable at that sample size, and the report should say so rather than implying precision. The two failures are also evidence, not noise: check whether the returned premium simply does not move much with that declaration for those profiles, or whether several candidate values produced the same figure. A field the output barely responds to is not recoverable at any query budget, and saying which profiles behaved that way is more useful than the hit rate. ## What a defensible finding looks like A finding that carries: precondition, baseline lift, per-subject payoff, query cost, sample size and the observed failure mode is one an owner can price and act on. A finding that carries only "3 of 5" is a number that will be argued about instead of fixed. One more discipline: resist reporting the *worst plausible* reading. If the lift over baseline turns out to be marginal, say so in the same sentence as the hit rate. Credibility on this class of finding is spent once.