Protected fact from allowed output
An inference attack derives a fact that policy intends to protect from outputs the attacker is allowed to observe. The attacker can combine query results, totals, counts, model predictions, error behavior, timing, or external data. The system can enforce every direct access check and still disclose the fact.
Inference types
Membership inference asks whether a person's record was in a dataset. Attribute inference learns a sensitive property from other features. Reconstruction recovers individual-level records from aggregates. Differencing compares overlapping queries. Model extraction and confidence outputs can reveal training or decision information.
State target fact, observer, auxiliary knowledge, allowed queries, repetitions, and confidence needed for harm.
Controls
Minimize data and output precision. Enforce query-set size and overlapping-query policy. Limit repeated adaptive queries. Use aggregation, suppression, controlled access, and differential privacy where its assumptions and implementation fit. Review model outputs, confidence, explanations, and logs.
Track a privacy budget or cumulative release state when the method requires it. Coordinate across endpoints and time so one user cannot reset limits through another account or dataset.
Failure and residual risk
Fixed minimum counts can fail through differencing. Adding unmeasured noise can be averaged out. Access limits can be bypassed by colluding accounts or cached releases. Differential privacy can fail through wrong adjacency, clipping, accounting, random generation, or post-processing that uses private data again.
Utility and privacy are coupled. Suppressing one output can move users to less governed raw exports.
Pomerium boundary
Pomerium can decide which identities reach a query or analytics route. It does not understand application query overlap, model outputs, group sizes, privacy budgets, or derived facts. The upstream owns inference analysis and output controls even when every requester is authenticated.
Evaluation checklist
- What protected membership, attribute, relationship, or record can be inferred from allowed outputs?
- Which external data, repeated queries, overlapping groups, accounts, and time windows does the observer control?
- Can noise, thresholds, limits, or account boundaries be averaged, differenced, reset, or combined?
- Does the privacy mechanism have explicit adjacency, contribution bounds, accounting, and implementation tests?
- Will the control preserve enough useful access to avoid an unmanaged raw-data workaround?
