Most MCP adoption starts on a laptop. A developer adds a server to an editor configuration, the client starts it locally, and it uses whatever credentials the developer already has. It works in minutes, which is why it spreads. Six months later a platform team discovers forty such installations, each configured slightly differently, each running as a different person, none of them visible in central logs.
The alternative is to run MCP servers as a shared service. Azure MCP Server has supported self-hosted remote deployment since version 2.0, and Microsoft's 3.0 release post lists both a local standalone server and a self-hosted remote server for team access with centrally managed configuration among the supported ways to run it. A third option, increasingly common across the market, is an MCP endpoint operated by a vendor or another team entirely.
None of the three is right for everything. The choice is an architecture decision about identity, tenancy, network and ownership, and it deserves to be made deliberately.
The three options
Local. The server runs on the user's machine, started by the client. Configuration lives in the user's editor or agent settings. It usually authenticates as the user.
Shared, self-hosted. Your platform team runs the server as a remote endpoint, for example in a container platform inside your network, with configuration managed centrally. Clients connect to it over HTTP. It authenticates users, and it reaches the cloud either with its own identity or on the user's behalf.
Remote, third-party operated. Someone else runs the endpoint: a vendor, a SaaS provider or another organisation. You configure access and trust their operation.
Compared on the four questions that matter
| Question | Local | Shared, self-hosted | Remote, third-party |
|---|---|---|---|
| Whose identity reaches the cloud? | Usually the user's own credentials, with all their rights | A service identity, or the user's via delegation; your choice | Whatever the provider's model allows; check carefully |
| Who can see requests and results? | The user's machine and the model provider | Your platform, your logs, plus the model provider | The operator, plus the model provider |
| Who controls version and tool list? | Each user | The platform team, once | The operator; you may not get notice |
| Who is on call? | Nobody in particular | The platform team | The operator, under their terms |
Identity is the deciding question
The single largest risk in local deployment is identity. A local server running under a developer's credentials gives the agent everything that developer can do, across every subscription they can reach, including standing rights from old incidents. Read-only mode and tool filtering, discussed in Part 1, reduce exposure, but they are settings in a file each user controls.
A shared server lets you choose. Two patterns are common:
- Service identity. The server reaches Azure as its own workload identity with narrow, workflow-specific roles. Every user gets the same authority, so the authority must be suitable for every user. Audit logs in Azure show the service identity; the server's own logs must record which user asked.
- Delegated identity. The server acts on behalf of the signed-in user, so Azure enforces that user's rights. This keeps the familiar permission model, but it also means a user with broad rights gives the agent broad rights.
Both patterns exist for Azure MCP Server in practice. The project's README notes that the server can be self-hosted on Azure Container Apps and recommends following Microsoft's security guidance, including enabling Entra ID authentication. Microsoft Learn documents an on-behalf-of deployment, in which the server calls Azure as the signed-in user so each user's own RBAC applies, and a managed identity deployment for Microsoft Foundry, in which every caller shares the container app's identity. The choice between them is the choice above, made concrete.
Whatever the pattern, an unauthenticated shared MCP endpoint inside the network is not a shortcut; it is an internal service that will run tools for anyone who can reach it.
Tenancy and data
A shared server serves many users, which raises the question the MCP security review asks directly: can one user cause the agent to access another user's data? With a service identity, the answer is often yes unless the server enforces per-user scope. With delegation, Azure enforces it, but any caching or state inside the server must not leak across users.
A simple test settles it before launch. Sign in as two users with different rights, for example an engineer who owns the dispatch resource groups and one who does not. Ask each the same question about a dispatch resource. With delegation, the second user should be refused by Azure. With a service identity, both will get an answer unless the server itself checks scope, and if both do, the design has quietly given every user the service identity's view. Then repeat the first user's question as the second user straight afterwards, to make sure no cached result from the first session is served to the second.
Remote third-party endpoints add a further question: where does the data go? Tool requests and results pass through the operator's infrastructure. That is a processing arrangement under POPIA and a contractual question, not only a technical one.
Network and observability
Local servers are invisible to central monitoring unless you deliberately collect from endpoints. Most run over the stdio transport, as a child process of the client, so there is no network hop to observe at all. A shared server uses an HTTP transport, which is what makes central logging, rate limits and a proxy in front of it possible. The MCP 2026-07-28 revision helps here: it requires Mcp-Method and Mcp-Name headers on Streamable HTTP POST requests, so a proxy can see which method, and for a tool call which tool, each request targets without parsing the body. Shared servers give you one place to log every tool call with user, tool, parameters, result size and duration, one place to apply rate limits, and one place to switch something off. That is the same argument that makes an enterprise MCP gateway attractive; for a single heavily used server, the server itself can carry some of those controls.
Ownership is the hidden cost
A shared server is a production service. Someone must patch it, upgrade it under change control (Part 5), watch its errors, rotate its credentials and answer when it is down. Teams that move from local to shared without assigning that ownership often end up with something worse than forty laptops: one unowned service that everybody depends on.
A practical progression
Sedgefield Freight is fictional, and its systems and figures are illustrative. Sedgefield's path is typical:
- Local, controlled. During the pilot, developers run the server locally from a standard configuration file in the platform repository, pinned version, read-only, short tool list, and a dedicated pilot identity rather than their own credentials where the workflow allows.
- Shared for the common workflow. Once the Advisor-to-Terraform workflow is proven, the platform team hosts one shared server for it, with Entra ID authentication, a service identity with Reader on the relevant resource groups, and central logging.
- Local remains for exploration, in development subscriptions only, with the standard configuration.
- Third-party endpoints go through the same review as any SaaS that processes company data.
The decision rule Sedgefield adopted: anything more than one team depends on runs shared and owned; anything that touches production runs shared and owned; local is for learning.
Next: Part 7, From prompt to change record. All parts are on the series page.
How CloudNala can help
CloudNala helps platform teams decide where MCP servers should run. We inventory local installations, choose the identity pattern for each workflow, design and deploy shared servers with authentication, logging and ownership, and set the review for third-party endpoints. The result is a small number of owned services instead of an unknown number of laptops.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Readiness Review or write to us at consult@cloudnala.co.za