Copilot Connectors Security: Synced and Federated Acceptance Tests

Microsoft 365 Copilot connectors now split into two models with different security consequences. A synced connector ingests external content and indexes it in Microsoft Graph. A federated connector retrieves content at query time through MCP, keeps the source data in its original location, and can expose tools that create or update records, or delete them.

I would reject any connector review that puts both models under one green check mark. Draw two columns on the whiteboard. If the rows for data location and acting identity match those for write authority and audit owner, the review has probably skipped the mechanism.

TL;DR

• Treat synced and federated Copilot connectors as separate security models, with separate approvals and evidence.
• Record where data moves and which identity retrieves it. In the same acceptance evidence, document how source permissions map and where activity is audited.
• Test citations and stale permissions. Add denied reads and write approval, plus connector disablement and evidence export, using controlled accounts.
• Keep Microsoft-hosted Copilot and MCP tool traffic outside DeepInspect's boundary; only deliberately routed HTTP LLM calls enter it.

Two connector models create two control paths

Microsoft's Copilot connectors overview defines the first acceptance decision. Synced connectors ingest and index external content in Microsoft Graph. Federated connectors retrieve content in real time through MCP without indexing the source data into Graph. Microsoft also warns that implementation and authentication vary by connector model, as do packaging and availability for the target experience.

Start the acceptance record with the model name. For a synced connector, capture the source system and schema. Record indexed fields and the ingestion account, plus synchronization frequency and deletion behavior. Identify the Microsoft 365 location that receives the content. For a federated connector, capture the MCP endpoint and retrieval identity. Record the token audience and source permission check, then the exposed tools and Copilot experiences where the connector is available.

Link the record to the existing Microsoft 365 Copilot security review, but keep this artifact separate. A platform review asks how Copilot handles enterprise data. The connector matrix asks which bridge moves or retrieves each field and under which authority. It also records what happens when that authority changes.

Synced connector acceptance tests

A synced connector creates a second governed copy in Microsoft Graph. The acceptance test must prove that the indexed copy matches the approved schema and access model rather than relying on a successful crawl count.

Use a test source containing exactly three records. Make the first visible to the test user. Deny the second through a source ACL. Set the third so its permission changes after initial ingestion. Put a conspicuous value such as RED-FOLDER-27 in the denied record. After synchronization, search as the test user and capture the returned items and citations with their timestamps. Change the visible record to denied, run or await the documented sync, then repeat the search. Record the interval during which the old permission or content remained discoverable.

The matrix should include:

• Indexed content: Record exact source and derived fields. Add attachments and labels, then identify excluded values.
• Ingestion authority: Record the account or application and its granted scopes. Name the credential owner and rotation path.
• Identity mapping: Record the source and Microsoft 365 principals. Document group expansion and the treatment of unmatched users.
• Change handling: Record expected timing for additions and edits. Do the same for permission changes and deletions.
• Evidence: Preserve the connector configuration version and crawl event. Add the query result and citation, plus the access decision.

A connector that passes ingestion while exposing RED-FOLDER-27 to the wrong account has failed the only test that matters.

Federated connector acceptance tests

Microsoft's federated connectors overview says federated connectors access data using the user's identity and permissions. They leave external data in its original location and are governed by administrators in the Microsoft 365 admin center. Where the connector supplies tools, Copilot can also create or update source data, or delete it, with user approval. Microsoft says administrators can audit activity in Purview.

Test the live authorization path with two named users whose source permissions differ. Each user should issue the same query. Capture the source-side authorization event and Copilot citation. Preserve the corresponding MCP activity and Purview record. Then revoke one user's source access and repeat the query after the documented propagation interval. The connector should return only what the source currently permits.

Write tools need a separate test tenant. Attempt one allowed update and one action beyond the user's source authority. Capture the approval screen and tool name. Preserve the arguments and source identity, along with the resulting record and audit events. A user clicking approve cannot expand the source account's authority. The destination must reject the out-of-scope operation and record the denial.

Treat tool descriptions and retrieved data as untrusted model input. The indirect prompt injection guide explains the model-side risk, while connector approval still belongs to Microsoft administration and the MCP server, with separate authorization at the destination system.

The acceptance matrix

One row should represent one connector in one environment. Avoid a document that approves a connector family across production and non-production environments such as staging and development. The row needs these fields:

• Connector identity: Record the name and publisher, followed by the version and model. Add the environment, owner, and review expiry.
• Data movement: Identify the source and indexed destination or live retrieval path. Record the fields, attachments, and deletion behavior.
• Authentication: Identify the ingestion principal or user identity and OAuth audience. Record scopes, token lifetime, and the named secret owner.
• Authorization: Document source ACL mapping and group treatment. State the unmatched identity behavior and write ceiling.
• User experience: Record the supported Copilot surface and citation behavior. Preserve the approval prompt and failure message.
• Administration: Name the approver and availability group. Record the configuration version, disable control, and rollback owner.
• Audit: Preserve the Microsoft 365 and source-system events. Add the MCP event where applicable and the destination result. Record the request ID and retention owner.
• Acceptance evidence: Preserve the permitted and denied reads. Record permission revocation and the permitted write. Add the denied write and disablement evidence, followed by restored service.

The final row should state the residual risk in plain language. For synced connectors, that may be permission-change lag in the indexed copy. For federated connectors, it may be a source API whose audit event omits the Microsoft user identifier. Give that gap an owner and an expiry date.

Disablement and evidence replay

A connector approval needs a kill test. Disable the connector through its administrative control, then repeat the exact query and write attempt used during acceptance. Preserve the user-visible failure and the corresponding administrative or audit event. Re-enable only after the expected behavior has been reviewed.

Replay one accepted transaction using exported records alone. The reviewer should be able to identify the user and connector version. The record must show the source and retrieved or indexed object, followed by the permission result and Copilot surface. It must also preserve the action approval and destination outcome with the timestamp. Missing joins belong in the acceptance matrix rather than in a future logging backlog.

This is where a request ID earns its keep. Print the Microsoft 365 and source-system identifiers beside the destination identifier on one sheet of paper. If the team needs three consoles and a guess to connect them, the evidence package remains unfinished. Signed audit logs for AI requests covers the separate integrity requirements for a routed model-call record.

DeepInspect

DeepInspect applies to a narrow segment of a connector-enabled architecture. When a customer-controlled application assembles connector-derived content and deliberately sends an authenticated HTTP request to an LLM through DeepInspect, the proxy can evaluate the supplied caller identity and data classification, followed by the model destination and policy, before forwarding the request. It records whether that model call was permitted or denied and whether redaction was applied.

Microsoft retains control of native Copilot inference and connector administration, along with synced indexing and federated retrieval. It also retains control of Purview events. MCP servers and destination systems retain tool authorization. Keep those records beside the DeepInspect decision rather than presenting one log as proof for the whole path. Book a technical deep dive at deepinspect.ai.