The sensitive answer was dropped from the model's features - does that stop an attacker inferring it?

## The reply that sounds decisive and is not When an attribute-inference finding lands, the most common push-back from an owner is: *we dropped that column from the features, so the model cannot leak it*. It sounds like an airtight structural argument. It is not, and seeing why is the point of this leaf. The adversary never looked at the feature list. They submitted applications and read back prices. Their evidence is the **output**, and the question that matters is whether the output carries information about the field - which is a property of what the model fitted, not of which columns appear in a schema. That the retained features can stand in for a removed one is assumed here rather than re-argued; it is thoroughly established territory in ordinary modelling practice. What is specific to a security review is what an *adversary* can do with it, and how the two variants differ. ## Variant one: the field is still an input This is the case most "we removed it" claims turn out to be, once someone reads the request payload rather than the design document. The attacker holds every other field, so they submit the application once per candidate value and compare the returned premium against the figure that person was quoted. The match names the declared value. This is **recovery**: a specific value attributed to a specific person, and it is decisive. ## Variant two: the field genuinely is not an input Now there is nothing to submit for it, so exact-match recovery is unavailable. But the model was fitted on data where the retained fields co-varied with the dropped one, so the returned premium still shifts with what the dropped answer would have been. The attacker submits the record they hold and reads a price that is informative about the missing field. What they get is different in kind: | Variant | What the attacker submits | What comes back | | --- | --- | --- | | Field is an input | The record, once per candidate | The declared value, by matching the observed price | | Field is not an input | The record as held | An estimate of the field, driven by correlation | The second is weaker and, crucially, **not automatically a disclosure by the model at all**. Anyone holding the same auxiliary attributes could fit their own predictor of the sensitive field from public or purchased data and get an estimate without touching the endpoint. So the model contributes exactly its **lift over that baseline** - how much better the attacker does with the endpoint than without it. That number is measurable, and it is what settles the argument. ## Why the direction of the claim matters here Get the direction wrong and you encode the misconception: - **Removing a column does not remove what the model encodes.** It removes one channel - direct candidate submission - and leaves the output channel. - **A correlation-driven estimate is not a recovered value.** Reporting an estimate as "the model disclosed her answer" overstates the finding as badly as the reviewer's reply understates it. - **Lift over the auxiliary-only baseline is the model's contribution.** If the endpoint adds nothing over what the purchased record already implies, the disclosure is attributable to the data holding, not the model - and saying so honestly is what makes the rest of the report credible. ## What removal does buy It is not worthless. Removing the field: - eliminates the exact-match variant, which is the decisive one; - removes the field from request logs and from anything downstream that stores payloads; - degrades the attacker's result from a value to an estimate whose strength is now an empirical question rather than a certainty. What it cannot do is make the question go away, because the question was never about the schema. ## How to answer this in a room Say three things, in order. First, the attacker reads outputs, so the feature list is not responsive. Second, name the two variants and which one is left after removal. Third, propose the measurement - the attack's success against a baseline predictor built from the auxiliary attributes alone - and note that whichever way it comes out, the answer is now a number both sides can act on rather than a design claim.