Use the simpler pattern only when the deployment is small, direct, and easy to govern. Once gateways, multiple users, or agent intermediaries enter the design, OAuth registration with explicit control over who can create clients becomes the safer operating model.
When do direct ACLs stop being enough for an internal MCP server?
Direct ACLs are workable when the server is tightly scoped, the clients are few, and the trust boundary is simple. They become fragile when access has to scale across teams, agents, or gateways, because the real question is no longer only “who can call the server” but “who is allowed to register and govern those calling clients.”
That shift matters for MCP because the server is often not just a static endpoint, it is an authorization boundary that may expose tools, data, and delegated actions. Once client creation, token handling, or intermediary services enter the path, MCP authorization for HTTP transports becomes the more durable design pattern than a hand-built allowlist.
Direct ACLs also tend to hide governance decisions inside configuration files, reverse proxies, or local deployment habits. That is fine for a small internal prototype, but it does not scale well when the security team needs explicit ownership, reviewable client registration, and a clear way to revoke a client without rewriting server rules or redeploying every integration.
Why OAuth registration gives better control once the design grows
OAuth registration changes the control point from static network trust to explicit client identity and lifecycle management. Instead of relying on everyone who can reach the endpoint to be implicitly trusted, the organisation can decide who may create a client, what metadata it must carry, what scopes it may request, and what audience the resulting token is valid for.
That is especially important when the MCP server sits behind gateways or serves multiple user populations, because the server then needs to distinguish transport access from delegated authority. The safer model is to treat the server as a protected resource, with client registration and audience-bound tokens supported by RFC 6749: The OAuth 2.0 Authorization Framework and reinforced by RFC 8707: Resource Indicators for OAuth 2.0.
For internal MCP deployments, registration control is not bureaucracy for its own sake. It is the mechanism that prevents a convenient local integration pattern from becoming a standing privilege path. Where a gateway, registry, or broker sits between users and the server, registration makes it possible to apply policy consistently instead of trusting every caller that can reach the network.
When the environment needs a more complete authorization model, the MCP authorization specification and RFC 9700: Best Current Practice for OAuth 2.0 Security both support the idea that tokens should be scoped, audience-bound, and resistant to replay or misuse.
What practitioners should check before choosing the simpler pattern
The right choice depends on whether the server is acting like a single-purpose internal utility or a shared platform capability. If the deployment is small, the ACL is easy to audit, and every caller is under one operational owner, direct ACLs can be acceptable. If any of those conditions are no longer true, the organisation should favour OAuth registration and make client creation a controlled workflow rather than an ad hoc technical convenience.
Practical teams should also verify how tokens are stored, whether client secrets can be rotated cleanly, and whether the server can distinguish a registered client from a merely reachable endpoint. If the design cannot answer those questions cleanly, the access model is probably too brittle for production use, even if it is acceptable in a lab or pilot environment.
Where stronger proof is needed, sender-constrained mechanisms such as RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) or certificate-bound access through RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens can further reduce the risk of token replay in higher-trust internal environments.
Risk and Threat Considerations
The main risk with direct ACLs is that they create a narrow control surface at the beginning and a wide one over time. As soon as multiple clients, gateways, or agent intermediaries are introduced, the ACL often becomes a coarse proxy for trust, which can leave overbroad access, weak revocation, and unclear ownership of client creation.
Failure mechanism: A caller that was meant to be a simple internal integration becomes a standing trust path because the server cannot distinguish an approved registered client from anything else that can reach the endpoint, especially when tokens or secrets are passed through intermediaries.
Impact: Over time, the organisation can accumulate hidden privilege, harder incident containment, and a larger blast radius if a token, client secret, gateway, or intermediary is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Covers service-to-service and machine authentication for internal MCP clients. |
| AC-3 — Access Enforcement | Applies to enforcing who may invoke MCP tools and resources. | |
| IA-5 — Authenticator Management | Relevant to rotation and control of client secrets and tokens. | |
| Recommendation — Require registered service identities and authenticate MCP clients explicitly. Enforce call-time authorization on every MCP request. Manage MCP client secrets and tokens with rotation and revocation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP servers exposed over HTTP inherit authentication failures if client registration is weak. |
| API5 — Broken Function Level Authorization | Direct ACLs can fail to constrain which functions or tools a client may invoke. | |
| Recommendation — Register and authenticate MCP clients to prevent token abuse. Scope MCP client permissions to the minimum tool set required. | ||
Practitioner Guidance
What to prioritise: Use direct ACLs only when the server is small, local, and owned by one team with a short revocation path. The moment you need multi-user access, a gateway, or delegated agent traffic, move the decision point to OAuth registration and client governance.
What to verify: Make sure the server can revoke one client without breaking unrelated clients, and that client creation is limited to an explicit administrative or developer workflow. If you cannot describe who is allowed to register clients, the model is already too loose.
Practitioner takeaway: The safest operating model is not the most convenient one at setup time, it is the one that keeps client identity, registration, and revocation visible when the MCP deployment stops being trivial.
Related resources from NHI Mgmt Group
- How do organisations decide whether MCP should use OAuth, mTLS, or federation?
- How can organisations reduce risk when AI agents use MCP servers?
- How should organisations implement an AI gateway when agentic systems connect to models, tools, MCP servers, and internal data sources?
- Why do AI gateway architectures matter when organisations use multiple LLMs and MCP servers?