Secure content before you expose it to AI#

Enabling the MCP server means an AI client can reach report content. Everything needed to control that exists, but none of it is automatic, and the defaults differ between the two access paths in a way that surprises people.

This page is the checklist to work through before you turn it on. The mechanics of each path are in Copilot, MCP and trust paths; this is the governance decision that sits on top.

The one fact that drives everything#

Two paths reach the MCP server, and only one of them carries a user identity.

On the identity path, your existing permission model is the control, and it does the work you expect.

On the API-key path there is no per-user identity at all. The request is not "Alice asking"; it is "the instance asking". Content-service trimming still applies, but per-user permissions cannot, because there is no user. Anyone who holds the key sees what the instance can see, bounded only by the workspace narrowing you configure.

Treat an MCP API key as equivalent to a full-workspace read credential, and handle it accordingly.

Work through these before enabling#

1. Decide which path you actually need#

If your callers are people using Copilot or a signed-in AI client, use the identity path and let permissions do their job. Reach for the API-key path only when the caller genuinely is a machine with no user behind it, and then narrow it to a named workspace.

2. Decide what a reader is allowed to see#

Reportworq's permission model already answers this for the portal. The question is whether the answer is still right when the same content is reachable conversationally, where a reader can ask broad questions rather than navigating to a specific report.

Go through the workspaces in scope and confirm the folder and item permissions say what you intend, rather than what has accumulated.

3. Decide which surfaces stay hidden#

Content marked hidden from readers stays hidden through MCP as well as in the portal. That is the mechanism for "this exists but is not for general consumption". Use it deliberately rather than relying on obscurity.

4. Gate the ingresses independently#

Each ingress has its own MCP-scoped channel switch, and an instance-wide access mode (Disabled, Key, or OAuth) sits above both:

• The Direct URL channel governs direct callers. Enabling it also turns on the workspace's Local API.
• The CloudHub relay channel governs relayed callers. Enabling it also turns on the Cloud Connector.

Because the channels are MCP-scoped, turning off the direct channel stops AI agents on that ingress without disabling the shared Local API or Cloud Connector features behind it. That is what lets you lock down the direct API surface while a relayed Copilot agent keeps working.

Start with the instance-wide mode set to the narrowest thing that meets the requirement, and open up from there.

5. Confirm the audit trail is where you expect#

Every request that reaches a tool, and every request rejected at the gate, is recorded. The rejections matter as much as the successes: they are how you notice a client probing for content it should not have. See MCP audit.

Decide who reviews that log and how often, before you need it.

Verify as a reader, not as yourself#

This is the step most often skipped, and it is the one that catches real mistakes.

Administrators see everything, so an administrator testing MCP learns nothing about what a reader can reach. Verify with an account that has the permissions of your least-privileged intended user, and ask it the broad questions you are worried about, not the narrow ones you designed for.

If the answer surprises you, fix the permissions, not the prompt.

A note on scope creep#

MCP access tends to broaden quietly. A workspace gets added, a folder's permissions get loosened for an unrelated reason, a key issued for one integration gets reused for another. None of these are visible as an "MCP change", but each one widens what an AI client can reach.

Two habits keep it honest:

• Re-run the reader verification after any material permission change, not just after MCP changes.
• Issue one key per integration, so that revoking one does not mean breaking all of them, and so the audit log tells you which caller did what.

Related pages#

• Copilot, MCP and trust paths for the full trust-path model.
• MCP audit for what gets recorded and where to read it.
• Microsoft 365 Copilot agent and The MCP shim for desktop AI clients for each ingress in detail.
• Accounts, groups and entitlements for the permission model this all rests on.
• Plan your integrations.