Knowledge Base · MCP & Data Products

Enterprise Copilot Agents and Connectors: What IT Admins Need to Know

What Microsoft 365 admins actually see when governing Copilot agents and MCP connectors: where the controls live, how OAuth and Entra SSO fit, user access management, and a phased rollout pattern that works.

  • Leading Investment Research Firm
  • Financial Services
  • MCP Development
  • AI Data Products

Why this page exists

Getting an MCP connector built and submitted to directories is half of enterprise distribution. The other half happens inside each customer’s Microsoft 365 tenant, where an IT admin has to find the controls, wire up identity, and decide who sees what. Node8 sat down with a leading investment research firm’s IT and engineering teams and walked the actual Microsoft 365 admin portal, end to end, ahead of rolling their data connector out to Copilot users. This page is what an admin (or a data vendor selling to admins) actually needs to know.

The controls live in Microsoft 365 admin, not Azure

First point of confusion in our session: everyone’s instinct was to look in the Azure portal. The Copilot agent and connector governance surface lives in the Microsoft 365 admin center. That’s where you’ll find:

  • The connector catalog for the tenant — public connectors from established data vendors are visible there by default, alongside anything your own organization has created.
  • The option to create custom agents — the older, declarative-agent route that predates first-class MCP support. It still exists; for a data connector use case, you likely don’t need it anymore.
  • A “connect to MCP server” option — the newer path, and the important one. It lets a tenant point Copilot directly at a remote MCP server.
  • “Manage user access to Copilot products and services” — the section governing which users get which Copilot capabilities.

Entra (Azure AD) enters the picture only where it should: as the identity provider behind sign-in.

The direct MCP connection is your pilot lane

The most useful discovery in our review: a tenant does not have to wait for a connector to appear in the Microsoft marketplace. The direct “connect to MCP server” path let the firm enable its own connector for internal users as a proof of concept while the formal marketplace submission was still in review.

That matters for two audiences:

  • Admins get a low-risk way to evaluate a connector with a pilot group before any marketplace commitment.
  • Data vendors get real enterprise usage — and feedback — weeks or months before a listing goes live.

One caution we flagged and verified rather than assumed: the sign-in and access flows are not guaranteed to be identical between the marketplace path and the direct-connection path. If you pilot on one and launch on the other, re-test authentication and user access on the launch path.

Identity: OAuth, Entra, and the per-organization pattern

Connecting an MCP server to Copilot in an enterprise requires OAuth 2.0 / OIDC — anonymous or API-key connectors don’t fit the enterprise model. The pattern we implemented, which generalizes to any vendor-to-enterprise connector:

  1. The connector’s identity layer (a hosted platform such as WorkOS, in our build) defines an organization per enterprise customer.
  2. The organization is bound to the customer’s trusted email domains.
  3. SSO is configured against the customer’s Entra tenant via OIDC, so employees authenticate with the corporate identity they already have — no new credentials, and offboarding is inherited from the directory.
  4. The customer’s IT contact can complete the SSO configuration through a delegated admin flow — the vendor doesn’t need credentials into the customer’s tenant, and the admin doesn’t need to understand the vendor’s stack.

The firm used itself as the first “enterprise customer” to prove this pattern before offering it externally. That’s worth copying: your own tenant is the cheapest place to find the sharp edges. Onboarding each subsequent customer is then configuration — organization, domains, SSO — not engineering.

One cosmetic note admins ask about: the vendor’s logo appearing on the Microsoft sign-in screen requires the vendor to complete Microsoft Partner verification. Its absence doesn’t affect functionality — an unbranded sign-in page still works — but vendors should have it on their roadmap because enterprise users notice.

User access: decide who sees it before anyone sees it

The governance question that consumed the most discussion wasn’t “can we connect it” but “who will see it once we do.” Two honest findings from working through it:

  • The M365 admin center’s Copilot access controls (“Manage user access to Copilot products and services”) are the lever, and they operate at the level of users and Copilot capabilities.
  • Fine-grained per-connector visibility — this connector for these users only — required genuine investigation rather than being obvious from the portal. Our rule became: do not connect anything tenant-wide until you have demonstrated, in your tenant, exactly which users can see and invoke it. Test with a scoped group first.

Also inventory licensing before you plan the pilot: only users with Copilot licenses can use connectors at all. The firm started by identifying which employees already held licenses and built the pilot group from them — no procurement dependency in phase one.

A phased rollout that works

The sequence we settled on, which we’d recommend to any organization deploying a data connector into Copilot:

  1. Inventory — who has Copilot licenses; who owns the M365 admin role; who owns Entra.
  2. Direct-connect a pilot — use the MCP server connection for a small internal group; verify OAuth end to end, including token refresh during long sessions.
  3. Prove the access model — confirm which users can see the connector, and document the steps.
  4. Configure enterprise SSO — organization, trusted domains, Entra OIDC; have the IT contact run the delegated flow so the process is validated as self-service.
  5. Expand internally, then extend to external customers, repeating the organization + SSO pattern per customer.
  6. Switch to the marketplace listing when approved — and re-test auth and access on that path before migrating users.

Work with Node8

Node8 works both sides of this table: we build production MCP connectors for data owners, and we’ve walked enterprise M365 admin portals with IT teams to get them governed and rolled out. If you’re deploying — or shipping — a Copilot connector and want the access model right the first time, talk to us.

Frequently asked questions

Where do admins manage Copilot connectors — Azure or Microsoft 365?

The Microsoft 365 admin center, not the Azure portal. Copilot's agent and connector controls, including connecting to an MCP server and managing user access to Copilot products and services, live in M365 admin. Entra (Azure AD) only enters as the identity provider for SSO.

Can a tenant connect to an MCP server before it's in the Microsoft marketplace?

Yes. The M365 admin center offers a direct 'connect to MCP server' option, so an organization can enable a custom MCP connector for its users without waiting for marketplace listing — ideal for internal pilots while a directory submission is in review.

How does authentication work for an enterprise Copilot MCP connector?

The connector requires OAuth 2.0/OIDC. The clean enterprise pattern: the connector's identity layer defines an organization per customer with trusted domains, and SSO is configured against the customer's Entra tenant via OIDC — so employees sign in with their existing corporate identity.

How do you control which users see a connector?

Through the Copilot user-access controls in the M365 admin center ('Manage user access to Copilot products and services'). Plan a deliberate pilot group first — and verify the access model for your path, because marketplace and direct-connection paths don't behave identically.

What should the rollout order be?

Internal users first — employees who already hold Copilot licenses — then external enterprise customers once the access model and SSO pattern are proven. Each new customer is then an identity-layer organization plus an SSO configuration, not new engineering.