Use self-hosting for sensitive, regulated, or latency-critical integrations where you need control over data and credentials. Use proxying for lower-risk SaaS connections and early experimentation. Most enterprises will need a hybrid model, but only if a gateway preserves one policy and logging standard across both paths.
Why This Matters for Security Teams
Whether an MCP server is self-hosted or proxied is really a question about who controls trust boundaries, secret handling, and enforcement points. For agentic systems, that matters because a model-driven workflow can chain tools, expand scope, and exfiltrate data faster than a human review cycle can react. NHIMG research on MCP security found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which turns deployment choice into an immediate exposure decision rather than a purely architectural preference. Current guidance from the OWASP Top 10 for Agentic Applications 2026 treats tool access, secret handling, and overbroad delegation as first-order risks.
Security teams often assume a proxy reduces risk by default, but that only holds if the proxy actually governs authentication, authorization, logging, and secret mediation instead of merely relaying traffic. Self-hosting can improve control, but it also shifts responsibility for hardening, patching, and operational separation onto the organisation. In practice, many security teams discover the difference only after an MCP tool has already been granted broader access than intended, rather than through intentional design review.
How It Works in Practice
The practical choice is not “proxy versus self-host” in isolation, but where policy enforcement, credential issuance, and audit logging live. Self-hosting is usually preferred when MCP connects to regulated data, internal systems, or latency-sensitive workflows, because the organisation can bind the server to internal identity controls, network segmentation, and local secret stores. Proxying is often acceptable for lower-risk SaaS integrations or pilot use, especially when the gateway can mediate tokens, redact payloads, and enforce a single logging standard. The key is that the proxy must be more than a traffic relay; it should become the policy decision and inspection point.
For agentic deployments, current best practice is evolving toward short-lived credentials, workload identity, and runtime authorization. That means the MCP path should not inherit long-lived API keys from a developer workstation. Instead, a gateway can issue ephemeral credentials per task, validate the calling agent’s workload identity, and apply request-time policy based on context such as data sensitivity, tool type, and environment. This aligns with the risks described in NHIMG’s The State of MCP Server Security 2025 and the OWASP Agentic Applications Top 10, both of which emphasize tool-scoped control and secret minimization.
- Use self-hosting when you need local control over secrets, data residency, and privileged integrations.
- Use proxying when the gateway can enforce policy-as-code, log every tool call, and issue short-lived credentials.
- Keep one authorization model across both paths so the same tool cannot be less restricted simply because it is proxied.
- Tie access to workload identity rather than static user roles, especially for autonomous agents that change behaviour by task.
These controls tend to break down when the proxy cannot see downstream context, such as nested tool calls, opaque SaaS scopes, or delegated actions inside third-party execution environments.
Common Variations and Edge Cases
Tighter gateway control often increases operational overhead, requiring organisations to balance governance consistency against delivery speed and integration complexity. A hybrid model is usually the right answer, but only if it avoids two common failures: one path for “trusted internal” MCP servers and another for “everything else,” and separate logging or policy formats that make audit reconstruction impossible. There is no universal standard for this yet, so teams should treat gateway design as a control-plane decision, not a deployment convenience.
Edge cases include low-latency automation where a proxy adds unacceptable delay, air-gapped environments where proxying is unnecessary, and vendor-managed MCP servers where self-hosting is not an option. In those cases, the minimum bar is still the same: scoped credentials, explicit tool allowlists, and complete traceability across requests and responses. For organisations building out agent governance, Analysis of Claude Code Security shows why tool access decisions should be reviewed as part of broader agent behaviour, not just infrastructure placement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A4 | Addresses agent tool abuse and overprivileged integrations. |
| CSA MAESTRO | M1 | Covers governance of agentic control planes and delegated execution. |
| NIST AI RMF | GOVERN | Supports accountability for autonomous agent access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Relevant to hard-coded and long-lived secrets in MCP deployments. |
| NIST CSF 2.0 | PR.AC-4 | Applies least-privilege access to MCP servers and gateways. |
Restrict MCP tools to the minimum task scope and review each action path at runtime.
