Self-Hosted vs Vendor-Hosted MCP Servers for Slack, Google Drive, and SharePoint

Define the deployment models before comparing them

An MCP server is the connection point between an AI assistant or agent and external tools, APIs, and data sources. For Slack, Google Drive, and SharePoint, it sits between the agent and the platform. It receives tool calls, uses a credential to call the platform, and returns content to the agent. Wherever that server runs becomes part of the data path.

"Self-hosted" needs a precise definition. Cloud deployment models can be private, on the premises of the consumer or on a provider's dedicated infrastructure, or public. A server on provider-dedicated infrastructure is not the same as one in an environment your own team operates. For this comparison, self-hosted means the server runs in infrastructure your enterprise operates and controls. Vendor-hosted means the provider operates the server and the infrastructure under it.

The distinction matters because, in a provider-operated cloud service, the consumer generally does not manage the underlying network, servers, operating systems, or storage. Control is limited to the configuration the provider exposes. The practical question is which layers you can configure or inspect in each model.

Self-hosted vs vendor-hosted against six boundary criteria

The table summarizes how each model typically behaves against each criterion. Treat the vendor-hosted column as a set of questions to verify per provider, because implementations differ.

• Data path: Self-hosted: requests and retrieved content pass through infrastructure you operate. Vendor-hosted: they pass through the provider's infrastructure before reaching the agent.
• Token and credential custody: Self-hosted: tokens sit in your secret store under your access rules. Vendor-hosted: the provider holds tokens, so its storage and access practices become your exposure.
• Retention and logs: Self-hosted: you set what is written and for how long. Vendor-hosted: request, response, and diagnostic data may persist outside your boundary under the provider's terms.
• Residency: Self-hosted: processing location follows where you deploy. Vendor-hosted: it follows the provider's regions and sub-processing, which you must confirm.
• Tenant isolation: Self-hosted: isolation is a property of your own deployment. Vendor-hosted: you depend on the provider's separation between customers.
• Auditability: Self-hosted: you can inspect the runtime and export records directly. Vendor-hosted: evidence depends on what the provider exposes and how it can be exported.

Applying the criteria to Slack, Drive, and SharePoint

The three platforms hold different kinds of client data, but the boundary logic is the same. Slack holds conversational content and channel history. Drive and SharePoint hold documents and the sites or folders that organize them. In each case, content retrieved by a tool call travels through the MCP server on its way to the model. A vendor-hosted server therefore processes that content, at least transiently, outside your boundary.

Credentials deserve separate attention. The server acts with an identity granted through OAuth or similar authorization. Its reach is bounded by the scopes it requests and the permissions of the account behind them. Broad scopes widen what any caller of the server can retrieve, regardless of where it runs. In a vendor-hosted model, the provider holds that token, so the scope decision and the custody decision are split across two parties.

Residency and retention follow the same split. The platform's own controls govern where data sits at rest. The MCP server adds a second location where data is processed and possibly logged. When you assess client contractual obligations, assess both. A compliant source platform does not make the intermediary compliant by association.

Self-hosting does not control what an agent does with data

Self-hosting moves the server inside your boundary. It does not decide whether a given tool call should be allowed, whether a retrieved document should reach the model unmodified, or whether an agent should be permitted to write to a channel or share a file. An agent with legitimate access to a SharePoint library can still retrieve content it should not combine, summarize, or forward. Location and behavior are separate problems.

This is why the policy decision point should be assessed independently of the server. Zero trust guidance allows the policy engine and administrator to be either an enterprise-local asset or a cloud-hosted service, and describes the agent/gateway pattern as the most common deployment at the application layer. For MCP, that means a point in the execution path where individual tool calls can be evaluated and then allowed, redacted, or blocked. That point can sit in front of a self-hosted server or in front of a vendor-hosted one, and in either case it produces a record of what was permitted and what happened.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, at the level of individual tool calls. It generates audit-ready evidence from that enforcement and supports self-managed deployment in the customer cloud, with configurable retention and data residency. The comparison above holds whether or not you use it.

Governance practices that apply in either model

Assign a system owner to every MCP deployment. System-specific controls are the primary responsibility of the system owner and the authorizing official, and that applies whether the server is yours or a provider's. For vendor-hosted servers, document the shared-responsibility split in writing, since your control over the underlying infrastructure is limited.

Inventory MCP servers, including ones nobody approved. OWASP lists Shadow MCP Servers in its MCP Top 10: unapproved or unsupervised deployments outside formal governance, often created for experimentation and often using default credentials, permissive configurations, or unsecured APIs. A self-hosted model does not prevent this. It can make it easier for individual teams to stand up servers on their own.

Harden the server as you would any remote-access intermediary. A compromised intermediary can be used to eavesdrop on and manipulate communications and as a jumping-off point to other hosts, so placement matters.

• Name a system owner and authorizing official per MCP deployment
• Remove default credentials and permissive configurations
• Discover and review unsanctioned MCP servers
• Define whether the enforcement point is enterprise-operated or cloud-hosted
• Confirm that evidence can be exported to your own records