Learn how to classify, approve, and govern MCP server connections. Understand the risk difference between sanctioned and unsanctioned MCP servers in 2026.
Security teams are asking a question they could not have anticipated two years ago: "What tools does this AI agent actually have access to?" The answer lives inside the MCP server.
MCP (Model Context Protocol) is an emerging open standard that connects AI agents to external tools, data sources, and services. Think of an MCP server as a capability broker. An agent connects to it, discovers what tools are available, and then calls those tools to take real-world actions: reading files, querying databases, sending emails, modifying records. The agent does not hard-code these capabilities. It discovers them at runtime, from whatever the MCP server exposes.
That dynamic discovery is the governance problem. Tools inside an MCP server are only visible at runtime. A static configuration review cannot tell you what a server will expose when an agent connects. This is the black box problem at the heart of MCP security.
The scale of this problem is accelerating. One enterprise security team discovered that MCP connections in a single AI coding environment were doubling quarter over quarter. Industry security frameworks have begun cataloging shadow MCP servers as a top-tier MCP security risk, and analysts increasingly describe MCP servers as a new form of shadow IT inside AI infrastructure. The governance gap is real, it is growing, and it starts with a classification problem: which of your MCP servers are sanctioned, and which are not?
For a broader view of how this fits into your overall AI agent governance program, the MCP layer is one of the most under-governed components in the stack.
The difference between sanctioned and unsanctioned MCP servers is not technical. It is procedural. Both types may be running identical software. Both may be reachable by the same agents. The distinction is whether the server has been reviewed, approved, and inventoried by a security team with the authority to make that call.
AttributeSanctioned MCP ServerUnsanctioned (Shadow) MCP ServerSecurity review statusCompleted and documentedNoneTool inventory visibilityKnown and approvedUnknownOwner on recordYes, with contactNone or unclearAuthentication requirementEnforcedOften absentData access scopeAssessed and boundedUnassessedRisk classificationAssignedUnknown by defaultRecommended actionMonitor and maintainImmediate review or blockCompliance postureTrackableExposure risk
An unsanctioned MCP server is not automatically malicious. A developer may have stood one up to accelerate a workflow. A business team may have connected a third-party service without realizing it introduced a new tool surface. The danger is not intent. The danger is that the security team is ghost chasing: reviewing theoretical configuration signals with no runtime evidence of what tools that server exposes or what data those tools can reach.
Industry security frameworks now name shadow MCP servers as a critical risk category because they operate outside formal security governance and expose organizations to data breaches and compliance violations without any visible trigger. An unsanctioned server is the highest-risk class in your MCP inventory by definition, because its tool behavior is unknown.
Understanding what shadow AI looks like across your SaaS environment is the prerequisite for understanding shadow MCP servers. The same proliferation dynamic applies, but the stakes are higher because MCP servers enable agents to take actions, not just receive data.
Security teams cannot govern what they cannot see. The governance workflow for sanctioned vs. unsanctioned MCP servers follows four sequential steps. Skipping any step leaves the program incomplete.
The first question is: what MCP servers exist in your environment? This includes servers registered in agent builder platforms (Copilot Studio, n8n, Amazon Bedrock, Salesforce Agentforce), servers referenced in workflow configurations, and servers that agents are connecting to at runtime but that no configuration file explicitly lists.
Discovery requires both configuration-layer scanning and runtime observation. Configuration scanning finds servers that are declared. Runtime observation finds servers that agents are actually reaching, including connections that were never formally declared anywhere. These are the shadow MCP servers. They will not appear in any spreadsheet or platform dashboard until you look at what agents are actually doing.
One enterprise security team found hundreds of Copilot agents they did not know existed through a single assessment pass. The MCP connections attached to those agents represented an entirely unreviewed tool surface. Building a complete AI agent visibility baseline is the prerequisite before any MCP classification work can begin.
Once you have a discovery output, every MCP server receives one of two initial classifications: sanctioned or unsanctioned. Apply the classification based on one question: has this server completed a documented security review with an assigned owner on record?
If yes: sanctioned. If no: unsanctioned, pending review.
Do not let "we think it's fine" serve as a substitute for "we reviewed it." That substitution is exactly how theoretical configuration becomes a ghost chase.
Classification is not the end of the review. A sanctioned server still requires an effective authority assessment: what can the tools on this server actually do inside the SaaS applications and data systems it connects to?
This is where most governance programs stop too early. Knowing that a server is approved tells you nothing about whether the tools it exposes are operating with least privilege. A server connecting to a CRM may expose tools that can read all records, not just the records the agent's workflow requires. The effective authority of that server is far broader than its theoretical configuration suggests.
Non-human identities already outnumber human identities by 25 to 50 times in modern enterprises. AI agents are the fastest-growing non-human identity category. Each MCP connection those agents hold is an entitlement that needs the same lifecycle scrutiny as any human identity's access grant.
After effective authority assessment, each server reaches a disposition:
The AI agent governance framework that supports this workflow needs to be a living program, not a one-time audit. MCP connections change as agents are updated, workflows are modified, and new platforms are adopted.
The hardest part of governing sanctioned vs. unsanctioned MCP servers is not the classification. It is the effective authority assessment for servers that pass initial review.
Configuration is not reality. A server's declared scope (what it says it does) and its operational scope (what it can actually do when an agent calls its tools) are frequently different. This gap exists because MCP tool definitions can be broad, because the credentials attached to a server often carry permissions beyond the specific workflow, and because agents are probabilistic systems that may call tools in sequences the original developer never anticipated.
Action chaining compounds this gap. An agent connects to an MCP server, calls a file-read tool, passes that output to a second tool that queries a database, and then passes the combined result to a third tool that sends an external request. Each individual tool call may look benign in isolation. The chain produces a data exposure that no single-tool review would have flagged.
Effective authority assessment asks: given the full set of tools this server exposes, and given the credentials those tools operate under, what is the maximum blast radius if an agent uses every available tool in sequence? That answer is what the security team needs, not the answer to "what is this server configured to do."
Runtime visibility is the only mechanism that produces this picture. Retroactive log review cannot reconstruct MCP tool call sequences after the fact with sufficient fidelity. The tools inside an MCP server are only fully visible when an agent connects and the interaction is observed in real time. This is the core argument for runtime AI security over configuration-based approaches.
Individual risk factors on an MCP server are manageable. Combinations of risk factors create critical-severity exposures that require immediate action.
The highest-risk pattern in 2026 is the toxic combination of an unsanctioned MCP server attached to an agent that operates in maker mode. Maker mode means the agent runs using the credentials of its creator, not the credentials of the person invoking it. A user without Salesforce access can invoke a maker mode agent. That agent calls an MCP server tool using the creator's admin-level Salesforce credentials. The user extracts records they have no right to see. The agent did exactly what it was designed to do. Your IAM controls were bypassed entirely.
Add an unsanctioned MCP server to that scenario and the blast radius expands further. The tools on that server are unknown. The credentials it operates under are unreviewed. The agent connecting to it may be org-wide accessible, meaning any user in the organization can trigger the chain.
This is machine insider risk in its most concrete form. The agent holds credentials like a human insider. It takes actions like a human insider. But no insider risk program covers it, because no existing program was designed to govern non-human identities operating through MCP connections.
Other toxic combinations to flag during governance review:
The OAuth token abuse surface that underlies many of these scenarios is well-documented. MCP connections add a new layer to that surface because they abstract the credential behind a tool call, making the access pattern harder to trace without runtime visibility.
A governance policy for sanctioned vs. unsanctioned MCP servers needs five components to be operationally useful.
1. An approved MCP server registry. A centralized, maintained list of every MCP server that has completed security review. This registry is the single pane of glass for MCP governance. Any server not on the list is unsanctioned by default. The registry should include: server name, owner, review date, tool inventory summary, credential type, data access scope, and next review date.
2. A classification standard. Define exactly what "sanctioned" requires: completed security review, documented owner, tool inventory on file, authentication enforced, access scope bounded to workflow requirements. Define what triggers reclassification: owner departure, tool updates, credential rotation failures.
3. An approval workflow. New MCP servers require a formal request and review before agents connect to them. The review covers tool inventory, credential scope, authentication mechanism, and data access boundaries. Approvals have expiration dates. Renewals require re-review.
4. Remediation SLAs. Unsanctioned servers discovered in the environment need a defined response timeline. Critical combinations (unsanctioned plus maker mode, unsanctioned plus public access) require immediate escalation. Standard unsanctioned servers require review within a defined window before connections are flagged for restriction.
5. Continuous re-discovery. The MCP environment changes faster than quarterly reviews can track. MCP connections in some environments double quarter over quarter. Governance requires ongoing discovery, not point-in-time audits. The registry must be a living document updated by runtime observation, not just configuration declarations.
For teams building the broader program that MCP policy sits inside, AI agent governance provides the structural context for where MCP governance fits alongside agent inventory, identity management, and access control.
Runtime enforcement (the ability to block agent connections to unsanctioned servers) is the target state for mature programs. For Microsoft Copilot, runtime guardrails are on the near-term roadmap (Q1 2026), with other platforms targeting Q2 2026. Current governance programs should focus on discovery, classification, and effective authority assessment as the foundation. Enforcement capabilities are the next layer, built on top of a complete and accurate sanctioned server registry.
Intent does not determine classification. An unsanctioned MCP server is any server that has not completed a documented security review with an assigned owner on record. A developer may have legitimate business reasons for standing up a server. Until that server passes review, its tool behavior is unknown to the security team, and it carries the highest-risk classification by default. The review process is what converts it from unsanctioned to sanctioned.
Configuration scans find servers that are declared in agent builder platforms or workflow files. They do not find servers that agents connect to at runtime through dynamic discovery, servers referenced in embedded credentials, or servers that were added to an environment after the last configuration scan. Runtime observation is required to find the full population of active MCP connections.
Maker mode means an agent runs using its creator's credentials. When that agent connects to an MCP server, the tools on that server execute with the creator's permission level, regardless of who invoked the agent. An unsanctioned MCP server attached to a maker mode agent represents a toxic combination: unknown tool behavior executing at potentially admin-level privilege, triggered by any user who can reach the agent.
Theoretical configuration is what the server's setup files say it does. Effective authority is what the tools on that server can actually do inside the SaaS applications and data systems they connect to, given the credentials they operate under and the full sequence of tool calls an agent might execute. Effective authority is almost always broader than theoretical configuration, because credentials carry permissions beyond the specific workflow and agents can chain tool calls in sequences no single review anticipated.
Re-review triggers should include: tool updates on the server, credential rotation, owner account changes, agent permission changes, and scheduled periodic review (at minimum annually, more frequently for servers with broad data access). A server's sanctioned status is not permanent. It reflects the state of review at a point in time and requires maintenance.
Yes, and third-party servers often carry higher risk because the security team has less visibility into tool updates and credential management practices. Third-party MCP servers should require the same review process as internal servers, with additional scrutiny on the vendor's authentication practices, data handling commitments, and update notification procedures.