Cursor Enterprise: Network Configuration

By default, Cursor carries real-time chat and agent work over bidirectional HTTP/2 streams. Some enterprise proxies mishandle HTTP/2 streaming, and Zscaler is the most widely used of them. When the stream fails, Cursor switches on its own to HTTP/1.1 Server-Sent Events (SSE), a mode Cursor designed for Zscaler and other proxies that buffer HTTP/2 streams or break them.

The other usual blocker is SSL inspection, which Cursor counts among the most frequent problems it sees in enterprise deployments. Many corporate proxies inspect encrypted traffic for security threats or data loss prevention (DLP) by swapping Cursor's SSL certificates for their own. When Cursor traffic passes through a secure web gateway, SSL inspection or DLP, Agent work often times out, slows down or fails.

Set up the exclusion before you touch the firewall list. Inspection in the path changes what later tests tell you, starting with the certificate check, which keeps naming your proxy's issuer however correct your firewall rules are. Cursor's hardening checklist puts allowlisting and the exclusion in one step, so finish the exclusion half first.

None of this reaches the security software on the laptop. Antivirus, EDR and endpoint DLP run on the machine, not in the network path, so they need their own exclusions. The two problems can look alike in a support ticket, which makes it easy to send one to the wrong team. The endpoint security page covers those exclusions.

Cursor's services are already encrypted end to end, so Cursor recommends turning off SSL inspection for these domains:

• .cursor.sh
• cursor-cdn.com
• marketplace.cursorapi.com
• authenticate.cursor.sh
• authenticator.cursor.sh
• *.cursorvm.com
• *.*.cursorvm.com
• cursor.com and *.cursor.com, for the web dashboard, Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. at cursor.com/agents and code review pages

Sign-in now also goes through accounts.spacex.ai, accounts.x.ai and related auth hosts, so exclude those too. authenticator.cursor.sh is the fallback sign-in page during the transition, and Cursor's sign-in help page says that fallback retires on October 30. Grok BotAn early AI teammate product from SpaceXAI and Cursor that works across apps on a persistent cloud computer and asks for approval on selected actions; launch materials describe it as beta, but Cursor says Beta Services terms do not apply. Press Enter for the full definition. needs both cursorvm.com patterns, because its hosted computers use nested hostnames that a single-level wildcard misses. Apply the exclusions to roaming and off-network proxy profiles as well as office locations.

A gateway that scans downloads needs one more change. The web app at cursor.com streams agent conversations and code review data as long-lived compressed responses. A gateway that treats them as files can hold each response until the connection closes, which can take over ten minutes. Cursor says Cloudflare Gateway does this when its HTTP policies inspect cursor.com, and that Zscaler and Netskope have equivalent settings.

Agents then stay on "Loading…" at cursor.com/agents while the desktop app opens the same agents normally. Exclude cursor.com and *.cursor.com from TLS inspection and from file scanning.

Cursor recommends allowlisting domain patterns, not IP addresses, which can change. For most networks, allow traffic to *.cursor.sh, *.cursor-cdn.com, *.cursorapi.com, *.cursorvm.com and *.*.cursorvm.com. If your firewall requires granular subdomain entries without wildcards, Cursor's docs list each subdomain and what it handles.

The choice is five wildcard patterns against a granular list that runs past twenty hostnames, six of them api5 agent subdomains and two of them token issuers. The patterns give your network team a short change ticket to review. The granular list gives them an inventory, but it only pays off when the firewall can't take a wildcard, which is the case the docs reserve it for.

Sign-in needs entries of its own, because the five patterns don't cover the new sign-in page. Cursor's sign-in help page asks networks with a firewall or proxy allowlist to add accounts.spacex.ai, accounts.x.ai and related auth hosts, preferably as wildcards such as *.spacex.ai and *.x.ai. Once the fallback retires on October 30, a network that blocks them stops users from signing in. Our sign-in domains page lists every host.

Cursor encrypts data in transit and at rest. Security reviewers ask for exactly this when you request an SSL-inspection exclusion, so here is what to hand them.

Two at-rest items need a second look. Encrypted code storage belongs to Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., the only feature that requires Cursor to store code, and with CMEK on, Cloud Agent data is encrypted with your key. The network page doesn't say what the encrypted vector database holds. Cursor's search docs now say Cursor doesn't upload code to build a search index or store embeddings of your codebase for search, and the codebase indexing page covers how search works now.

The exclusion request is narrower than it sounds. Only the listed hosts leave the inspection path and stay encrypted end to end, and everything else your users reach is inspected as before. A reviewer who reads it as switching inspection off for a whole vendor is likely to refuse it, so list every entry in the ticket.

It depends on where the agent runs. Agents in the editor or the CLI on a machine inside your VPC inherit that machine's network configuration: security groups, firewall rules, DNS, and VPN or private network access. They can reach the internal resources that machine can reach, under your existing controls.

Cursor-hosted Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. run on Cursor's infrastructure instead. Cursor's network page says they can reach public GitHub, GitHub Enterprise Cloud repositories you've granted access to, GitHub Enterprise Server, on-prem and cloud GitLab, Bitbucket Cloud and public package registries. It also says they can't reach resources behind your firewall, on-premises GitHub Enterprise Server or private registries without internet access. The page lists GitHub Enterprise Server on both sides, and Cursor's private connectivity page draws the line at whether a system is reachable from the public internet.

For systems that aren't, Enterprise teams can set up private connectivity through AWS PrivateLinkAn AWS connection Cursor uses for private Git provider and repository-origin traffic; it does not cover model-provider traffic. Press Enter for the full definition. or Cloudflare Tunnel. It covers Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. and Cursor's backend services.

How much of this is open to you is partly a procurement question. Private connectivity is an Enterprise capability, and setup runs through hi@cursor.com or a Cursor sales representative, not a settings page. A team of eight that needs an agent inside the network will get there sooner by installing Cursor on a machine that already has the VPN. Private connectivity covers the prerequisites and both traffic directions.

You control it in the Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. dashboard, not on your firewall.

Cursor-hosted Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. run on Cursor's infrastructure, so their outbound traffic doesn't leave through your network, and they have internet access by default. The dashboard offers three access modes: allow all network access, the default domains plus your own allowlist, or allowlist only. Users, saved environments and team admins can each set a mode. Only Enterprise admins can lock the team setting so members can't override it.

The team allowlist is the same list that sets the sandbox's default network allowlist for desktop agents, so one change affects both. Self-Hosted Machines sit outside all of this. They use the machine's own network, firewall and proxy, and a locked setting doesn't reach them.

Firewall rules and egress modes are separate jobs. The network team reviews firewall rules, while whoever administers Cursor sets the egress modes. Give each job a named owner instead of filing both under one network project. The modes and their precedence are on Cloud Agent security and network access.

Usually not. Cursor points most teams to its managed Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition.. Self-Hosted Machines move tool execution, not the agent: Cursor keeps running the agent loop, planning and inference in its cloud, while your machine runs file edits, terminal commands and local MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers. They come as My Machines, for one user's machine, and Team Pools, a worker fleet for Enterprise teams.

Weigh Cursor-hosted retention against your policy before you choose. Snapshots are encrypted copies of the agent's VM disk, which is what lets an agent resume without recloning the repository. Each start or resume extends a snapshot's 30-day window, and snapshots can't be deleted on demand. Enterprise admins can cap conversation history at 90 days.

Most connectivity issues come from proxies buffering streaming responses. Cursor's docs include curl tests that simulate the requests Cursor makes. To check for SSL inspection, run curl -v https://api2.cursor.sh |& grep -C1 issuer: and read the certificate issuer. Amazon RSA is the expected result, and your proxy provider's name, such as Zscaler, means SSL inspection is intercepting the connection.

The two streaming tests need care, because a failure looks like a pass. The HTTP/1.1 test should print line by line over five seconds. If everything appears at once when the five seconds end, the path buffered it. The HTTP/2 test should print once a second, and the same all-at-once ending means bidirectional streaming isn't getting through. Since only the timing differs, the buffering case often reaches you as a complaint about speed.

Work through Cursor's checklist in order. Each step isolates one layer, so by the end you know whether the problem is the firewall, SSL inspection, a scanning gateway or the proxy buffering streams.

1. 1Test basic connectivity to api2.cursor.sh.
2. 2Check whether SSL inspection is active, and consider excluding the Cursor domains above.
3. 3If cursor.com/agents stays on "Loading…" while the desktop app works, check whether download scanning is holding the web app's streams.
4. 4Verify streaming with the HTTP/1.1 SSE and HTTP/2 bidirectional curl tests from the docs.
5. 5Confirm firewall rules allow *.cursor.sh and related domains.
6. 6Review proxy logs for connection errors or timeouts.
7. 7Test from a machine outside your network to isolate network-specific issues.

We'd move step seven up when teams disagree about whose problem this is. A test from outside the network settles that quickly, and the steps above it then tell you what to fix.