Data Discovery and Classification for Sensitive AI Workloads

How AI Workloads Generate Combinatorial Sensitivity That Static Labels Can't Anticipate

Static classification answers one question: what does this field contain right now? That's a reasonable question. It's also the wrong one, once an agent is running.

Sensitivity in AI workloads doesn't live in individual fields. It emerges from what happens between them. Employee ID is not sensitive. Department is internal. Salary band is internal. Performance quartile is HR-restricted. Assembled in a single query, those four fields produce an individually identifiable, multiply regulated record that nobody labeled as such, because the labels were applied to fields in isolation and were never designed to think about combinations. Each ingredient is benign; the dish is the problem, and nobody read the recipe.

The mechanisms that produce this are distinct, and they compound in ways that aren't always obvious until something goes wrong. Field joining is the most legible: two tables meet, a regulated record appears. Aggregation is subtler. A query that surfaces no individual record can still re-identify specific people once counts drop below a threshold or once the output is narrow enough that only one person plausibly fits the profile. Then there's context persistence, which is the one that took me the longest to fully internalize. When an agent retains output from one query and routes it into the next step of a workflow, sensitivity accumulates across a session in ways that no single query would have flagged. The agent isn't behaving badly. It's doing exactly what it was built to do, across a boundary the labels never knew existed.

Research from Cyberhaven Labs found that more than 80% of data exfiltrated from modern organizations consists of fragments: portions of plans, acquisition details, customer records moving through SaaS workflows and AI prompts without triggering file-based controls. Agents accelerate this not as a side effect but as a design feature, because crossing source boundaries is precisely what they're built to do. That number should recalibrate how you think about what exfiltration looks like now.

A point-in-time snapshot classifies what exists at rest. It says nothing about what a query will produce.

What Current Discovery and Classification Tooling Actually Does Well, and Where It Stops

The tooling has genuinely improved. The era of pure regex pattern-matching is mostly behind us, and that matters. Modern platforms use ML-based content detection, optical character recognition for scanned documents, contextual tagging, and continuous catalog scanning rather than periodic sweeps. Bidirectional tag synchronization between a metadata platform and the underlying storage systems turns classification from passive documentation into active enforcement: a label change propagates downstream rather than sitting inert in a catalog nothing reads at runtime. Real advances, full stop.

And yet. The 2026 Thales Data Threat Report found that only one in three organizations has complete knowledge of where their data is stored. Part of what makes agents useful is that they find data the organization didn't know it had. That same capability is what makes incomplete coverage consequential rather than merely embarrassing.

Where the tooling stops is consistent across every major platform I've worked with: these tools classify what a field contains, not what a query will produce. They operate on data at rest, not on data moving through an agent's session in real time. Access visibility is genuinely useful. Knowing which data a given agent can reach is not a trivial thing. But access visibility and combination-risk detection are different problems. Conflating them is where most governance programs quietly go sideways. Knowing every road on the map tells you nothing about which roads a particular driver will chain together into a route that crosses a restricted zone. No current major platform natively evaluates sensitivity at the point where data from multiple sources converges in a runtime query. That gap is structural. It's not on a feature roadmap.

Why Governance Frameworks Designed for Dashboards Misfire When Applied to Agents

Dashboard governance is coherent on its own terms. Permissions are static, reviewed on a defined cycle, scoped to a report whose query shape is known in advance. The consumer is identified. The question the report answers doesn't change between runs. Governance can be applied once and trusted across many subsequent accesses. That logic worked for a long time, and I don't think it deserves the contempt it sometimes gets in these conversations, because it solved a real problem in the context it was designed for.

None of it holds for agents. Agent permissions must be evaluated at query time, scoped to the actual end user behind the request, against a query whose shape was generated at runtime and has never existed before. Gartner has projected that a substantial share of organizations will fail to realize expected AI value specifically because of governance framework mismatches, not model quality. The framework is the variable.

A common failure mode: a user lacks direct access to a contract folder, but an AI assistant can summarize those contracts because the indexing process ignored access control lists. Governance was technically present. It just wasn't enforced at the moment that mattered. The policy existed; the agent didn't see it. Great attendance record. Never showed up to work.

Service accounts make this worse in a way that's easy to underestimate. They're the operational norm for agent infrastructure, and they cannot express the identity of the actual person issuing the request. When a permission check resolves against a service account rather than a person, it's resolving against the wrong subject entirely. The classification is correct; the enforcement is answering a different question than the risk question.

There's also a read/write asymmetry that most governance frameworks treat as equivalent, which they shouldn't. An agent reading from a source carries a fundamentally different risk profile than an agent writing, updating, or routing data downstream. Treating those actions identically in policy understates agent write risk by more than most organizations have accounted for, and that's the next category of incident we'll be talking about in a year or two.

What Classification Must Encode to Catch Sensitivity That Emerges at Query Time

Classification must move from field-level labels to relationship-level rules. The question can no longer be only "what does this field contain?" It also has to be: what does this field produce when joined to that table, aggregated to that granularity, or routed through that agent's session?

That requires encoding permitted data combinations explicitly. A label that reads "PII" on a field is necessary. It is not sufficient. What's also needed is a rule that reads: this field joined to that table produces a regulated record and requires elevated handling. MIT CISR research has been specific on this point, identifying that the semantic layer must encode data usage constraints, permitted combinations, rules for handling personal data, and lineage sufficient to support compliance audits. That's an architectural requirement, not a general principle. Combination logic belongs in the semantic layer, not only in access control lists.

Sensitivity also degrades over time in ways point-in-time classification structurally cannot address. A classification accurate when the catalog scan ran is wrong by the time an agent queries a live source hours or days later. As agent query volume scales, that freshness problem scales with it.

Audit logs face the same pressure. At scale, a log that records only "query executed" is forensically useless. Meaningful audit capture requires identity, intent, and lineage together: who requested the query, what policy evaluated it, what was joined, and what was returned. Anything less cannot support a real review after the fact. You cannot reconstruct what happened from breadcrumbs that were never specific enough to be useful in the first place.

The Semantic Layer as the Place Where Combination Rules Can Actually Be Enforced

A semantic layer translates raw fields into governed business definitions: entities, relationships, metric logic, and access policies, defined once and applied consistently to every agent and application that queries data. It sits between the agent and the underlying sources. It sees the full join before execution. That position is what makes it the right enforcement point for combination-risk rules, because the enforcement happens before the risk is realized, not after.

When a large language model agent encounters a raw field like custsegcd, it has no way to infer business meaning or sensitivity classification. A semantic layer supplies both at query time. Internal testing on governed semantic definitions has shown material reductions in data errors in generative AI natural language queries, which means governed definitions change not only what agents can access but what they actually produce. That's a larger claim than it first appears, and it is undersold in most vendor conversations about this architecture.

Combination-risk rules belong here because this is where they can be evaluated prospectively rather than detected retrospectively. If the semantic model defines a metric as the join of two sources, it can also encode the rule that flags, blocks, or reroutes that join when it crosses a classification boundary. The Model Context Protocol standardizes how agents query semantic definitions, which produces traceability and consistency as byproducts of the architecture rather than as compliance bolt-ons layered on afterward. Those are different things, even if the outputs look similar on a checklist.

What an AI-Workload Classification Program Looks Like in Practice

Start with a combination-risk inventory. Map which agent workflows join across sources, then classify the outputs of those joins, not only the inputs. This is a different scope than a traditional data catalog project, and it requires input from the teams who understand how the agents are actually designed, not only from the data governance function. Those two groups rarely talk to each other early enough, and the gap between them is where the most significant exposures tend to sit quietly until something surfaces them.

Push classification logic into the semantic layer. Field-level labels belong in the catalog. Combination rules and permitted-join policies belong in the semantic model, where they're evaluated at runtime against actual queries. Conflating these two things is how organizations end up with excellent catalog coverage and no runtime enforcement, which is precisely where most enterprises sit today.

Enforce permissions under the end user's identity at query time. A service account or a cached role from a prior session is the wrong subject for a permission check. Classification and access control must resolve against the same subject, or the check is answering a question nobody actually asked.

Treat agent write actions under a stricter policy tier than reads. The risk profile is asymmetric; governance should reflect that explicitly rather than assuming equivalence by default.

Build lineage into the audit log at the level of the query: what was joined, who requested it, what policy evaluated it, and what was returned. Table-level logging is insufficient at agent query volume. The minimum for meaningful forensic review is full query lineage, and organizations that have yet to build toward that are running on faith that nothing will need to be reconstructed.

Treat classification as a continuous process, not a compliance cycle. Agent workloads surface new combinations every time a new workflow is deployed. The catalog and the semantic rules must update as those workflows go live, not on a quarterly schedule designed for a world where query shapes were known in advance and the person at the other end was always a human sitting at a dashboard.