Cumulative Disclosure Accounting
Keep a session-scoped ledger of what a data agent has already disclosed and evaluate each new query against that accumulated record, so a sequence of individually-permitted results cannot jointly re-identify protected rows.
Problem
The gate decides one call at a time and keeps no record of what it has already released, so it cannot see the join. Four aggregates that are each computed over a large enough group can intersect on a group of one, and the person the policy was written to protect is disclosed by arithmetic the gate never performed. Classical database-privacy work names this a composition attack and shows experimentally that it breaches privacy in practice against a large class of published anonymisation techniques, k-anonymity and several of its variants among them. A layered study of data agents finds the same hole in the policy layer of current systems, which approve each query in isolation and never track cumulative disclosure across the session.
Solution
Make the policy decision stateful. Open an account when a principal starts a session, and record in a ledger every result the gate lets out: which table and attributes it touched, which population it was computed over, and what privacy cost it carried. When the next query arrives, the gate does not ask whether this query alone is permitted; it asks what the proposed result would reveal once joined with everything the ledger already holds. Two mechanisms answer that question. A composition check tests whether the new result intersected with prior ones narrows any protected group below the declared minimum, and refuses or coarsens the query when it does. A privacy budget prices each query in a randomised mechanism whose composition bound is provable, subtracts the price from the session's remaining allowance, and stops when the allowance runs out. Every disclosure channel is metered, not only direct table reads — tool results, memory writes, and messages passed to another agent all spend from the same account. Exhaustion is surfaced as an exhausted account escalated to the data owner, never as a quietly truncated answer, and the ledger is keyed to the principal so that opening a fresh session does not refill it.
When to use
- An agent issues many reads against the same sensitive dataset within one task or session.
- Results are aggregates or redacted extracts that are individually within policy but can be joined by whoever receives them.
- A data owner needs to state how much has been disclosed to a principal, not only that each release was permitted.
- The dataset covers a population containing groups small enough to be re-identified from a handful of slices.
Open the full interactive page →
Diagram, neighbourhood map, code examples, related patterns and full provenance.