Sensitivity Evaluation at Data Combination Points

Traditional access controls were designed for a world of discrete queries: one identity, one table, one retrieval. Field-level classification, the tagging of columns as PII, confidential, or restricted, happens at collection time. It has no mechanism for evaluating what a join produces. The classification travels with the field. Not with the output.

Most enterprise data estates compound this problem structurally. Schemas are normalized for transactional or analytical workloads, not for the compound retrieval patterns AI agents generate. A service account running a query on behalf of an agent inherits broad, static permissions disconnected from the actual end user whose question triggered the query. The agent holds valid permissions to an HR table, a project table, and a compensation table individually, and still produces a joined output it should never have surfaced. No control in the current stack intercepts that.

The governance gap is widely felt even if its root cause isn't precisely named. A 2025 KPMG report found that 62% of organizations cite lack of data governance as the primary challenge inhibiting AI initiatives. An IAPP 2024 survey found only 28% have formally defined oversight roles for AI governance. So the ownership question is still unresolved before the technical architecture question even gets raised.

What actually becomes sensitive at the combination point

Not all emergent sensitivity works the same way, and that distinction matters because each pattern requires a different detection mechanism. Conflating them produces policies that address none of them adequately.

The first is re-identification. Joining a de-identified medical or HR record with a location or behavioral dataset can restore individual identity. The anonymization didn't fail; the combination circumvented it.

The second is inference. Joining performance data with compensation data with org-chart position surfaces salary equity gaps, termination risk, succession planning. None of those outputs exist in any single source. The query manufactures them.

The third is aggregation exposure: combining individually permissioned datasets to produce a population-level view that should require a separate, higher authorization, one that no field-level tag is designed to trigger.

AI agents make all three patterns more frequent because they generate multi-table queries automatically, without the deliberate reasoning a human analyst would apply before running a join. Shadow AI compounds this further. When employees route internal documents through unmanaged tools, combination points form outside any governed perimeter.

The sensitive output doesn't exist upstream. Re-identification is an emergent property of access architecture, not a data quality failure solvable at the source. Governing it requires evaluating data for what it can become when joined, not only what it contains in isolation.

U.S. intelligence law recognized long ago that individually unclassified fragments, assembled together, can compromise protected subjects or operational security. The intelligence community built doctrine around what it called the mosaic effect precisely because the risk lived in the combination, not in any constituent piece. Enterprises are encountering the same problem now, compressed by the speed at which AI agents can correlate data points that once would have taken human analysts weeks to assemble. The exposure window is now effectively zero.

Why moving sensitivity evaluation to the query layer is the necessary architectural response

If sensitivity is created at query time, the only defensible interception point is query time. Upstream classification describes fields. Downstream audit describes what already happened. Neither prevents the exposure.

User-scoped permissions evaluated at query time, tied to the actual end user rather than a service account, are the minimum viable control. They ensure that what an agent retrieves is what that specific user is authorized to see at that moment. But necessary is not sufficient. They stop unauthorized retrieval; they don't evaluate whether the combination of authorized fields produces an unauthorized view. That is a different problem, requiring a different policy model.

Combination-point evaluation introduces join-path awareness: does this query cross a boundary between data domains that, in combination, produce a higher-sensitivity output? It introduces schema context: does the semantic layer carry the relationships and metric definitions that make emergent sensitivity detectable before the result is returned? And it introduces policy at the combination rather than at the component. A rule expressed as "compensation joined to performance joined to org hierarchy requires approval" is categorically different from three separate field-level tags that never interact with each other.

Static pipelines cannot do this. They assume stable sources and stable schemas. AI agents query dynamically across sources that were never intended to be joined. The production-readiness standard for any governed AI workload requires that every piece of data returned carries known provenance and access controls, and that the workload's use of that data is logged in a form an auditor would accept. That standard cannot be met if sensitivity is evaluated only at the field level.

The semantic layer's role in making combination-point sensitivity detectable

An AI agent carries no institutional memory. It cannot ask a colleague what a vague column name means, and it cannot reason about what a join produces without structured context about how the business actually uses its data. That gap is not a limitation of any particular model; it is structural.

A semantic layer encodes exactly what combination-point governance needs: table descriptions, metric definitions, relationships between entities, the business logic that connects them. It is the machine-readable representation of how data is actually used, not merely how it is stored.

Metric inconsistency is the most pervasive data quality failure in AI deployments, and it is a governance problem as much as a quality one. The same concept defined differently across systems means a joined query can silently produce a meaningless or misleading result. Internal Google testing found that LookML reduces data errors in generative AI natural language queries by as much as two-thirds, which is direct evidence that structured semantic context materially changes what agents get wrong. Gartner elevated the semantic layer to essential infrastructure in its 2025 Hype Cycle for BI and Analytics. Not optional scaffolding.

A semantic layer that only carries metric definitions is still incomplete for combination-point governance. It tells the agent what data means; it doesn't tell the governance layer whether the agent should have it. What closes that gap is ownership and certification status per metric, AI-agent access policies scoped to specific workloads, and lineage that traces the actual sources of values in a joined result back to their origin.

MIT CISR research finds that business leaders feel increasing pressure to invest in semantic technologies that can store metadata and make data assets useful to AI agents instantaneously. The question is whether the semantic layer is built to carry governance weight, or just definitional weight.

What audit and lineage requirements look like when agents generate queries at scale

Human analysts generate queries deliberately and infrequently. AI agents generate them continuously and automatically. The audit surface is orders of magnitude larger, and the log that was adequate for human-scale querying is not adequate here.

A log that captures only the query and the result is insufficient at agent scale. Without the real user's identity behind the request, the agent's intent, and the full join path across every source touched, the log cannot reconstruct how a sensitive output was created. Identity is harder than it sounds: when an agent runs under a shared service account, the log records the service account, not the end user, and the combination point becomes unattributable.

IBM's 2025 Cost of a Data Breach Report found that a notable share of organizations reported breaches involving AI models or applications. A separate 2025 survey found that fewer than one in ten organizations integrate AI risk and compliance reviews directly into development pipelines. Governance remains largely a post-hoc exercise, which is structurally too late to catch combination-point exposure.

Regulatory expectations are tightening around exactly this. GDPR, ISO/IEC 42001, the NIST AI Risk Management Framework, and the EU Data Act, which began applying in September 2025, each presume that an organization can reconstruct what data was accessed, why it was accessed, and by whose authority. Adequate audit infrastructure at combination points must capture the real user identity behind the agent's query, the full join path across every source, the sensitivity classification of the output and not just the inputs, and the policy decision that evaluated the combination. An audit trail that cannot answer all four of those questions is not an audit trail; it is a log.

Why most enterprises haven't yet made this architectural shift, and what's changing

The gap is not primarily technical. A 2025 IAPP survey found that 77% of organizations are actively building or refining AI governance programs. But building a program is not the same as evaluating sensitivity at combination points. Accenture's research identifies only 7% of enterprises as having progressed far enough in AI-ready data capabilities for scaled AI adoption; that cohort achieves profit margin uplifts up to 1.6 times over industry peers. The distance between those two figures is where most governance programs actually live.

A few structural conditions explain the slow movement. Governance ownership is fragmented: with only 28% of organizations holding formally defined AI oversight roles, combination-point policy falls between compliance, IT, and legal with no clear owner and no clear accountability. Many teams also operate under the assumption that combination-point governance requires migrating to new infrastructure, when a semantic and governance layer can sit on top of existing systems. And classification systems were designed for fields, not joins. Retrofitting combination-point policy onto field-level tagging requires a different policy model entirely, not merely additional tags.

What is forcing the change is simpler. AI agents are now in production, generating cross-source queries at volumes that have made the exposure real and frequent rather than theoretical. Regulators are asking questions, including GDPR data subject requests and AI Act conformity assessments, that require combination-point audit trails to answer. A 2025 CSA survey of 300 IT and security professionals found that governance maturity is the strongest predictor of AI readiness. Organizations that have made the architectural shift are separating from those that have not, and the gap is becoming visible in outcomes.

The realistic path forward is additive: a governance and semantic layer that spans existing infrastructure through a single interface, rather than requiring a parallel data estate.

What a combination-aware governance architecture looks like in practice

The core requirement is a single layer that sits between AI agents and existing data infrastructure, enforcing sensitivity evaluation at the point where queries cross source boundaries. Not upstream. Not in post-hoc review. At the crossing.

That layer needs to do several things to function. Query-time permission enforcement must be scoped to the real end user's identity, not a service account's static grants. Semantic context must cover every queryable object, including definitions, relationships, and metric ownership sufficient to detect when a join crosses a sensitivity boundary. Combination-point policy must be expressed as rules that evaluate the output of a join rather than its inputs. Full lineage logging must capture identity, join path, the sensitivity classification of the result, and the policy decision, all at query time, not reconstructed after the fact. And revocability must operate at the workload level, so that an agent's permissions can be modified without disrupting everything downstream.

Peaka's architecture addresses these requirements by providing a semantic layer with governance built into every query, permissions enforced at query time under the real user's identity, and full lineage logging, positioned on top of existing infrastructure without migration.

The no-migration requirement matters specifically for this problem because the data that needs to be governed already exists, distributed across warehouses, SaaS tools, and operational systems. A governance layer must span all of it without requiring a consolidated copy. A consolidated copy would itself be a combination point; centralizing data to govern it creates the exact mosaic the architecture is meant to prevent.

The practical test for any candidate architecture is straightforward. Can it tell you, for any query an agent ran, which sources were joined, which user's identity governed the access, what sensitivity classification the output carried, and what policy evaluated the combination? If the answer is no, the mosaic effect remains ungoverned, regardless of how many fields have been tagged.