CData Connect AI gives AI agents live access to more than 350 enterprise data sources (Salesforce, ServiceNow, NetSuite, HubSpot, your on-prem SQL Server, your data warehouse) through a single governed MCP platform. The connection layer is solved.

The question that should come before you connect any data source to an AI agent almost never does: what’s actually in the data?

Schema names describe intent, not content. Field names can be wrong, outdated, or simply never updated to reflect what ended up in them. This is true of every data source: CRM, ERP, data warehouse, ticketing system, anywhere years of human data entry have had their way with a schema. A column called Fax can contain Social Security numbers. We saw that exact case in a production Salesforce org. The scanner flagged it. The schema wouldn’t have.

That’s the classification gap. This post is about closing it: before you connect your first data source, and monitoring for data drift after.

The classification step teams skip

The question that should come first when you put an AI agent in front of a database (what’s in there that needs to be protected?) almost never does. Teams move fast. They wire up the connection, scope what the agent can see, and assume the field names tell them what’s sensitive.

The same question stays relevant after the connection is live. Data drifts. The Notes column is clean on launch day and full of credit cards six months later because a support engineer pasted one in to remember a customer. Field-level controls you set at provisioning time silently stop matching reality. If you’re not scanning continuously, you’re trusting the front-end to keep your back-end clean, and that’s almost never been a winning bet.

Inspect-Data and CData work on adjacent problems, content classification and data access governance, and they fit together in a way that’s not obvious until you’ve watched a team skip the classification step and ship anyway.

The configuration model is sound. The inputs aren’t.

CData Connect AI is one face of CData’s broader platform. The connector layer reaches 350+ data sources; on top of it, CData exposes the same data through a Virtual SQL Server endpoint, REST/OData APIs, ODBC/JDBC drivers, and, most relevantly for AI, a standardized MCP endpoint. Same data, multiple consumption surfaces, one configuration to manage.

For AI agents specifically, the governance model is good: Workspaces define which datasets an agent can discover; Toolkits define which operations it can perform; each Workspace/Toolkit pair deploys as its own dedicated MCP endpoint. You can give a sales agent read access to a slice of Salesforce without exposing your accounts payable database.

This works perfectly, provided you know what’s actually in each Workspace before you scope it.

The reality is that many teams configure Workspaces from a table list. They include the customer table, exclude the payroll table, allow read on orders. The decisions are based on table and column names. If the schema looks clean, the configuration looks clean.

Three patterns we see when content classification gets skipped:

Manual audit. A security engineer reads schemas table-by-table. Thorough, unscalable, and by the time the audit lands the use case has moved on.

Field-name heuristics. “If the column is called SSN, lock it down.” Reasonable as a starting point, brittle in practice. Free-text columns named Notes or Description routinely contain SSNs, phone numbers, emails, and whatever else a data-entry user pasted there at 4pm on a Friday.

Trust existing database permissions. Row- and column-level security assumes a known application and known query patterns. An AI agent writing arbitrary queries breaks that assumption. CData gives you the controls to handle this, but you need to know what’s in the data before you can guard it.

What “classify first” actually looks like

We ran Risk Finder (Inspect-Data’s content classifier) against a Salesforce org through CData Connect AI’s Virtual SQL Server endpoint. The setup: 1,002 tables, 11,902 columns, 100-row sample per table.

One interesting outcome: an Account.Fax column had been used as the org’s de facto SSN field. The scanner classified it as sensitive [US-SSN, 100% coverage, confidence 90]: every sampled row matched, at a detector confidence of 90. The column header reads “Fax.” Nothing in the schema would have told you to lock it down.

We also caught:

• Account.SicDesc (Standard Industry Classification text, supposed to hold things like “Software, Prepackaged”) full of email addresses; somebody had been pasting the wrong field
• Account.Description correctly flagged as containing emails, phones, and SSNs, plus the compliance regimes triggered: POLICY-CCPA, POLICY-GLBA, POLICY-PII-GENERAL
• LoginGeo.Latitude/Longitude and LoginHistory.ForwardedForIp: security telemetry that’s PII under most modern privacy frameworks

41 columns flagged out of 11,902. That’s a number a security reviewer can triage in an afternoon. Compare against reviewing 11,902 columns from scratch.

How Risk Finder works with CData

Risk Finder ships as a single Docker container, providing an MCP server that interacts with CData Connect AI. Use Risk Finder with Claude, or any MCP-aware client, to drive scans interactively. Tools include list_workspace, scan_table, scan_workspace. Point them at a CData connection and schema; structured findings come back: {classification, dominant_entities, coverage, avg_confidence, max_confidence} per column, with statistical analysis. Identify both mislabeled columns (newSchemaCol1 is actually an SSN) as well as statistical oddities (a mispasted SSN in a phone number field, or driver’s licenses that have leaked into the notes field).

SQL backend. Under the hood, Risk Finder fetches sample rows via SQL, using CData’s Virtual SQL Server endpoint. SQL is dramatically faster than asking an LLM to scan rows: a 1,002-table Salesforce org completes in minutes, while an LLM-per-row approach would take orders of magnitude longer with per-token billing.

Classification happens inside the container. Risk Finder’s classifier is entirely self-contained. The detector models, the rules, the keyword lists, the compliance-regime mappings: all local. The container’s only outbound traffic is the SQL connection to your data source.

No row data is sent to an external classification service.

This matters because a tool you point at your most sensitive data shouldn’t itself be a privacy hazard. Risk Finder reads via your existing CData connection, classifies in the container, and emits an aggregate summary. The raw cell values never leave your environment.

For deployment, the container takes environment variables for your CData credentials and exposes itself as an MCP server for ease of use. Use it with Claude Code, Claude Desktop, OpenCode, or your own MCP-aware tooling.

How the workflow fits together

What we recommend before, and after, standing up a Connect AI Workspace:

1. Classify first. Point Risk Finder at the data sources you intend to expose. Run it via the MCP server; Claude can drive it interactively, or you can script it directly.

2. Scope Workspaces from the findings. A column flagged sensitive [US-SSN] doesn’t belong in a sales-agent Workspace. A column flagged clean is safe to expose. A column flagged mixed deserves a human look before it ships.

3. Configure Toolkits accordingly. Read-only on tables with flagged columns. Write access only on entities the agent demonstrably needs. The decisions are now grounded in what’s actually there, not what the schema names suggest.

4. Re-scan on a schedule. Schemas drift, and so does the data inside them. The column that’s clean today might be full of SSNs in six months. Run the classifier on a cadence against rows updated since the last scan; new findings are potentially real drift, or a new ingest path you didn’t know existed.

Configuration time is a bit longer than just enabling the connection, but you ship a Workspace you can defend in a compliance review, and you don’t discover a year later that your AI agent has been quietly returning sensitive PII whenever someone asks about “that account from the West Coast.”

How to start

CData Connect AI handles the connection layer and per-agent governance. Risk Finder handles the content layer: what’s actually in there, regardless of what the schema says. Together, they give you a defensible “before you connect” step that takes minutes but gives you a level of confidence, and an “after you’ve connected” step you can re-run forever.

To try it: pull Risk Finder from Docker Hub, point it at your CData Connect AI setup, and start with one of the larger free-text tables in your most sensitive workspace. The first scan often finds something, and the subsequent periodic scans tell you whether your front-end controls are holding.

Classify first, then connect.

Pull Risk Finder from Docker Hub | How Risk Finder works | Talk to us about AI data governance