Copilot connectors need clean ACL mapping before they index external data

One problem comes up again and again in Copilot projects: getting external knowledge sources such as ServiceNow, Confluence or plain old file shares into Microsoft Search, and from there into Copilot. That's the job of Copilot connectors (formerly Microsoft Graph connectors). In almost every tenant I work in, the Copilot rollout raises the same urgent question. How do I stop oversharing or a permissions mess once external content starts flowing into Copilot?

Copilot connectors live in the Microsoft 365 admin center

Copilot connectors are how you bring third-party or file system content into Microsoft Search and Copilot. They sit in the Microsoft 365 admin center (Copilot → Connectors), and there are built-in options for ServiceNow, Atlassian Confluence, Salesforce and generic file shares, among others. Microsoft describes the technical basis and the connector catalog in the official connectors overview. Indexing files or tickets is only half of it, though. What really matters is how access control lists (ACLs) are mapped and how identities get linked. Copilot shows users whatever is indexed and permitted, no matter where it originally came from.

Misconfigured ACL mapping exposes restricted content to everyone

The trap I run into most often is ACL mapping that's set up wrong. If a connector can't read granular permissions from the source system, some connectors simply index the content as "everyone-visible". So a document that only a handful of people could open before now turns up in Copilot for the whole company. I see this constantly, usually when admins or project teams spin up a connector "just for testing" and never check the scope. Sources that don't use Entra ID make it harder still, for example legacy file shares or a Confluence instance with its own user store. In those cases you have to configure the identity mapping wizard in the connector setup very carefully. Get one setting wrong and your search index exposes far more than it should.

Practical tip: Once a connector is set up, test it with pilot users from several departments and check exactly what each of them can pull up through Microsoft 365 Search and Copilot. That way you catch ACL mapping errors and overly broad indexing before your users stumble onto the wrong content.

Connector limits can leave you with a partial index

There are technical limits as well. Every connector has its own caps on item count, file size, update frequency and so on (according to the current announcement; check the Microsoft documentation for the details). With large sources you may end up with only part of the content indexed, and that isn't always obvious. So keep watching index status and errors in the admin center. And if you need to know precisely what a given user can find through Copilot, nothing replaces hands-on testing with test accounts and targeted search queries.

The diagram below shows how data moves through a Copilot connector and where ACLs come into play:

flowchart TD
    ExternalSource["External source (e.g. ServiceNow)"] --> ConnectorService["Connector service"]
    ConnectorService --> Indexing["Indexing & ACL mapping"]
    Indexing --> M365Search["Microsoft Search index"]
    M365Search --> CopilotUser["Copilot query (user)"]
    CopilotUser --> Result["Search result (ACL filtered)"]

Figure: External data reaches Copilot through connectors, with ACL checks at each stage.

Identity mapping for non-Entra sources causes the most trouble

Linking identities from the source system to Entra ID users is usually the hardest part. Depending on the source, the mapping relies on email addresses, UPNs or even custom attributes. With legacy file shares or cloud platforms that don't use SSO, things get messy quickly. Automatic mapping only works when identities are maintained consistently and are unique. If you're combining old user bases from different systems, export a mapping table first and verify it with a test group before you roll out more widely. When in doubt, start with a small test cohort and only widen it once you've confirmed visibility is correct.

Removing a connector takes more than deleting it

If you indexed too much or turned on a connector just for testing, the cleanup matters as much as the setup. Deleting a connector doesn't always remove its indexed content right away, and that content can stay visible for hours or even days (according to the current announcement). What I do is disable the connector in the admin center, clear the index and keep checking the status until removal is confirmed. Also look at any groups that had special permissions tied to the connector. If you think sensitive content was exposed, run a search activity audit for the period in question (with Purview Audit, if you're licensed for it).

My Copilot connector playbook comes down to four steps

Here's what has worked for me. First, begin with a test group and dedicated non-production data. Second, validate each connector on its own, with as few users as possible, before the full rollout. Third, don't take ACL mappings on trust; test identity mapping and visibility for every type of user. Fourth, after each test, remove the connector completely, clear the index, and only then move to production. Sticking to these basics has given me stable, secure Copilot connectors in every project so far.

For more detail, take a look at Microsoft's documentation on Graph connector identity and security.