Official documentation checked October 14, 2026.
A connector audit must establish which information is indexed, who can retrieve it, and whether that audience is appropriate. A successful connection or crawl does not prove that permissions are safe. This workflow focuses on synced Microsoft 365 Copilot connectors; federated connectors and custom agents also require their own authentication and service-access review.
1. Inventory the connections and their owners
Open the Microsoft 365 admin center with an authorized connector-administration account, then go to Copilot > Connectors > Your connections. Record each connection’s ID, source system, owner, crawl status, scope, and visibility settings. Include paused or failed connections in the review: previously indexed information can remain searchable.
Do not equate native Microsoft 365 access to SharePoint, OneDrive, or Exchange with a separate external connector. Review those services’ permissions too, but keep the inventories distinct. Microsoft’s connector overview explains the different connection models.
2. Check the connection-wide access model
Open a connection’s details and review Permissions. An access model limited to people who already have source access is materially different from one that makes the indexed content visible to everyone in the organization. The latter does not preserve each item’s restricted source audience.
Obtain the source owner’s approval for the intended audience rather than judging safety from a source name such as “HR.” A broad internal group can be inappropriate even when every member is an employee. Microsoft’s access-permissions guide currently says changing this connection-level access model requires deleting and recreating the connection. Treat that as a planned migration, not an automatic first troubleshooting step.
3. Validate representative indexed items and users
Use the connection’s index browser with a known item ID. Inspect the indexed properties, refresh information, and permissions. Use Check user access for an employee who should have access and another who should not. Compare those results with the actual source permissions and user/group mappings.
Test several sensitive collections, not only one public document. A missing user can indicate mapping or discovery problems; review the mapping configuration and error reports. Permission changes are not necessarily immediate. Microsoft’s index-validation guide explains ACL refresh and full-crawl requirements. Repeat the negative-access test after the applicable refresh completes.
4. Establish what the sensitive-data scan actually covers
Ask the source owner to identify restricted fields, documents, and record types, then compare that list with the connector’s configured scope and indexed properties. Use the classification or discovery tooling supported for that source and document the coverage, exclusions, and scan date. Absence from a report is not evidence that an unscanned external repository contains no sensitive information.
Get-DlpSensitiveInformationType lists sensitive-information-type definitions in Security & Compliance PowerShell; it does not scan a URL or repository. Microsoft documents its purpose in the cmdlet reference. Keep classification results separate from the access test: finding sensitive content and proving unauthorized access are different findings.
5. Automate inventory with a documented API
There is no documented Exchange Online Get-CopilotConnector command for the workflow described here. For external-connection inventory, Microsoft Graph documents this read request:
GET https://graph.microsoft.com/v1.0/external/connections
The corresponding Graph PowerShell example uses Get-MgExternalConnection from Microsoft.Graph.Search. Use approved authentication and permissions appropriate to the inventory’s scope; do not grant write access simply to reproduce a sample. See List externalConnections. A connection list is not an item-permission audit, content scan, or guarantee of coverage for every federated connection.
6. Contain the specific exposure and retest
Correct the source ACL, identity mapping, or ingestion scope that caused the finding. If the access model itself is wrong, preserve configuration and dependencies before an approved recreation. Plan the indexing interruption and verify the replacement before declaring completion.
Connection visibility can provide a narrower containment measure, but Microsoft notes that hiding a connection does not stop crawling; partner-connector visibility also has limits for declarative agents. Pausing a crawl alone does not remove already indexed content. Follow the connection-management guidance, record the affected surfaces, and rerun the item/user tests. Keep unresolved coverage gaps in the audit report rather than describing the entire tenant as safe.