A Deeper Look: Domain and IP Allowlists for Lucid’s MCP

MCP Domain Allowlist

What is it?

Domain allowlisting gives admins more granular oversight over which AI clients are permitted to connect to Lucid's MCP server. It works by restricting which domains (e.g., claude.ai, chatgpt.com) are allowed to authenticate with Lucid’s MCP.

How does it work?

When the domain allowlist control is enabled, the domain is checked…

• Initial authentication: when a user attempts to authenticate through an AI client, Lucid validates the redirect URI — the address it sends the OAuth authorization information to — against your approved domain list. If the redirect URI isn't on the allowlist, Lucid does not complete the authentication.
• Token refresh: when the access token is refreshed, Lucid checks whether the domain of the original redirect URI is on the allowlist. If the domain isn't on the allowlist, Lucid does not refresh the access token. Note that access tokens expire hourly, meaning a removed domain will cause a user’s access to lapse within an hour.

How admins configure it

Note: this section and the next section make some generalizations about how different types of AI clients authenticate to Lucid’s MCP. However, authentication methods can vary by client and by configuration. We recommend you check both your AI provider’s documentation and how your users’ AI clients are configured to determine how to configure the Lucid MCP domain allowlist. 

Admins enter the domains or OAuth redirect URIs of the AI providers they want to permit. For example, you might add claude.ai/api/mcp/auth_callback or chatgpt.com/*. Admins should also check whether they need to enable the “Allow local authentication” setting (more details below).

More about the “Allow local authentication” setting

Browser and desktop AI clients typically make requests to Lucid's MCP via the AI provider's own servers. That's what makes the domain allowlist effective for these clients — Lucid can validate the redirect URI against a known, provider-controlled domain during authentication. 

Some AI clients — like command-line tools — work differently. Rather than authenticating through the AI provider's servers, they run directly on the user's own machine and authorize via a local IP address (typically appearing as localhost). For localhost connections, there's nothing for a domain allowlist to reliably check: a localhost connection looks the same regardless of which tool is making the request. Furthermore, any information that could be used to identify a particular AI client is self-reported rather than verified, so that information can't be used to distinguish one local tool from another with high confidence.

For that reason, we provide a separate control for local clients rather than folding them into the domain allowlist. Admins can allow or block locally hosted MCP clients as a group, independent of which specific domains are approved.

If your organization needs granular, high-confidence control over which individual locally hosted AI clients can connect to Lucid's MCP, the domain allowlist is not the right mechanism and we’d suggest you explore third-party endpoint security solutions.

MCP IP Allowlist 

What is it?

This feature applies an admin-defined IP allowlist to all authenticated requests coming into Lucid’s MCP. 

The intention is to offer protection against “token replay attacks”, where an attacker steals an OAuth token and tries to use it to access user data.  Admins can use this feature to enforce that requests to Lucid’s MCP are coming from approved IP ranges (such as your corporate VPN or the listed IP range of your approved AI tool), and not coming from unapproved IPs like a coffee shop.  

How does it work?

When this control is enabled, the origin IP of every authenticated request made by a user on your account is checked against your organization's MCP IP allowlist. If a request comes from an IP not on the list, it is rejected.

How admins configure it

Note: this section makes some generalizations about how different types of AI clients call Lucid’s MCP. However, AI clients can call Lucid’s MCP differently depending on the client and how it’s configured. We recommend you check both your AI provider’s documentation and how your users’ AI clients are configured to determine how to configure the Lucid MCP IP allowlist.

AI clients generally connect to an MCP server in one of two ways, and which one your users' clients follow determines what you'll need to add to the MCP IP allowlist:

1. Desktop- or browser-based AI clients: Generally when a user connects to Lucid's MCP through a desktop- or browser-based AI client, the initial authentication request comes from the user's browser on their own network. Then ongoing requests come from the AI provider's own servers rather than the user's device. To facilitate users accessing Lucid’s MCP via desktop- or browser-based AI clients, admins enabling this control usually must add both the IP ranges for users’ local machines (usually your corporate network's IP range) and your chosen AI providers' published IP ranges to the allowlist. Provider IP ranges are typically listed on the provider's own website.
2. CLI-based AI clients: Generally when a user connects to Lucid's MCP via a command-line (CLI) AI tool — such as Claude Code — the request to Lucid's MCP usually comes from the user's local network. To facilitate users accessing Lucid's MCP via CLI-based tools, admins enabling this control usually must add to the allowlist the IP range where their users' computers will connect from (usually the IP range of your corporate VPN).

How the features interplay

Each control checks something different, and admins can enable both features independently or together. 

• MCP domain allowlisting governs the moment a user authorizes an AI client to Lucid’s MCP, which occurs before any authorization token exists. The control helps catch when users are authorizing an unapproved AI tool to Lucid’s MCP, even from a fully trusted network. IP allowlisting would only check and control where the authorization request came from, while domain allowlisting checks and controls where Lucid sends the authorization credential to.
• MCP IP allowlisting checks every authenticated request, including the initial authorization step and every request after a token has been issued. The control helps prevent a stolen or leaked token being used from an unapproved network to access Lucid data. 

Considerations and Limitations 

To ensure you’re making educated decisions, we list below a number of things you should be aware of when configuring these features:

• No org-group granularity: At this time, both controls currently operate at the account level. Admins cannot configure these features differently for different Lucid org groups (e.g. applying more permissive rules to Engineering than to Sales).
• AI provider IP range and domain maintenance: AI providers can change their IP ranges or domains. When enabling these features, admins accept the responsibility of keeping IP ranges or domains updated in their allowlist(s).
• Personal accounts on approved clients: Even with both domain and IP checks active, a user could still authenticate to Lucid's MCP using a personal AI account through an approved client. Both security conditions would be technically satisfied, though the account itself might not be approved by your organization. If you need controls to prevent use of personal accounts on approved AI clients, we'd recommend you consult with your AI provider.
• IP allowlisting reduces, but doesn't eliminate, the risk of token replay: This feature raises the bar for an attacker, but it isn't a complete solution. A stolen token can still be used successfully if it's replayed from a location already on your allowlist — for example, from a compromised device already inside your corporate VPN, or via infrastructure that shares an IP range with your approved AI provider. Treat this control as one layer of defense that meaningfully narrows an attacker's options, not as a guarantee that a stolen token can't be misused.
• Session timeout applicability: The "max session timeout" or "idle session timeout" settings in the admin panel govern browser-based interactions with Lucid. These settings do not apply to Lucid’s MCP, as Lucid’s MCP relies on the OAuth 2.0 protocol which has its own standards for authentication timeouts.
• IP allowlisting for user login: This article discusses IP allowlisting for accessing Lucid’s MCP. Lucid also provides an IP allowlist control for user login via a browser. These are separate lists that must be maintained separately (if they’re both enabled). The MCP IP allowlist is available for all customers on Lucid’s Enterprise plan. The IP allowlist for browser login is available to customers with Enterprise Shield.