Lesson 3 of 6 · 7 min read
Membership Inference Attacks
In this lesson
TL;DR: Membership inference asks whether a given record was in the training set. Models tend to be more confident and lower-loss on their training data, so an attacker who compares a record's behaviour against what is typical can infer membership. Overfitting widens the gap. The privacy harm is that membership itself can reveal sensitive facts: being in a hospital's diagnosis model means having the condition. The principled defence is differential privacy in training; practical mitigations are regularisation, returning labels rather than full confidence scores, and keeping sensitive data out of training. For large language models, measured attacks are often weaker than for small overfit models, but verbatim memorisation is a related and real risk.
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1A clinic trains a model only on records of patients with a particular rare disease and offers it as a risk-scoring API. Why is 'was this person in the training data?' a privacy question?
Why models leak membership
Training pushes a model to fit its training examples. Unless generalisation is perfect, the model ends up slightly better on examples it has seen than on similar ones it has not: lower loss, higher confidence in the correct label. That difference is a signal.
Shokri and colleagues (2017) demonstrated the attack against machine-learning-as-a-service APIs using shadow models: train models on data from a similar distribution where you know membership, learn what members' outputs look like, and apply that classifier to the target. Later work, notably Carlini and colleagues' likelihood-ratio attack (LiRA, 2022), made attacks much stronger and argued they should be evaluated at low false-positive rates, because confidently identifying a few members matters more for privacy than average accuracy.
Target record
Was it trained on?
Model API
Returns scores
Attacker
Compares
Also in the picture
Reference behaviour
- Shadow models
Query the record
The attacker submits the target record and records the model's confidence or loss.
How LiRA works, and why the metric changed
The likelihood-ratio attack replaces one global threshold with a per-example test. The attacker trains many shadow models (256 in the paper's main experiments, 64 for ImageNet), some with the target example and some without. For that one example, this gives two distributions of the model's confidence: what it looks like when the example was a member, and when it was not. Each is fitted with a Gaussian, and the target model's confidence on the example is scored by which distribution explains it better. Some examples are naturally easy and some hard, and the per-example comparison removes that noise.
The paper's second contribution was the metric. Average accuracy or AUC rewards an attack that is slightly better than chance on everyone. Privacy harm comes from identifying a few people with high confidence, so the paper reports the true-positive rate at a very low false-positive rate, such as 0.1% or 0.001%. On that measure, the older loss-threshold attack achieved 0% true positives at 0.1% false positives, while LiRA identified between 0.1% and 10% of members at 0.001% false positives, depending on the dataset: about ten times more powerful at the low end.
Worked example: why accuracy hides the harm
An audit uses 10,000 training members and 10,000 non-members. The numbers are illustrative.
| Attack A | Attack B | |
|---|---|---|
| Balanced accuracy | 60% | 55% |
| True-positive rate at 0.1% false positives | 0.05% | 3% |
| Members correctly identified at that threshold | 5 | 300 |
| Non-members wrongly flagged | 10 | 10 |
| Share of flagged records that really are members | 33% | 97% |
Attack A looks better by accuracy, but it cannot confidently identify anyone. Attack B identifies 300 people with 97% precision. If membership reveals that someone was in, say, a clinical study, B is the privacy problem.
What makes it worse
- Overfitting: small datasets, many training epochs, very large models relative to data.
- Outliers and duplicates: unusual or repeated records are memorised more and are easier to detect.
- Rich outputs: full probability vectors or log-probabilities give more signal than labels.
- Repeated queries: the attacker can average over many queries or augmentations.
Large language models
For large language models trained on huge corpora for few epochs, studies have found that many published membership inference methods perform close to chance in realistic settings (for example Duan et al., 2024), partly because members and non-members are hard to separate cleanly. That does not make LLMs private. Verbatim memorisation is the more pressing risk: models can reproduce rare or repeated training text, including personal data, when prompted, which is training data extraction. Fine-tuned models trained on small, sensitive datasets are closer to the classic setting and more exposed.
The distribution-shift trap
Many early papers reported strong membership inference against large language models. Duan and colleagues (2024) tested attacks on models from 160 million to 12 billion parameters trained on the Pile and found they barely beat random guessing. Two reasons: huge datasets seen for about one epoch leave little per-example signal, and the boundary between "member" and "non-member" text is fuzzy when near-duplicates are everywhere. Several apparent successes were explained by distribution shift: the non-member test set was drawn from a later time period, so the attack was detecting newer text rather than membership. An honest audit draws members and non-members from the same domain, time range and preprocessing, and reports a random-guess baseline next to the attack.
Defences
| Defence | How it helps | Cost |
|---|---|---|
| Differential privacy (DP-SGD) | Mathematically limits any one record's influence, bounding membership inference | Accuracy loss, tuning effort |
| Regularisation, early stopping | Narrows the gap between training and unseen data | Partial protection only |
| Label-only or rounded outputs | Removes the confidence signal attackers rely on | Some product features lose information |
| Data minimisation | Sensitive records never in training | Requires deciding what not to collect |
| Deduplication | Fewer repeated records to memorise | Pipeline work |
Measure risk empirically too: run membership inference audits against your own model before release, evaluated at low false-positive rates.
Differential privacy in practice
DP-SGD (Abadi and colleagues, 2016) is the standard way to train with differential privacy. Each training step clips every example's gradient to a maximum size, so no single record can move the model much, then adds Gaussian noise to the sum. A privacy accountant tracks how the guarantee degrades over many steps.
The guarantee is stated as (ε, δ). Informally, an attacker's ability to tell whether any one record was used is bounded: at a false-positive rate α, the true-positive rate can be at most about e^ε × α + δ.
| ε | e^ε | Maximum true-positive rate at 0.1% false positives |
|---|---|---|
| 0.5 | 1.65 | about 0.17% |
| 1 | 2.72 | about 0.27% |
| 2 | 7.39 | about 0.74% |
| 8 | 2,981 | no meaningful bound at this threshold |
Large ε values are common in practice because accuracy suffers at small ones. Abadi and colleagues reported 90%, 95% and 97% accuracy on MNIST at ε of 0.5, 2 and 8 (δ = 10⁻⁵), against 98.3% without privacy; on CIFAR-10 they reported 67%, 70% and 73% at ε of 2, 4 and 8, against about 80% without. The theoretical worst case at ε = 8 is weak, though measured attacks usually do far worse than the worst case.
Three further points separate experienced answers:
- Audit the implementation. Bugs in clipping, sampling or accounting break guarantees silently. Researchers audit DP training by inserting crafted canary records and measuring how detectable they are, which gives an empirical lower bound on the real ε.
- ε is per record. A person who appears in many records, or a record duplicated many times, is protected less. Deduplicate and consider user-level accounting.
- DP is not legal compliance on its own. The European Data Protection Board's Opinion 28/2024 says whether a model is anonymous is assessed case by case, looking at how likely extraction and inference are. DP is strong evidence for that assessment, not a substitute for it.
Also note a trade-off from the evasion literature: Song, Shokri and Mittal (2019) found that adversarial training increased membership inference risk. Hardening a model against evasion can make it leak more about its training data.
Accuracy on mismatched sets
Non-members from a later year
Report balanced accuracy
rewards weak signals
"Attack works" or "model is private"
Outcome, unsafe: Either answer may be wrong
The attack may detect the date, and accuracy hides confident hits.
Matched sets, low false-positive rates
Members and non-members matched
TPR at 0.1% and 0.001% FPR
plus a random baseline
Canaries measure memorisation
Outcome, safe: A result you can act on
Shows how many people can be identified with confidence.
Common mistakes
Non-members from a different period and an accuracy metric can both mislead.
Sample a batch
Random subset
Per-example gradients
One per record
Clip each
Bounds influence
Add noise
Gaussian, to the sum
Privacy accountant
Tracks epsilon
Limit each record
Clipping each example's gradient caps how much any single record can change the model.
Misconceptions interviewers listen for
- "Accuracy or AUC is the right metric." Use true-positive rate at low false-positive rates, ideally on a log-scale ROC curve.
- "Membership inference works well on large pretrained LLMs." Measured attacks are mostly near chance there; check for distribution shift. Fine-tunes on small sensitive sets are a different story.
- "Differential privacy makes us GDPR compliant." It strengthens an anonymity assessment; it does not replace one.
- "Our configuration says ε = 8, so we are private." Audit the implementation, and remember ε is per record and weak at that size.
- "Robustness and privacy point the same way." Adversarial training has been measured to increase membership leakage.
What if · interview follow-ups
Hold your answer as the constraints change
Your company is fine-tuning a model on clinical notes from one hospital network to draft discharge summaries. The interviewer probes membership risk, measurement and differential privacy.
Start here
Why does membership itself matter here, even if no note is reproduced?
What does being in the training set reveal?
If the training set is notes from patients treated by this network, showing that a person's record was used reveals that they were a patient, and possibly their condition if the dataset is specialised. Membership inference exploits the model's slightly higher confidence on training examples, which is strongest with small datasets, many epochs and rare records, exactly the profile of a clinical fine-tune.
Carry it forwardWhen membership is sensitive, inference is a disclosure without any text leaking.
Weak answerSaying there is no risk unless the model repeats notes verbatim.
Constraint changes
How would you run an honest membership inference audit?
Populations, metric, baseline.
Draw members and non-members from the same period, source and preprocessing so the attack cannot detect distribution shift; use a strong attack such as LiRA with shadow models; report true-positive rate at 0.1% and 0.001% false positives on a log-scale ROC with a random baseline; and plant canary records to measure memorisation directly.
Carry it forwardMatched populations and low false-positive rates make an audit meaningful.
Weak answerReporting balanced accuracy on sets from different years.
Constraint changes
How would you choose epsilon for differentially private fine-tuning?
What does epsilon bound, and what does it cost?
Explain epsilon as a bound on how much any record can change the odds an attacker sees: at epsilon 1, true positives at 0.1% false positives are capped near 0.27%, while at epsilon 8 the worst-case bound is meaningless. Plot task quality against epsilon on our data, deduplicate patients first because epsilon is per record, then audit the trained model empirically and choose with the privacy officer.
Carry it forwardChoose epsilon from a utility curve and an empirical audit, not a default.
Weak answerPicking epsilon 8 because a paper used it.
Constraint changes
The model is updated with new notes. How do you know membership risk did not increase?
Same suite, both versions, sliced.
Insert canaries before each training run, run the same membership and extraction suite on both versions, and slice results by record rarity and duplication. Treat a significant increase in the most sensitive slices as a release blocker or rollback trigger, with the comparison and sample sizes recorded.
Carry it forwardRegression-test privacy like any other release property.
Weak answerAssuming the same training recipe gives the same risk.
Constraint changes
Would a successful attack on this model count as a personal data breach?
What would engineering contribute to that decision?
It may be, because it can disclose special-category health information about identifiable people. The legal assessment belongs to the DPO under GDPR breach criteria and the EDPB's anonymity test. Engineering supplies the achievable true-positive rate at low false-positive rates, how many people could be identified, which records are most exposed, and what mitigations are in place.
Carry it forwardTranslate attack metrics into how many people could be identified, then let legal decide.
Weak answerTelling the DPO that differential privacy settles the question.
Now defend it
As the defender, what would you put in place before releasing this model?
Deduplicated training data with rare-record review, DP-SGD at an epsilon chosen from a utility curve, an empirical audit with canaries at low false-positive rates, label-only or truncated outputs where the product allows, access controls and query monitoring on the model, and a re-audit gate for every retrain.
How this shows up in interviews
"What is membership inference, and why does overfitting raise the risk?" is a standard ML privacy question. Strong answers explain the train/test behaviour gap, give the shadow-model idea, explain why membership is sensitive with a concrete example, and present differential privacy as the principled fix with practical mitigations alongside. Mentioning that LLM membership inference is often weak while memorisation is strong shows current knowledge.
Say it in 30 seconds: "Membership inference asks whether a specific record was in the training data. Models are more confident on what they were trained on, and overfitting widens that gap, so comparing a record's confidence or loss against shadow-model baselines reveals membership. That matters when membership itself is sensitive, like a disease-specific dataset. Differential privacy bounds it; regularisation, label-only outputs, deduplication and minimisation help. For big LLMs measured MIAs are often weak, but verbatim memorisation is a real risk."
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1Why should membership inference audits report true positive rate at a low false positive rate rather than overall accuracy?
2A team fine-tunes an LLM on 2,000 internal HR case notes. Which risk would you test first, and why?
3Why does LiRA report true-positive rate at very low false-positive rates instead of accuracy?
4What is the distribution-shift trap in LLM membership inference studies?