Choose based on where you need control over credentials, logs, residency, and revocation. Managed gateways reduce operational burden, but self-hosted or VPC-native options may be necessary when policy, jurisdiction, or containment requirements demand tighter ownership of the runtime.
Why This Matters for Security Teams
Managed and self-hosted MCP gateways are not just deployment choices. They define who controls credential handling, request logging, policy enforcement, and revocation when an agent or tool misbehaves. For teams building around MCP, the gateway becomes part of the trust boundary, so the decision affects containment, auditability, and how quickly secrets can be withdrawn when a tool is abused.
This is why practitioners increasingly treat gateway placement as an identity and governance issue, not an infrastructure preference. The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which makes runtime ownership of logs, secrets, and revocation especially consequential. Standards guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity, logging, and protective controls should be designed around risk, not convenience.
In practice, many security teams encounter gateway exposure only after a token, connector, or tool path has already been overused outside its intended scope.
How It Works in Practice
The decision usually starts with three control questions: where are secrets issued, who can inspect logs, and how fast can access be revoked? A managed gateway is attractive when the priority is speed and the provider can demonstrate acceptable logging, retention, and admin separation. A self-hosted or VPC-native gateway is usually preferred when policy demands stricter residency, custom inspection, or direct control over the control plane.
For MCP specifically, teams should map gateway choice to the lifecycle of tool credentials. If a gateway mints or brokers secrets, it should support short-lived issuance, scoped tool permissions, and immediate revocation when a session ends. That aligns with NHIMG guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which emphasizes lifecycle discipline rather than static trust. It also fits the practical lessons in the Top 10 NHI Issues, where credential sprawl and weak scoping are recurring failure modes.
- Use managed gateways when the provider can prove strong isolation, audit visibility, and rapid revocation.
- Use self-hosted gateways when jurisdiction, residency, or containment requirements outweigh operational simplicity.
- Prefer short-lived tokens and per-tool scopes over shared, long-lived secrets.
- Require immutable logs that capture tool calls, identity context, and revocation events.
- Validate whether the gateway supports policy-as-code and runtime enforcement, not just static allowlists.
Current best practice is to pair gateway placement with workload identity, so the runtime proves what it is at request time rather than relying on a human-managed credential vault alone. This is consistent with the direction of the OWASP Agentic AI Top 10, which stresses runtime abuse pathways and tool misuse. These controls tend to break down in highly distributed hybrid estates where multiple teams independently manage connectors, because ownership of logs and revocation becomes fragmented.
Common Variations and Edge Cases
Tighter gateway control often increases operational overhead, requiring organisations to balance governance strength against deployment complexity and latency. That tradeoff matters most when teams are running agentic workloads across regulated environments, multi-region data sets, or cross-border support functions.
There is no universal standard for this yet, but current guidance suggests that managed gateways are easier to adopt for lower-risk use cases, while self-hosted gateways are the safer default when the gateway itself could expose secrets, policy decisions, or customer data. The agentic risk profile matters here because tool chains can expand quickly, and a gateway that works for simple API mediation may not be sufficient when agents chain actions, re-use context, or touch multiple sensitive systems. The Analysis of Claude Code Security is a useful reminder that developer-facing AI runtimes can become security control points, not just productivity tools.
Teams should be especially cautious when a vendor-managed gateway cannot provide tenant-dedicated logs, customer-managed keys, or region-specific processing guarantees. In those cases, self-hosted or VPC-native deployments are usually the more defensible choice, even if they require more engineering and incident-response maturity.
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 | A2 | MCP gateways mediate agent tool use and runtime abuse paths. |
| CSA MAESTRO | GOV-04 | Gateway placement changes governance, logging, and control ownership. |
| NIST AI RMF | GOVERN | Managed vs self-hosted is a governance decision about risk and accountability. |
| NIST CSF 2.0 | PR.AC-4 | Gateway choice affects least-privilege access enforcement for MCP tools. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Gateway-brokered secrets need tight rotation and revocation controls. |
Assign gateway ownership, audit logging, and revocation responsibilities before deployment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
