Treat them as unsanctioned entry points until proven otherwise. Inventory every approved and personal client, identify any direct MCP settings, and compare those paths with the governed gateway route. If the same resource can be reached both ways, the weaker path is now part of the effective access model.
What teams should do with clients that bypass the gateway
Teams should treat outside-the-gateway clients as part of the security perimeter, not as harmless convenience. The practical task is to inventory every sanctioned client, any personal or unmanaged client, and every direct MCP configuration, then compare those paths to the governed route. If the same resource is reachable through both, the weaker path must be governed as an active access path.
Why outside-the-gateway clients change the access model
Once a client can reach a model, tool, or backend directly, the gateway is no longer the sole enforcement point. That means logging, policy checks, rate limits, identity binding, and data handling can all diverge between routes. A client that looks like a shortcut can become the path that determines the real blast radius, especially when it carries a saved token, API key, or direct MCP setting.
Approval status matters less than effective reachability. A personal client used by a trusted employee may still create shadow access if it can call the same resources with weaker controls than the sanctioned path. The right question is not whether the client is “allowed somewhere”, but whether it can reach protected resources under different conditions than the governed gateway route.
How to compare the sanctioned route with the weaker path
Start by mapping the actual access chain end to end: client, auth method, token or secret handling, target resource, and any policy or audit point in between. Then compare what is enforced on the gateway route versus what is enforced on the direct route. The comparison should include authentication strength, authorization scope, request logging, content filtering, tenancy boundaries, and revocation speed.
Where the same resource is reachable through multiple paths, the weakest path defines the effective control baseline. That is the path attackers, insiders, or well-meaning users will gravitate toward if it is faster, less constrained, or easier to automate. For that reason, “supported” and “secured” are not the same thing, and both must be measured against the same resource-level policy.
Risk and Threat Considerations
Outside-the-gateway clients create bypass risk because they can weaken the control stack without visibly breaking the application. The main exposure is inconsistent enforcement: one route may log and constrain usage while another preserves broad access through a long-lived token, direct MCP setting, or personal client configuration.
Failure mechanism: The direct path becomes the de facto control path when it offers broader reach, weaker authorization, or less monitoring than the gateway route. That lets misuse, overexposure, and hard-to-detect drift persist even after the sanctioned path has been tightened.
Impact: The organisation can end up with shadow access to sensitive resources, weaker incident forensics, and a larger compromise blast radius if a client, token, or endpoint is abused.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Direct client paths can exceed intended permissions to the same resource. |
| NHI-09 — NHI Reuse | The same resource reachable through multiple clients creates reuse across access paths. | |
| NHI-07 — Long-Lived Secrets | Direct clients often rely on persistent tokens or keys that outlast the gateway. | |
| Recommendation — Reduce privileges on direct clients until they are no broader than the governed route. Eliminate duplicated access paths or make them enforce the same controls. Rotate long-lived secrets and replace them with shorter-lived credentials where possible. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Weaker direct routes often grant broader access than the governed gateway. |
| IA-5 — Authenticator Management | Client bypasses frequently depend on unmanaged tokens, keys, or secrets. | |
| AU-2 — Event Logging | Different access paths can produce inconsistent audit coverage and forensics. | |
| Recommendation — Limit each client to the minimum access needed for its approved use. Manage client authenticators with rotation, revocation, and lifecycle controls. Log direct client access events with the same depth as gateway traffic. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | This is a trust-boundary question about governing every access path to the resource. |
| Recommendation — Treat every client path as untrusted until policy and verification are enforced. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is unmanaged access paths and inconsistent control over who can reach what. |
| CIS-5 — Account Management | Approved and personal clients both need lifecycle control and ownership clarity. | |
| Recommendation — Inventory and remove direct access paths that bypass the controlled gateway. Assign ownership and lifecycle review to every client that can reach production resources. | ||
Practitioner Guidance
What to prioritise: Build a resource-centric inventory first, not a tool-centric one. The fastest way to miss bypasses is to catalogue only the gateway and forget every approved desktop client, personal workspace, plugin, and local MCP configuration that can reach the same backend.
What to verify: For each reachable resource, verify whether the direct path is functionally equivalent to the gateway path on authentication strength, scope, logging, and revocation. If it is weaker in any of those dimensions, treat it as a governance gap rather than an optional alternative.
Decision rule: If you cannot quickly retire the weaker path, narrow its scope until it is strictly less permissive than the governed route. If you cannot narrow it, the safer assumption is that the bypass route remains active exposure and should be escalated for remediation.
Practitioner takeaway: The control question is not “is the client approved?”, it is “does this client create a weaker way to reach the same resource?” If yes, it must be managed as part of the effective access model.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org