I’m currently using a custom Base URL in Cursor to access my own LLM proxy service. The request flow is roughly:
Cursor IDE (user local machine)
→ Cursor Server
→ My LLM Proxy
My LLM proxy service has IP allowlisting enabled. However, requests forwarded from Cursor Server to my proxy are currently being rejected with: 403 Forbidden
The reason is that the Cursor Server egress IP is not included in my service’s allowlist.
I’d like to ask the Cursor team or the community:
Does Cursor Server use fixed egress IPs or IP ranges?
If so, could you provide the IPs / CIDR ranges so that we can configure them in our self-hosted LLM proxy allowlist?
If Cursor Server egress IPs are dynamic, is there any officially recommended network-level access control approach?
Are there any plans to provide documentation similar to “Cursor Server egress IP ranges”?
Our use case is an enterprise/team internal deployment with a self-hosted LLM proxy. Although LLM API requests already include authorization information, we still want to enforce IP allowlisting at the network layer and only allow trusted sources to access the proxy service.
If we cannot determine the Cursor Server egress IPs, we would have to loosen our IP restrictions, which does not align with our current security policy.
Is there any officially recommended solution for this?
We don’t publicly publish static egress IPs for BYOK or custom Base URL. The pool on this path isn’t static and it’s not in cursor.com/docs/ips.json. That file only lists cloudAgents and gitEgressProxy, and those aren’t related to BYOK traffic.
We can’t share IP ranges for the same reason. There’s no public guarantee these addresses stay stable, so you shouldn’t rely on them for production allowlisting.
Recommended approach is app level auth, not network level:
a strong API key or bearer token in the Authorization header (you already have this)
optional mTLS between Cursor backend and your proxy
rate limiting and audit logs on the proxy side
The flow Cursor IDE → Cursor Server → your LLM proxy is by design. The final request is built on our backend, so your proxy will always see Cursor server IPs, not the user’s IP.
Docs wise, there’s currently no public table of egress IPs specifically for BYOK. Static egress routing for custom models is being worked on internally, mostly for enterprise scenarios, but I can’t share an ETA or public availability. If and when it ships, it’ll show up in ips.json and in Network Configuration | Cursor Docs.
Databricks has an endpoint that will refresh IP lists so that you can keep up to date with any changing IPs. We need to really be tight on agent security, and it would be great if Cursor would implement a mechanism to do what is being asked to allow whitelisting for model endpoints.
Hey, thanks for the feature request. Makes sense: a refreshable endpoint with an IP list like Databricks so you can keep your allowlist up to date as addresses change.
Right now, for BYOK and custom Base URL, we don’t have a public list for that. The pool on that path isn’t static, and it’s not included in cursor.com/docs/ips.json (that file only has cloudAgents and gitEgressProxy).
We’re looking into static egress routing for custom models internally, but it’s mostly for enterprise use cases, and I can’t share an ETA or guarantee it’ll be publicly available. If and when it ships, it’ll show up in ips.json and on Network Configuration | Cursor Docs.
For now, for proxy-level security, the practical approach is app-level auth instead of network-level: use a strong API key or bearer token in the Authorization header (optionally mTLS between our backend and your proxy), plus rate limiting and audit logs. The flow is Cursor IDE → Cursor Server → your proxy by design, so your proxy will always see our server IPs, not the user’s IP.
@victoru, good catch. Let me clarify, since my earlier mention of mTLS might have been misleading.
Right now, there’s no documented, self-serve way to set up mTLS client certificates for the BYOK or custom Base URL path in Cursor, and that’s why you don’t see it in the docs. It’s not an enterprise-only toggle either. It’s just not generally available right now.
When I mentioned mTLS earlier, I meant it as a general security pattern you could enforce on your own proxy, not a setting Cursor supports today. So the supported way to secure your proxy endpoint is still app-level auth, like a strong API key or bearer token in the Authorization header, plus rate limiting and audit logs on your proxy.
If mTLS for custom models is a hard requirement for your setup, the best path is to raise it with your enterprise or account contact so it’s tracked for your specific deployment. I can’t promise availability or an ETA. If anything ships here, it’ll show up in the docs, likely Network Configuration | Cursor Docs.