MCP Governance: Access Control, Authentication and Audit for AI Connectors Across the Company

Why MCP needs governance at all

MCP, the Model Context Protocol, is how Claude, ChatGPT and Copilot connect to your CRM, file store, finance system and internal tools. Each connection is an MCP server. The protocol defines how the assistant and the server talk and how a user signs in. It does not decide which servers your company allows, which teams get which tools, or whether the AI may change data. Those are company decisions, and if nobody makes them, every employee makes them alone.

That is the situation in most companies a year into AI use: connectors set up by whoever needed them, some with write access, some with an admin key, none written down. Our MCP security guide covers the risks that follow. Governance is how you stop it being each person’s call.

The five decisions

How MCP authentication works

People searching for “MCP authentication” usually want to know whether the AI uses their account or someone else’s. The MCP authorization specification answers it in a few rules:

• It is built on OAuth 2.1, the same family of standards behind “Sign in with Microsoft” or “Sign in with Google”. The user signs in to the system and approves access; the AI client receives a token, not the password.
• It is optional, and depends on the transport. Remote servers reached over HTTP should follow the OAuth flow. Local servers that run on a person’s own machine over stdio do not use it; they take credentials from their environment, which in practice often means an API key in a configuration file.
• The MCP server is a protected resource. It must publish metadata that tells the client which authorization server to sign in with, so the client does not have to guess.
• Tokens are bound to one server. The client names the server it wants a token for, and the server must check that a token was issued for it. A server must not pass a token it received on to another service.
• Clients register in standard ways. The 2025-11-25 revision made Client ID Metadata Documents the default way for a client to identify itself, with dynamic client registration still supported.

The current revision of the specification, dated 28 July 2026, keeps this model and tightens it further. The point for a leader is simpler than the RFC numbers: the protocol already supports each person signing in as themselves. Whether that happens depends on how each connection is set up.

Per-user tokens or service accounts

Every connection uses one of two identities. Most companies end up with both, and should know which is which.

The rule of thumb: per-user tokens wherever the system supports them. Where it does not, use a service account that is read-only, scoped to what the use case needs, and reachable only by the groups that need it, so the gateway or connector decides who may use it and logs who did.

MCP access control per group

Access control is where governance becomes visible to employees. Set it per group, not per person, and take the groups from the directory you already manage, such as Entra ID or Google Workspace, so nobody keeps a second list in sync.

The example is illustrative; yours will differ. Two patterns are worth copying. Writing is the exception, granted per system where it saves real time. And tools that send data out, such as email, start as drafts a person sends, because that breaks the chain the security guide calls the lethal trifecta.

The assistants’ own admin settings cover part of this. On ChatGPT Business, apps can only be switched on or off for the whole workspace, while Enterprise adds control per role; see ChatGPT Business vs Enterprise. Claude Enterprise adds SCIM and audit logs that Team lacks; see Claude Team vs Enterprise. Neither sets the same rules across all three assistants, which is the gap an MCP gateway fills.

Audit logs: what to record

An auditor, a client or your own incident review will ask the same question: what did the AI do, for whom? A useful log answers it without anyone reconstructing events from five systems.

• Who: the named person, not only a service account.
• From where: which assistant, such as Claude, ChatGPT or Copilot.
• What: which server and which tool, and whether it read or wrote.
• When, and whether it succeeded or was refused.
• Kept for a period you chose, and exportable to your own security tools.

Logs contain personal data too: names, and often what people asked for. Decide who may read them and how long they are kept, as you would for email logs. Our guide to AI data governance covers the data side.

Who owns what

Governance fails most often because nobody owns it. Name the roles, even if one person holds several.

Add one short route for requests: a person asks for a new connector, the system owner decides, IT adds it. If that takes weeks, people go back to connecting things themselves, and you are back to shadow AI. The same rules belong in your AI policy, which tells people which tools are approved and what data may go into them.

Enterprise MCP and the AI control plane

“Enterprise MCP” is usually shorthand for running MCP across a whole company rather than one person’s laptop: remote servers instead of local ones, company sign-in, access by group, logs and an approved list. “AI control plane” is the name for the layer that holds those rules. It borrows the term from networking, where the control plane decides where traffic may go and the data plane carries it.

An AI control plane decides which systems AI may reach, for which people, under which rules, and records what happened. Most products sold under the name are an MCP gateway with more added, such as company skills, guardrails and discovery of unsanctioned tools. As assistants become agents that act on their own, the same layer is where you govern them; see AI agent governance.

The MCP governance checklist

• An inventory of every MCP server and connector in use, in which assistant, with whose login.
• An approved list of servers, with a named owner for each.
• A review step before any community or third-party server is added.
• Per-user OAuth wherever the system supports it; shared keys replaced or made read-only.
• Access set per group from your identity provider.
• Read-only as the default; write access granted per system and group.
• Human approval for anything that sends, publishes, pays or deletes.
• A log of every call: who, which assistant, which tool, when, kept and exportable.
• Offboarding that removes AI access in the same step as everything else.
• A short route for requesting a new connector, with an answer in days.
• A review every six months of what is used, what is not, and what should change.

Where Deployed OS fits

Deployed OS is an MCP gateway built to hold these decisions. Your systems are connected once and used from Claude, ChatGPT and Copilot, through the same MCP connection in each. Each person signs in with their own login where the system allows it, user groups decide who may read or write in which system, and every call is logged and can be exported. Company skills and guardrails come with every question, so the rules apply the same way in every assistant. It is built by an EU company, and you choose where the data is stored.

If you want the checklist above set up on your own systems rather than in a document, we connect Deployed OS with your team and show exactly what each group can reach. See every connector.

Frequently asked questions