MCP Connector Risk Registers for UK AI Assistants

Tools & Technical Tutorials

25 July 2026 | By Ashley Marshall

AI assistant connectors are not harmless convenience features. They are live access paths into your business systems.

Why connector risk registers matter now

MCP has made the old integration risk problem feel new again. A connector is no longer just a background sync between two systems. In an AI assistant or agent platform, it can become the route by which a model reads documents, searches inboxes, creates calendar entries, updates CRM records, queries code repositories or triggers operational workflows. That is useful, but it also changes the control question. The question is no longer only whether the software is approved. It is whether each tool exposed to the assistant has a clear owner, a justified permission set, a known data boundary, a tested audit trail and a revocation path that still works when staff, suppliers or agents change.

The MCP authorization specification is explicit that HTTP based authorization uses established OAuth patterns. It says protected MCP servers act as OAuth resource servers, MCP clients act as OAuth clients, and clients must use protected resource metadata for discovery. That is a good starting point, but it is not the same as a business control. OAuth tells you how access can be granted. A risk register records whether access should be granted, who approved it, what could go wrong and how the organisation would notice.

For a UK business, this matters because AI adoption is moving faster than normal SaaS governance. Teams are connecting assistants to Google Workspace, Microsoft 365, Slack, Notion, GitHub, HubSpot, Salesforce, Jira and internal databases. Many of those systems already hold personal data, commercial secrets or regulated records. The risk is not a science fiction agent escaping its sandbox. The more ordinary risk is a helpful assistant with a broad token, poor logging and no one accountable for the connector after the initial pilot. What this means in practice is simple: every MCP server or platform connector should be treated like a live privileged integration, even when it was added through a friendly chat UI.

Start with permissions, not the assistant brand

The leading misconception is that connector risk is mainly about the AI model. In board conversations, the first question is often whether the assistant is trustworthy. That question matters, but it is incomplete. The more concrete question is what the assistant can do through each connected tool. A model with no connector can suggest a bad answer. A model with a mail, drive, CRM or ticketing connector can expose, change or transmit business data. The risk register should therefore begin with the tool inventory and permission map, not with a generic AI policy statement.

Use vendor permission models as the raw material. Microsoft Graph permissions, for example, separate delegated permissions, where the app acts as a signed-in user, from application permissions, where an app can act without a user present. Microsoft also documents granular permission names such as Mail.Read, Files.Read.All and User.Read.All. Google uses OAuth scopes across products, and its sensitive scope verification guidance distinguishes sensitive and restricted access that can require verification or additional review. These classifications are not paperwork. They are clues about where the operational risk lives.

A useful register has a row for each connector and a column for each meaningful permission. Do not record only the vendor name. Record the exact scopes, whether they are read only or write capable, whether they apply to one user or a tenant, whether admin consent is required, and whether the assistant can call the tool automatically or only after user confirmation. Add a plain-English business purpose beside each permission. If the purpose is weak, the scope is probably too broad. What this means in practice: an assistant that needs to summarise a single project folder should not receive tenant-wide file access, and a scheduling assistant should not inherit mailbox write permissions unless it truly needs to send or modify messages.

OAuth scopes are business decisions in technical clothing

OAuth can make connector approval look deceptively tidy. A user sees a consent screen, clicks approve, and the assistant works. Behind that click may be a token with access to personal data, customer communications, confidential files or source code. The OAuth 2.0 Security Best Current Practice, RFC 9700, exists because OAuth is powerful enough to need careful threat modelling. It updates earlier OAuth security advice and covers practical threats that became clearer after the original OAuth 2.0 standard was published.

MCP adds another layer because connectors can be proxied, delegated or dynamically registered. The MCP authorization specification says MCP clients must include the OAuth resource parameter in both authorization and token requests, and that the resource must identify the MCP server the token is intended for. That requirement matters because it helps prevent a token minted for one resource being casually reused elsewhere. The register should turn that into a control field: target resource, token audience, authorisation server, refresh token use, token lifetime and revocation route. If those fields cannot be answered, the connector is not ready for broad deployment.

The business decision is not whether OAuth is safe. OAuth is a protocol. The decision is whether the organisation has selected scopes that match the job, stored the token safely, limited token reuse, and made revocation operationally real. For example, if a connector uses a refresh token to maintain access to a shared mailbox, who reviews it when a project ends? If a supplier built the MCP server, where are the client credentials stored? If the assistant supports dynamic tool discovery, can it request new scopes later without a fresh governance step? These are not blockers to adoption. They are the minimum questions that keep adoption from becoming invisible shadow access.

Map data exposure before the first live pilot

The UK data protection angle is direct. The ICO guidance on AI and data protection says organisations must comply with data protection law when using AI that processes personal data. It also stresses accountability, lawful basis, fairness, transparency, security and data minimisation. A connector risk register helps make those principles visible at the point where the assistant meets real business systems. Without it, teams often discover the data boundary only after the assistant has already indexed, summarised or acted on sensitive material.

Use the register to describe data exposure in human terms. List the data categories the connector can access: customer emails, employee records, special category data, contracts, invoices, board papers, support tickets, source code, credentials, supplier documents or sales notes. Then record the data subjects affected, whether the data leaves the original system, whether it is sent to an AI provider, whether prompts and tool outputs are retained, and whether retrieval results can be shown to users who would not normally have direct access. Link this to the ICO source material so the register is grounded in UK accountability, not an internal hunch. The ICO AI and data protection guidance is a practical reference point for this review.

What this means in practice is that a connector to a CRM is not just a CRM connector. It may expose prospect notes, health information disclosed in support conversations, employee names, sales forecasts, pricing and complaint history. A connector to Google Drive or SharePoint is not just a document search feature. It may bridge old folder permissions into a conversational interface that makes oversharing much easier to miss. The risk register should therefore include a data minimisation decision for every connector: what is deliberately excluded, what is allowed, and what technical guardrail enforces the boundary.

Treat audit trails as a launch requirement

A connector that cannot be audited should not be treated as production ready. This is where many AI assistant pilots are weaker than conventional software projects. Teams test whether the assistant gives useful answers, but they do not test whether a security lead can reconstruct what happened after a bad answer, a mistaken update or a suspected data leak. The NCSC guidance for secure AI system development tells providers of AI systems to build secure systems across the lifecycle, including secure design, development, deployment and operation. That is a useful lens for connector governance because MCP connectors sit exactly at the boundary between AI behaviour and operational systems.

The NCSC secure AI system development guidance applies to systems built from scratch and systems built on top of other tools and services. That second phrase is important for UK businesses adopting AI assistants. Most deployments are not pure engineering projects. They are assemblies of hosted models, agent platforms, SaaS apps, OAuth grants, vector stores, MCP servers, workflow tools and identity providers. The audit trail has to follow that assembly, not just the application front end.

A practical audit column set includes: user who initiated the request, assistant or agent identity, connector called, tool arguments, data source queried, records returned, action taken, approval step, model output, downstream system update, token used and correlation ID. For higher risk tools, keep before-and-after state for write actions. For example, if an assistant updates a HubSpot deal, creates a Jira ticket, posts to Slack or modifies a Microsoft 365 calendar, the audit log should show the originating prompt and the exact API action. The counterargument is that detailed logging creates privacy and storage risk. That is true, so log deliberately. Mask secrets, avoid retaining unnecessary personal data, set retention periods and protect logs as sensitive records. The wrong answer is not less logging. It is ungoverned logging.

Build the register as a living control, not a spreadsheet graveyard

The risk register only works if it remains connected to operations. A one-off spreadsheet created during procurement will be out of date as soon as a team adds a new connector, changes a scope, swaps an MCP server, turns on agent autonomy or expands a pilot from five users to fifty. The register should be owned by a named role, reviewed on a fixed cadence, and tied to identity, change management and incident response. For smaller UK businesses, that does not require enterprise ceremony. It requires a disciplined list of connectors, owners, scopes, data classes, controls and review dates.

Use a simple scoring model. Likelihood should reflect exposure, maturity and autonomy: how many users can invoke the connector, how broad the token is, whether it can write, whether it can run without human confirmation, and whether supplier or public endpoints are involved. Impact should reflect data sensitivity, business criticality, customer harm, regulatory exposure and recovery difficulty. Then record required controls: least privilege, admin approval, allowlisted MCP servers, per-client consent, exact redirect URI matching, token rotation, explicit user confirmation for writes, sandbox testing, alerting and quarterly recertification.

The MCP security best practice guide names a specific attack that belongs in the register: the confused deputy problem. It describes how an MCP proxy server using a static client ID, dynamic client registration and consent cookies can allow malicious clients to obtain authorization codes without proper consent unless per-client consent and redirect URI validation are implemented. That is the kind of named example that turns the register from generic risk language into engineering reality. The answer to the common objection, “surely the platform vendor handles this”, is partial. Vendors provide controls, but the business still decides which connectors are enabled, which scopes are approved, which data is reachable and what level of evidence is acceptable before launch.

Frequently Asked Questions

What is an MCP connector risk register?

It is a structured record of every MCP server or AI assistant connector, including its owner, business purpose, exact permissions, OAuth scopes, data exposure, controls, audit evidence, review date and revocation process.

Is this only needed for regulated businesses?

No. Regulated firms have stronger evidence requirements, but any UK business connecting assistants to email, files, CRM, support tickets or finance systems should track connector risk because those systems commonly contain personal and commercially sensitive data.

What permissions should be captured?

Capture exact OAuth scopes and platform permissions, including whether they are delegated or application permissions, read or write capable, user level or tenant wide, and whether admin consent was required.

How does this relate to UK GDPR?

The register supports accountability, security and data minimisation by showing what personal data each connector can access, why that access is needed, who approved it and how access can be reviewed or revoked.

Who should own the connector register?

Ownership usually sits with security, IT or operations, but every connector should also have a business owner who can justify the purpose and confirm the access is still needed.

How often should connectors be reviewed?

Review high risk connectors at least quarterly, and review any connector immediately after a scope change, supplier change, incident, staff role change or expansion from pilot to production.

Do vendor consent screens remove the need for a register?

No. Consent screens help users understand access at approval time, but they do not replace an operational record of purpose, controls, data exposure, audit logging and revocation testing.

What is the first practical step?

Inventory every live AI assistant connector, export its exact scopes from the identity or app platform, then remove any connector whose owner, purpose or revocation route is unclear.