MCP Connector Inventories Should Come Before UK Teams Extend Copilot

Tools & Technical Tutorials

19 September 2026 | By Ashley Marshall

MCP makes AI assistants more useful because it lets them reach live business systems. That is exactly why UK teams need a connector inventory before the first broad rollout.

MCP has moved from developer experiment to admin decision

Model Context Protocol used to feel like something only developers needed to understand. That is changing quickly. Microsoft now describes federated Copilot connectors as MCP-based connectors that fetch external data in real time, keep the data in its original location, use the user's identity and permissions, and are managed through the Microsoft 365 admin centre. Its connector overview, updated on 1 September 2026, also lists a wide set of available data sources across finance, CRM, legal, HR, developer tools, files, project management and sales. For a UK business, that makes MCP less of a lab feature and more of an operational access layer.

The practical risk is not that MCP is bad. The risk is that connectors are enabled faster than the business can explain who owns them, what data they touch, how users authenticate, and what evidence exists when something goes wrong. A connector that only reads HubSpot, Xero, Box, Linear or a custom line-of-business system can still expose commercially sensitive context if permissions are loose, old groups are over-broad, or staff do not understand which source Copilot used in an answer.

What this means in practice is simple: before extending Copilot or another AI assistant through MCP, build a connector inventory. Treat it like a lightweight asset register. Each connector needs an owner, business purpose, data source, user group, authentication route, permitted actions, logging location, review date and stop route. If nobody can fill those fields, the connector is not ready for broad use.

Source: Microsoft's federated Copilot connectors overview.

The connector list is already broad enough to matter

The business reason to pay attention now is the breadth of available connectors. Microsoft's overview lists external systems across accounting and finance, CRM, developer tools, files and documents, HR, IT service management, legal, project management and sales. The named examples include Xero, HubSpot, Intercom, Box, Azure DevOps, Cloudflare, Linear, Notion, Google Calendar, Google Contacts, Canva, FactSet, Morningstar, S&P Global and many more. Even if only a small fraction is relevant to your organisation, that is enough to create a new governance surface.

For many UK SMEs and mid-market teams, the risk will not come from one dramatic AI deployment. It will come from a series of small, reasonable admin decisions: enable a finance connector for leadership research, let sales connect CRM data, let operations query project tools, give developers access to documentation sources, and allow HR or legal teams to test specialist sources. Each decision may be defensible on its own. Together, they create an assistant that can draw from systems that were previously separated by interface, habit and team boundary.

The counterargument is that user permissions solve this because Copilot only sees what the user can already see. That helps, but it is not the same as governance. Many businesses have inherited permissions, shared mailboxes, old project groups and data folders that are wider than anyone would approve if they were designed today. MCP connectors make those permission decisions more visible and more useful, which also makes mistakes more consequential.

What this means in practice: start with the connectors that touch customer data, financial records, HR data, supplier terms, legal material, strategic documents or operational systems. Put those in a high-attention group, even if the connector is read-only.

Read-only access still needs operational control

Microsoft's federated connector model has sensible properties. The overview says federated connectors are read-only, audited in Microsoft Purview, managed by admins, and can be limited to specific Microsoft Entra ID groups through staged rollout. It also says admins can disable connectors at tenant level, bulk disable federated connectors through allowed agent type settings, and selectively enable specific connectors based on organisational policy and readiness. Those controls are useful, but only if someone has already decided how to use them.

Read-only does not mean harmless. A read-only connector can retrieve sensitive customer complaints, pipeline forecasts, internal legal analysis, margin data, HR notes, security findings or supplier negotiations. It can also combine sources in ways staff did not expect. A user might ask a reasonable question and receive an answer grounded in material that is technically permitted but commercially inappropriate for that task. That is a permissions hygiene problem, not a model intelligence problem.

A connector inventory gives administrators a working surface for staged rollout. Instead of enabling a connector tenant-wide because it looks useful, you can list the first approved groups, the test prompts, the expected sources, the business owner and the review date. You can also record why a connector stays off. That matters for leadership because it turns AI governance from a vague caution into a visible decision log.

For smaller teams, the first version can be a spreadsheet. Useful columns are connector name, source system, data owner, admin owner, approved groups, authentication method, action type, personal data risk, commercial sensitivity, logging route, last review, next review and emergency disable route. The point is not bureaucracy. The point is being able to answer simple questions quickly.

Agent guidance raises the bar for tool access

The UK's National Cyber Security Centre has been clear that agentic AI deployments need proportionate controls around autonomy, tools, networks, oversight, monitoring and shutdown. In its August 2026 blog on managing the cyber risk of agentic AI, the NCSC says organisations should assess how much autonomy is needed, identify what could go wrong, define what agents may access, maintain human oversight where consequences are significant, log and audit activity, make AI activity easy to attribute, and preserve the ability to pull the plug.

That advice applies directly to MCP connector rollout, even where the first use case is search or research rather than autonomous action. Connectors are the bridge between language instructions and business systems. Once a business becomes comfortable with read-only retrieval, the next request is often workflow automation, write actions, ticket updates, CRM changes, spreadsheet edits or desktop control. If the inventory is missing at the read-only stage, the organisation is already behind when action capability arrives.

What this means in practice is that every connector should be tied to an autonomy level. Is the assistant only answering questions? Can it draft changes for a human to apply? Can it call a workflow? Can it update a record? Can it trigger a process in another system? Each step needs more evidence. The NCSC's language about sandboxing, oversight and shutdown is not abstract security theory. It is a way to decide when a connector needs stronger controls before it moves from useful search to operational execution.

Source: NCSC, Managing the cyber risk of agentic AI.

Identity is becoming the control plane

One of the most useful signals in Microsoft's recent agent platform changes is the shift toward agent identity. The Copilot Studio updates page says that from July 2026, Copilot Studio automatically creates a Microsoft Entra Agent ID for every new agent and that organisations can no longer opt out at the environment level. It also says agent identities can scope connector permissions, Conditional Access policies and data loss prevention governance to individual agents. That is a strong hint about where enterprise AI control is heading.

For business leaders, the lesson is that an AI assistant should not be treated as a vague extension of a user, a team or a vendor. It needs an accountable identity. That identity should be visible in the inventory, tied to a named owner, and mapped to allowed systems. Where a connector relies on user identity, the inventory should say so. Where an agent identity is used, the inventory should say which Conditional Access, DLP and logging policies apply. Where service accounts or shared credentials still exist, the inventory should flag that as a risk to remove.

This matters because investigations depend on attribution. If a user asks a question, Copilot retrieves data through MCP, the answer informs a customer decision, and a complaint follows, the business needs to reconstruct what happened. Which connector was active? Which source was queried? Which identity was used? Which user group had access? Was the answer within the intended business purpose? Without an inventory, those questions become a scramble.

Source: Microsoft Copilot Studio what's new.

Data protection still sits underneath the connector decision

MCP connector rollout is not only an IT administration issue. If a connector can retrieve personal data, the UK GDPR and Data Protection Act still matter. The ICO's AI and data protection guidance highlights accountability, governance, transparency, lawfulness, fairness, accuracy and DPIA considerations for AI systems. It also notes that the guidance is under review because of the Data (Use and Access) Act, which is a reminder that the regulatory environment is moving while businesses are already deploying tools.

The practical question is not whether every connector needs a long legal review. Many will not. The question is whether the business can recognise when a connector changes the risk profile. A connector that lets staff ask questions over public documentation is different from one that reaches customer support tickets, employee records, health information, credit data, incident reports or complaint histories. A connector that is limited to a small trained group is different from one visible to every licensed user.

A good connector inventory should therefore include a data protection column. Does the source contain personal data? Special category data? Children's data? Employee data? Customer decision data? Does the connector support only retrieval, or could it feed an automated decision workflow later? Has a DPIA been completed or ruled out with reasons? Who is accountable for that decision?

The misconception to avoid is treating MCP governance as a purely technical checklist. Technical settings matter, but they do not replace purpose limitation, data minimisation, transparency and accountability. For UK teams, the safer habit is to connect the admin inventory to the data protection register before users make the assistant part of everyday work.

Source: ICO guidance on AI and data protection.

Frequently Asked Questions

What is an MCP connector inventory?

It is a register of every MCP-based connector or agent tool enabled for AI assistants, showing what it connects to, who owns it, who can use it, what identity it uses, what data it can retrieve or change, where logs live and how it can be disabled.

Do we need an inventory if connectors are read-only?

Yes. Read-only connectors can still expose sensitive business context, personal data or commercial information. The inventory helps you prove that access is intentional, limited and reviewed.

Who should own MCP connector governance?

IT or security should own the technical register, but each connector also needs a business data owner. Finance should own finance sources, HR should own HR sources, sales should own CRM sources and so on.

Is this just for Microsoft 365 Copilot?

No. Microsoft is a timely example because federated Copilot connectors use MCP, but the same principle applies to any AI assistant that connects to tools, databases, files, APIs or business applications.

What should we check before enabling a connector?

Check business purpose, source data sensitivity, user group, authentication, permissions, logging, audit visibility, staged rollout plan, review date, data protection implications and emergency disable route.

How often should we review the inventory?

Review high-risk connectors monthly during rollout and quarterly once stable. Also review immediately when permissions, source systems, data sensitivity, connector behaviour or AI autonomy changes.

Does user-level permissioning solve the risk?

It helps, but it does not solve the whole risk. Many organisations have inherited group permissions and broad access that were tolerable in old interfaces but become more exposed when an AI assistant can retrieve and combine information quickly.

What is the simplest first step?

List every enabled connector, the source system, the first approved user group, the data owner and the disable route. That one-page view will usually reveal which connectors need deeper review.