Because the connection starts in the AI provider's cloud, not on your laptop. Claude's help center says custom connector traffic originates from Anthropic's cloud, so the server must be publicly reachable, and private servers need the provider's IP ranges allowlisted. A security connector therefore needs a public endpoint with strong authentication.
What actually happens
When you ask a question in chat, your device does not call the security tool. The provider's service does. It opens the connection to the connector's address, signs in with your token, lists tools and calls them.
That is why a connector hosted on a private network, with no inbound path, cannot be reached by default. The help center spells out the two options: make it public, or allowlist the provider's address ranges so only that traffic gets through.
Why this is a buyer issue
Security teams often keep sensitive tools off the public internet. A remote connector flips that assumption, and it deserves its own review.
| Question | Why it matters |
|---|---|
| Is the endpoint public? | Anyone can try to reach it, so authentication carries the whole load |
| Is OAuth used? | Tokens can be scoped and revoked per user |
| Are provider IP ranges allowed? | Narrows who can connect at the network layer |
| Is traffic logged? | You need a record of tool calls |
The MCP authorization section requires the Authorization header on every HTTP request and forbids tokens in the URL query string. It also says servers must validate that a token was issued for them. Those are the controls that protect a public endpoint.
Public does not mean open
A public address is not the same as public data. The connector should answer an unauthenticated request with a 401 and nothing else. The specification says invalid or expired tokens must receive a 401 response, and that insufficient permissions get a 403.
You can test this yourself. Call the endpoint without a token and confirm it refuses. Then confirm that a token from a different service is also refused, which is the audience check.
Options when public is not acceptable
- Allowlist the provider's published IP ranges on a gateway in front of the connector.
- Use a local server instead, accepting that code then runs on a workstation.
- Wait for a deployment option from the vendor that fits your network.
Each has costs, so pick based on your data, not on convenience.
A review checklist for the endpoint
Before approving a public connector, ask for three artifacts. First, the address and hosting region of the endpoint. Second, the list of origins or IP ranges it accepts, if any filter exists. Third, an example of the audit entry produced by one tool call, showing user, tool and time.
Then run two quick tests. Request the endpoint without a token and confirm a refusal. Request it with a token from a different application and confirm that is refused too. If either test succeeds where it should fail, stop the rollout and send the result to the vendor in writing.
A worked example: reviewing one endpoint
This example is illustrative. A vendor gives you the connector address, a placeholder here, https://mcp.vendor.example/mcp. You run three checks with a command line tool.
- No token. Send a request without an Authorization header. The expected result is a 401 response with a header that points to the server's metadata, per the specification. If you get data, stop.
- Wrong token. Send a token issued for a different service. The expected result is again a refusal, because the server must accept only tokens issued for it.
- Valid token, small scope. Use a token with read access to one project. Ask for a different project. The expected result is no data or a 403 that names the scope needed.
Write each result in your review file with the date. These three tests take under an hour and tell you more than a brochure.
Step by step: choosing a network approach
- List the data the connector can return, and mark anything customer related.
- Ask whether the vendor publishes a fixed set of source addresses for the AI provider's calls, or whether you must obtain the provider's ranges. Claude's help center says private servers need the provider's IP ranges allowlisted.
- Decide whether a gateway in front of the connector can enforce the allowlist.
- Confirm that the allowlist does not replace authentication. It narrows who can reach the endpoint. It does not say who the user is.
- Confirm logging at both the gateway and the connector, so you can match a chat question to a tool call.
- Write down who updates the allowlist when the provider changes ranges.
Table: layers of protection for a public connector
| Layer | Purpose | Who sets it up |
|---|---|---|
| Network allowlist | Limit who can reach the endpoint | You or the vendor |
| OAuth sign in | Identify the user | Vendor and chat provider |
| Token audience check | Reject tokens for other services | Vendor |
| Scopes | Limit what a user may do | Vendor, approved by user |
| Tool approval prompts | Human check on actions | Chat provider |
| Logging | Reconstruct events | Vendor and you |
Common misconceptions
Public means insecure. Many business systems are reachable from the internet and are protected by authentication. What matters is whether this one is.
A private connector is automatically safer. A private network helps, but a connector that cannot be reached by the chat provider cannot be used by it. Teams then sometimes work around the problem with a local server, which moves the risk to a workstation.
The chat provider keeps the connection inside its own network. The help center says calls come from the provider's cloud to your server, so the data travels over the internet, and your server must accept the connection.
What to put in the contract
Ask for the hosting region, a statement of what the server stores, and notice of changes to the endpoint address or the tool list. Do not accept a verbal answer to any of these.
Where Safeguard fits
If you are comparing approaches, a free scan at gold.safeguard.sh/scan lets you review real output first. Safeguard's MCP Guardrail is aimed at the policy questions that follow once agents can call external tools.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the server is addressed and authenticated, then compare it with the three checks above.
Quick check
Can I keep a security connector on a private network?
Only if the provider's IP ranges are allowlisted to reach it, per the Claude help center, or if you use a local server instead.
Should a public connector return data without a token?
No. The MCP specification expects a 401 for missing or invalid tokens.
Does allowlisting the provider make the connector private?
No. It narrows network access, but you still need authentication, scopes and logging.
Sources
Last reviewed: 19 October 2026.
