A built-in gateway keeps cross-mesh traffic within the mesh management model, with listeners and routes configured by mesh policy and traffic secured through the data plane. A delegated gateway adds a separate gateway component that must be deployed and operated alongside the mesh. The practical difference is whether cross-mesh connectivity is handled natively or through an extra operational layer.
How built-in gateway and delegated gateway models differ in cross-mesh traffic
A built-in gateway keeps the cross-mesh path inside the mesh’s own policy and data-plane model, so routing, listener behaviour, and traffic handling stay governed by mesh-native controls. A delegated gateway introduces a separate gateway component that becomes part of the operational architecture. The practical difference is not just where traffic lands, but how much extra deployment and ownership complexity you add.
The built-in model is usually the cleaner fit when you want cross-mesh connectivity to behave like an extension of the mesh itself. It preserves a single control surface for policy definition and avoids an additional traffic handoff layer. By contrast, a delegated gateway is useful when you need a dedicated gateway runtime, but it also creates another place where configuration drift, policy mismatch, or operational bottlenecks can appear.
The distinction is especially important in environments that value consistency. Built-in gateways tend to reduce the number of components teams must coordinate, which can simplify change management and make traffic policy easier to reason about. Delegated gateways can be more flexible, but they also require clearer ownership boundaries because the gateway now has to be deployed, updated, monitored, and secured as its own asset.
What changes operationally when the gateway is delegated
Delegation shifts part of the burden from mesh policy to gateway operation. That means you are no longer only deciding how traffic should flow, you are also deciding who runs the gateway, how it is versioned, how it is observed, and how failures are isolated. In practice, the extra layer can help separate duties, but it also introduces another control point that must stay aligned with the mesh configuration.
A built-in gateway usually feels more native because the mesh remains the primary source of truth for the connection. A delegated gateway is better understood as an integration surface, where the mesh and the gateway must agree on listeners, routes, and trust boundaries. If that alignment slips, the result is often not a hard outage, but inconsistent traffic behaviour that is harder to debug than a simple routing failure.
This is why the operational difference matters more than the label. The built-in approach optimises for simplicity and consistency. The delegated approach optimises for separation and flexibility. Neither is automatically better, but each one changes where teams spend their operational effort: policy authoring in one case, lifecycle and runtime ownership in the other.
How to choose between native handling and an extra gateway layer
The decision usually comes down to whether you want cross-mesh traffic to be governed as an extension of the mesh, or whether you need a separate component for administrative, architectural, or deployment reasons. If the primary goal is to keep the traffic model uniform, built-in gateway handling is usually the lower-friction option. If the environment needs explicit gateway isolation or independent operational control, delegation can be the better fit.
Think about failure domains as well. A built-in gateway generally reduces moving parts, but it also ties the traffic path more closely to the mesh’s own control plane and data plane behaviour. A delegated gateway can reduce coupling in one sense, yet it adds another service that must be made highly available and kept in sync with mesh policy. That trade-off becomes more visible as the number of meshes, tenants, or traffic paths grows.
Trade-off: built-in gateways simplify the model, while delegated gateways expand the operational surface. The right choice depends on whether your bigger concern is keeping the path native or creating a separately managed gateway boundary.
Risk and Threat Considerations
The main risk is configuration divergence, where the gateway layer and the mesh layer stop expressing the same routing or trust assumptions. That can create traffic leakage, misrouted requests, or an unexpected exposure of cross-mesh connectivity that teams assume is still governed by mesh policy.
Failure mechanism: when a delegated gateway is introduced, its listeners, routes, and lifecycle can drift from the mesh configuration, or the gateway can become a separate operational choke point that is not monitored and updated with the same discipline as the mesh.
Impact: the result can be inconsistent traffic behaviour, harder incident triage, and a larger blast radius if the gateway is misconfigured, unavailable, or treated as a passive plumbing layer instead of a controlled component.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Cross-mesh traffic depends on enforced routing and boundary controls. |
| CM-2 — Baseline Configuration | Gateway and mesh policy alignment relies on controlled, repeatable configuration. | |
| AU-2 — Event Logging | Delegated gateways add an extra layer that should be observable for troubleshooting and assurance. | |
| Recommendation — Enforce cross-mesh traffic rules through explicit information flow controls. Maintain approved baselines for gateway and mesh configuration. Log gateway and routing events to support change review and incident analysis. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network Security | Cross-mesh gateways are network boundary controls that need secure routing and segmentation. |
| A.8.9 — Configuration Management | Built-in versus delegated gateways differ mainly in configuration ownership and drift risk. | |
| Recommendation — Define and enforce secure network boundary handling for mesh-to-mesh traffic. Control gateway configuration changes through formal approval and review. | ||
Practitioner Guidance
What to verify: confirm which component is the source of truth for cross-mesh routing, and test whether the gateway path behaves identically after policy changes, restarts, and upgrades. If the answer depends on tribal knowledge, the design is already too fragile.
What good looks like: teams can explain, in one sentence, whether cross-mesh traffic is mesh-native or gateway-mediated, who owns each layer, and how a routing change is validated before it reaches production.
Practitioner takeaway: the architectural choice is less about traffic forwarding and more about control ownership, because the simplest design is usually the one that leaves the fewest places for policy and operations to diverge.
Related resources from NHI Mgmt Group
- What is the difference between consumer routes and producer routes in Gateway API mesh traffic?
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
