What is the difference between per-client MCP config and a gateway model?

How the two patterns differ in day-to-day operations

Per-client MCP configuration makes each client carry its own server list, credentials, and permission assumptions. That gives teams local control, but it also means drift is easy and every workstation becomes part of the trust boundary. A gateway model moves those decisions into one managed layer, so the client talks to a smaller, controlled surface instead of managing its own direct connections.

The practical difference is where consistency lives. In a per-client model, consistency depends on every device staying aligned. In a gateway model, consistency depends on the gateway being correctly governed and kept current. That shifts the operational burden from distributed setup to central policy enforcement, review, and change control.

For teams comparing these patterns, the issue is not only convenience versus centralisation. It is whether the organisation wants access decisions to be duplicated across endpoints or enforced once in a shared control point. That distinction becomes important as soon as the MCP estate includes multiple tools, multiple operators, or any server that should not be exposed broadly.

Why governance and auditability change with a gateway

A gateway gives you a single place to define which servers are published, which credentials are held, and which permissions are exposed to clients. That makes review easier because policy, logging, and approval can be attached to one authoritative layer instead of being reconstructed from many local files. It also reduces the chance that a client still points to a stale or unsanctioned server after the environment changes.

Per-client configuration can be acceptable when the environment is small and tightly controlled, but it becomes weaker as soon as you need evidence of who could reach what, when, and under which credential. A central gateway makes that evidence easier to produce because the access path is deliberate and observable rather than scattered across endpoints.

This is why gateway designs are usually preferred when governance matters more than edge convenience. They are not automatically safer in every dimension, but they are easier to inspect, constrain, and retire consistently, especially when server access should be minimised or changed quickly.

What the security trade-offs actually are

The main trade-off is between distribution and concentration. Per-client config spreads trust across devices, which can reduce dependency on a single control point but increases the chance of misconfiguration, secret sprawl, and inconsistent permissions. A gateway concentrates trust, which simplifies control but creates a higher-value target and a dependency that must be protected carefully.

That means the gateway model only delivers its promised security benefits if the gateway itself is treated as sensitive infrastructure. If the central layer is overpermissive, poorly segmented, or poorly monitored, you have simply moved the problem. The gain comes from narrower exposure, stronger oversight, and a smaller number of places where credentials and policy can go wrong.

For implementation detail, the authorisation model should be explicit rather than implied by client-side configuration. The MCP authorization specification is useful reading when you want the gateway to enforce audience-bound tokens and avoid token passthrough.

Risk and Threat Considerations

Per-client MCP config increases the blast radius of local drift, because one copied credential or stale server definition can expose a client to the wrong system or preserve access after it should have been removed. Gateway designs reduce that distribution risk, but they also make the central layer an attractive target for credential theft, privilege abuse, or overbroad downstream access.

Failure mechanism: In the distributed model, attackers and mistakes both benefit from duplicated configuration, especially when server definitions and credentials are stored locally on many devices. In the gateway model, the failure mode shifts to central compromise, mis-scoped permissions, or an authorization layer that is narrower in appearance than it is in practice.

Impact: The first model tends to fail through inconsistency and forgotten exposure. The second tends to fail through concentration, where one control plane error can affect many clients at once. The right design depends on whether the stronger organisational need is local convenience or centrally enforceable control.

Practitioner Guidance

What to verify: Check where credentials are actually stored, who can change server definitions, and whether removal of access on the central side really removes it everywhere. If clients can keep functioning after the gateway policy changes, the model is not as centralised as it appears.

Decision rule: If you need consistent permissions, auditable access, and rapid revocation, prefer the gateway model. If you are intentionally optimising for lightweight local setup and the server set is stable and low risk, per-client config can be workable, but only with strict drift management.

Practitioner takeaway: The meaningful choice is not decentralisation versus centralisation in the abstract, it is whether you want every endpoint to carry governance responsibility or want one controlled layer to own the trust boundary.

Related resources from NHI Mgmt Group

• Guide: MCP Security Guide
• What is the difference between an MCP gateway and a sidecar security model?
• What is the difference between an MCP gateway and direct client-to-app access for enterprise agent workflows?
• What is the difference between per-client consent and general user authentication in MCP?
• What is the difference between privilege reduction and secret rotation?