MCP database aggregate disclosure controls: when a count still reveals too much

A count can reveal a person.

An AI database tool may block names, emails, and row-level exports yet still answer: “one employee in this office used the benefit,” “two customers in this segment are overdue,” or “revenue fell by exactly one large contract.” The result is aggregated, but the group is small enough to identify or infer the underlying record.

Secure MCP database access therefore needs aggregate disclosure controls, not only column redaction and read-only credentials.

Aggregation changes shape, not sensitivity

Group-by queries can expose protected facts through small groups, unique combinations, extreme values, or repeated comparisons. A user may ask several individually permitted questions and subtract the answers to isolate one record.

Example: the tool returns a department total. The user asks again excluding one known employee. The difference reveals that employee's value. No row was returned, but row-level information escaped.

Define an approved release policy

Every aggregate tool should know:

• which metrics and dimensions are approved;
• which identities and purposes may request them;
• the minimum group size for each sensitivity class;
• which filters and combinations are prohibited;
• how time range and geography affect risk;
• how repeated and overlapping queries are handled;
• what evidence is recorded for review.

The model should select among approved operations. It should not construct arbitrary dimensions and decide for itself whether the result is safe.

Enforce a minimum group size

Suppress groups below an approved threshold before results enter model context. Apply the rule after all filters and joins, using the relevant protected population rather than a convenient row count.

A threshold is contextual, not universal. A workforce metric, medical attribute, customer payment status, and anonymous product event may need different treatment. Document the policy version with each result.

Use complementary suppression

Suppressing only the smallest cell may not help if totals reveal it. If a table shows the grand total and every other category, the hidden category can be calculated by subtraction.

Complementary suppression hides additional cells or removes the total so the protected value cannot be reconstructed. The result contract should state that suppression occurred without revealing the suppressed value.

Control differencing across queries

Single-query validation cannot see a sequence of overlapping requests. Record a privacy-relevant query fingerprint: requester, purpose, metric, dimensions, filters, time window, policy version, and released result shape.

Then detect high-risk patterns such as:

• the same aggregate with one individual added or removed;
• successively narrower geography or time windows;
• many dimensions that create near-unique groups;
• repeated queries designed to discover a threshold boundary;
• totals that make a suppressed cell derivable.

Do not place raw sensitive results in the query-history log. Store controlled fingerprints, counts, policy decisions, and restricted trace references.

Limit dimensions before SQL generation

High-cardinality and quasi-identifying dimensions can turn an aggregate into a row lookup. Exact timestamp, postcode, job title, account tier, rare product, and narrow age band may be harmless separately and identifying together.

Expose an allowlist of approved dimensions and combinations. Coarsen time, geography, and numeric bands when fine detail is not necessary. Reject unsupported combinations before the query reaches the database.

This complements result redaction for AI database agents; redaction protects returned fields, while aggregate controls protect inference.

Keep tenant and purpose scope structural

Aggregate access must use authenticated tenant, role, environment, and purpose context. A global count can leak another tenant even when no individual row is visible.

Enforce tenant scope in the database or trusted service layer and test shared lookup tables, cross-tenant totals, nested subqueries, and comparison requests. See tenant scoping for AI database agents.

Return a disclosure-aware result contract

A safe aggregate result should include:

• approved metric and definition version;
• scope, filters, period, and timezone;
• data freshness and source;
• group-size policy and whether suppression was applied;
• coarsening, rounding, or truncation;
• row and byte counts processed and returned;
• policy decision and trace ID.

The model can explain why a breakdown is unavailable. It should not guess the missing cells or imply that the visible categories form a complete table when complementary suppression was used.

Concrete example: overdue accounts

A finance user asks for overdue accounts by industry and region. The approved operation returns counts and balance bands for groups above the minimum size. One rare industry-region combination is suppressed, along with the regional total that would reveal it by subtraction.

The user then requests a narrower city filter. The policy detects that the combination would create a group of one and refuses the breakdown while offering a coarser region-level view.

A separate authorized account-review workflow may permit record-level access. The aggregate reporting tool does not silently become that workflow.

Test inference, not only direct access

1. Request groups of zero, one, and just above the threshold.
2. Reconstruct a suppressed cell from totals and visible categories.
3. Repeat a query with one filter changed.
4. Combine quasi-identifying dimensions until groups become unique.
5. Ask for cross-tenant totals and shared-table joins.
6. Verify suppressed values never enter model context, traces, or logs.
7. Confirm a reviewer can reconstruct the release policy and decision.

Where Conexor fits

Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. Aggregate disclosure controls make read-only access safer by keeping approved metrics, dimensions, group thresholds, scope, and release evidence explicit.

Explore Conexor security controls

For the wider governance model, use the AI database access governance checklist.