Clouds Connected · Case study
Product studyFinancial services

Copilot connectors for five enterprise data sources, with 33 security controls that stop any crawl a bank could not defend.

Microsoft 365 Copilot connectors for SQL Server, Cloudera CDP, Oracle, Teradata and MongoDB, built for a US commercial bank on one shared engine, with 33 security controls that stop a crawl the moment a source decides access per person rather than per group.

Client
A US commercial bank
Sector
Financial services
Engagement
Microsoft 365 Copilot connectors pushing enterprise sources into the Microsoft Graph index
Period
SQL Server deployed, Cloudera CDP in progress
In progress

One of the five connectors is deployed; the programme is not finished. The Cloudera CDP connector is in progress and its QA cluster would currently refuse a crawl by design. The Oracle, Teradata and MongoDB connectors are built, tested and released but have never run against a real instance. Their deployment guide says so in its first paragraph, and so does this page.

In brief

Microsoft 365 Copilot connectors: what this engagement covered

The challenge

A US commercial bank wanted Microsoft 365 Copilot to answer questions over the data the business runs on: SQL Server, Cloudera CDP, Oracle, Teradata and MongoDB. Copilot reasons only over what has been indexed, so the value depended on getting that data into the Microsoft Graph index. The risk was never ingestion. It was access.

Every one of those sources answers "what may this person see?" at query time, from who is asking: row-level security, Oracle Virtual Private Database, Teradata security constraints, a redacting MongoDB view, Ranger policies over Hive and HDFS. A search index answers it once, at write time, then serves one copy to everyone entitled to it. Configuration cannot reconcile the two.

The mismatch fails silently, which is what makes it expensive. The crawl succeeds, the index looks complete, Copilot answers fluently, and somewhere in the corpus sits a row the reader was never entitled to see.

The solution

Five connectors run on one shared engine, with no source technology named anywhere in the shared code, so a sixth source is an adapter rather than a rewrite.

Every connector refuses a source that enforces access per user. Not warns, refuses, with a non-zero exit. Oracle stops on Virtual Private Database, Label Security, Real Application Security or Data Redaction; Teradata on row or column security constraints; MongoDB on views, which may redact on the caller’s roles without the driver knowing, and on encrypted fields, which index as ciphertext; Cloudera on Ranger security zones, on any policy carrying exceptions, conditions or validity schedules, and on a tag-service policy that denies or masks.

Access runs through one Active Directory group per source, under a condition stated rather than assumed: the group must be entitled to the least-accessible item in the corpus, because anything narrower is over-granted the moment it is indexed. That makes crawl scope, and the refusals that police it, the primary defence rather than a backstop. Revocation moves from the source to Active Directory, a cost accepted openly.

Guards fire on the dangerous direction only. Over-granting stops the run and under-granting is logged, because a guard that fires on the safe direction teaches operators to switch guards off.

The results

5 source familieson one shared engine: SQL Server, Cloudera CDP, Oracle, Teradata, MongoDB
33 security controlseach pinned by its own test
479 testsacross 15 projects and roughly 36,500 lines of code
111,800 itemsthrough the second of two exhaustive live test cycles
DimensionBeforeAfter
A source filtering rows per userIndexed once, served to everyoneRefused before anything is written
A clock-dependent Ranger policyRead as absent, silently over-grantingStops the run
A withdrawn security controlDeleted with its reasoningOne of four struck through in place
A silent defect in crawl stateShips, nothing fails visiblySix review passes found nineteen, six blocking

The SQL Server connector is deployed at the client and the rest is in progress. Cloudera CDP is not live: a tag-service policy on its QA cluster carries an item condition, so two controls fire and the run stops. That is the design working, with the blocker in code rather than in a document. Oracle, Teradata and MongoDB are built, tested and released, but have never run against a real instance.

One architectural limit belongs in the record because engineering does not remove it. A Microsoft Graph access list is a static snapshot with no validity window, so a time-conditioned source policy cannot be mirrored by any connector. Crawl cadence bounds the drift between index and source intent; nothing closes it.

Technologies

Questions we get asked

Microsoft 365 Copilot connectors: common questions

Can you index a SQL Server database with row-level security into Microsoft 365 Copilot?
Not safely. Row-level security answers “what may this person see?” at query time from who is asking, while a search index answers it once at write time and serves one copy to everyone entitled to it. One indexed copy cannot show different rows to different people, so these Microsoft 365 Copilot connectors refuse such a source outright with a non-zero exit rather than indexing it and hoping. The failure mode is otherwise silent: the crawl succeeds, the index looks complete, and Copilot answers fluently from rows the reader was never entitled to see.
How do you stop a Microsoft 365 Copilot connector from exposing data a user should not see?
Grant every indexed item to a single entitlement group per source and nothing else, even where the source could supply a per-item access list, because a Microsoft Graph access list is a static snapshot with no validity window. That model works only under a condition worth stating openly: the group must be entitled to the least-accessible item in the corpus, since anything narrower is over-granted the moment it is indexed. Safety therefore comes from crawl scope and from guards that stop the run on over-granting, not from cleverness in the connector.
Can a Microsoft 365 Copilot connector enforce Apache Ranger policies from a Cloudera CDP cluster?
Only partly, and the gap is architectural rather than an implementation shortfall. A Ranger policy can carry conditions, validity schedules and exceptions, while a Microsoft Graph access list has no clock, so a time-conditioned policy cannot be mirrored by any connector however perfectly it reads policy. The correct response is refusal rather than approximation: security zones, conditional policies and masking tag policies each stop the crawl. On one bank’s QA cluster a tag-service policy carrying an item condition is enough to stop the run today.
What should a bank check before indexing a data warehouse into Microsoft 365 Copilot?
Establish first whether the source enforces access per user, since Oracle Virtual Private Database or Label Security, Teradata row and column security constraints, and MongoDB redacting views or encrypted fields all decide entitlement at query time and cannot be indexed once and served to a group. Then decide the entitlement group for the crawl and confirm it is entitled to the least-accessible item in scope. Crawl scope, not connector configuration, is what makes the result defensible to an auditor.
Related work

Other engagements like this one

Work with us

Two ways this usually starts

For consulting partners

SharePoint delivery under your paper

Nine of the ten engagements in this library were contracted through a systems integrator, an ISV or a managed provider, with Clouds Connected as the named SharePoint delivery lead. Your client relationship, your invoice, our platform depth — white-label delivery, escalation cover, or a fixed-scope block of hours.

Every study here is anonymised by default, which is also how we work inside your accounts.

For direct clients

Upgrades, migrations, recovery, patching

SharePoint Server and Microsoft 365 platform work on estates that cannot simply be rebuilt: version upgrades, tenant and content migrations, disaster recovery design and drills, performance root-cause diagnosis, and scheduled security patching on a standing cycle.

Regulated utilities, financial services, aerospace and healthcare. Based in the Greater Toronto Area, Canada; delivery across North America.

Provenance

Where these facts come from

Reconstructed from project correspondence, September 2021 to September 2026. Every figure on this page traces to a dated message, and the source citation for each sits in the accompanying fact sheet. Nothing has been estimated, rounded up, or written on the client’s behalf.

Clouds ConnectedFinancial services · Copilot connectors for five enterprise source families