Choose based on the level of control you need over credentials, logging, and system reach. Self-hosted deployments give more direct governance, while remote servers usually require stronger authentication and proxy controls. The deciding factor is not convenience alone, but whether you can enforce the same policy standard end to end.
Why This Matters for Security Teams
The self-hosted versus remote MCP decision is really a control boundary decision. MCP servers can expose tools, secrets, and downstream systems to AI agents, so the hosting model changes who can enforce identity checks, logging, network restrictions, and approval flows. In practice, the risk is not just where the server runs, but whether its tool access can be governed with the same discipline as other privileged workloads.
That distinction matters because MCP deployments frequently centralise sensitive credentials in configuration and tool wrappers. NHIMG research on The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files. That makes server placement inseparable from secrets handling, not a separate infrastructure choice. The same issue appears in broader agentic risk work such as the OWASP Agentic AI Top 10, which treats tool access and unsafe delegation as core governance problems.
In practice, many security teams discover the wrong hosting model only after an MCP tool has already connected to a sensitive system without the logging, scoping, or identity checks that were assumed to exist.
How It Works in Practice
Teams usually decide by asking which side can enforce the strongest end-to-end controls. Self-hosted MCP servers are often preferred when the server needs direct reach into internal systems, when credentials must stay inside a controlled network, or when detailed telemetry is required for audit and incident response. remote mcp server can still be viable, but only when the organisation can place strong authentication, proxy mediation, and policy enforcement in front of the server and accept that some operational visibility will sit outside its own boundary.
The practical question is whether the server’s trust model matches the sensitivity of the tools it exposes. For agentic workloads, static role design is often too blunt because the agent’s requests are goal-driven and dynamic. Current guidance suggests using workload identity, short-lived credentials, and policy evaluation at request time rather than relying on broad standing permissions. That is why many teams combine MCP with proxy-based authorisation, token exchange, and per-session scoping, instead of giving the server a long-lived key that can call everything all the time.
- Use self-hosted when tool execution touches internal data, regulated systems, or privileged admin actions.
- Use remote only when you can verify identity, inspect requests, and enforce tool-level policy before execution.
- Prefer ephemeral credentials and workload identity over static API keys in config files or environment variables.
- Log tool calls, arguments, and outcomes so agent behaviour can be audited after the fact.
NHIMG’s JetBrains Marketplace AI Plugin Campaign is a useful reminder that supply-chain style exposure often starts with overly trusted integrations rather than direct compromise. For implementation detail, the OWASP Top 10 for Agentic Applications 2026 reinforces the need to limit tool reach and reduce implicit trust in agent-facing components.
These controls tend to break down in highly distributed environments where remote MCP servers sit outside the organisation’s identity plane and request-level telemetry cannot be centrally enforced.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance governance against deployment speed and platform convenience. That tradeoff becomes sharper when multiple teams want to share the same MCP service across different agents, data domains, and compliance boundaries. There is no universal standard for this yet, so best practice is still evolving.
A common edge case is a hybrid model: the server is remote, but the most sensitive tools are proxied back into a self-hosted enforcement layer. That can work well when the remote service provides convenience or vendor-managed scale, while the local proxy handles secrets, rate limits, and access scoping. Another variation is a fully self-hosted server for regulated operations and a remote server for low-risk, read-only utility tasks. The key is that the hosting choice should follow the sensitivity of the tool set, not the novelty of the platform.
Teams should be especially cautious when MCP servers are used by autonomous agents that can chain tools, retry actions, or escalate from one low-risk function into a higher-risk workflow. NHIMG’s AI Agents: The New Attack Surface report shows how frequently agents act beyond intended scope, which is exactly why remote trust assumptions can fail. In these cases, the deciding factor is whether the organisation can maintain equivalent policy, logging, and credential discipline regardless of where the server runs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret exposure and rotation, central to MCP hosting decisions. |
| OWASP Agentic AI Top 10 | A2 | Tool misuse and unsafe delegation are core risks in MCP-connected agents. |
| CSA MAESTRO | TRUST-01 | Agent trust boundaries and orchestration are key to MCP deployment choices. |
| NIST AI RMF | AI governance requires risk-based controls for autonomous tool use and monitoring. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Network isolation and explicit trust boundaries underpin self-hosted vs remote decisions. |
Use short-lived secrets and enforce rotation before any MCP server gets standing credential access.
