Cursor Enterprise: Network Configuration

Cursor uses HTTP/2 bidirectional streaming by default for real-time chat and agent work. Some enterprise proxies don't handle HTTP/2 streaming correctly; Zscaler is the most widely used proxy with this limitation. When HTTP/2 streaming doesn't work, Cursor automatically falls back to HTTP/1.1 Server-Sent Events (SSE), a fallback built specifically for Zscaler and similar proxies that buffer or break HTTP/2 streams. The switch happens transparently.

The other common blocker is SSL inspection, which Cursor names as one of the most common deployment blockers it sees from enterprise customers. Many corporate proxies perform SSL man-in-the-middle inspection for security or data loss prevention (DLP), replacing Cursor's certificates with the proxy's. When Cursor traffic passes through a Secure Web Gateway, SSL inspection or DLP, it often causes timeouts, slowness or errors in Agent work. Cursor's services are already encrypted end-to-end, so the documentation recommends excluding these domains from SSL inspection:

• .cursor.sh
• cursor-cdn.com
• marketplace.cursorapi.com
• authenticate.cursor.sh
• authenticator.cursor.sh

Do the exclusion before you touch the firewall list. Inspection in the path changes what the later tests tell you, starting with the certificate check, which will keep naming your proxy's issuer no matter how correct your firewall rules already are. Cursor's hardening checklist bundles allowlisting and the exclusion into a single step. Finish the exclusion half of it first.

None of this reaches the scanner on the laptop. Antivirus, EDR and endpoint DLP run on the machine rather than in the network path, and they need their own exclusions. The two failures read much the same from a support ticket, which I suspect is how this one gets misrouted. Those exclusions are on endpoint security.

Cursor recommends allowlisting domain patterns rather than IP addresses, which can change. For most networks, allow traffic to *.cursor.sh, *.cursor-cdn.com and *.cursorapi.com. If your firewall mandates granular subdomain entries without wildcards, the documentation lists each subdomain and what it handles.

The choice is three wildcard patterns against a granular list that runs past twenty hostnames, six of them api5 agent subdomains and two of them separate token issuers. Wildcards give your network team three lines to review in a change ticket. The granular list gives them an inventory, and it only pays when the firewall genuinely cannot take a wildcard, which is the case the docs carve it out for.

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

Two lines in the at-rest row need a second look. Encrypted code storage applies 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. when that is turned on, so a team running only the editor never has to argue about it. The encrypted vector database is where codebase indexing keeps its embeddings, and that is the line that matters if you index private repos. Codebase indexing covers what gets stored and for how long.

The exclusion request is narrower than it sounds. Five domains leave the inspection path and stay encrypted end to end; everything else your users touch is inspected exactly as before. A reviewer who reads it as switching inspection off for a whole vendor will say no, reasonably enough. Name the five domains in the ticket.

It depends on where the agent runs. When you run Cursor agents in the editor or via the CLI on a machine inside your VPC, they inherit that machine's network configuration: security groups, firewall rules, DNS, and VPN or private network access. So those agents can reach internal resources the machine can reach while following your existing controls.

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. are different because they run on Cursor's infrastructure, not your network. They can reach public GitHub, GitHub Enterprise Cloud repos you've granted access to, on-prem and cloud GitLab, Bitbucket Cloud and public package registries. They cannot reach resources behind your corporate firewall, on-premises GitHub Enterprise Server or private package registries without internet access. The dividing line is whether the system is reachable from the public internet, which is the framing Cursor's own private-connectivity docs use. For Enterprise teams that need Cloud Agents, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. or Cursor backend services to reach private source control, Cursor supports private connectivity via AWS PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. Press Enter for the full definition. and Cloudflare Tunnel.

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 rather than 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 holds 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.

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 does not leave through your network egress. The policy is one of three access modes: allow all network access, the default domains plus your own allowlist, or allowlist only. Enterprise admins can lock the team-level setting so members cannot override it.

The firewall work and the egress work are two separate jobs. I used to bundle them into one network project, and that framing hides what actually goes wrong: firewall rules get reviewed by the network team, the egress modes sit with whoever administers Cursor, and on plenty of teams those two never compare notes. Give each one an owner rather than giving the pair a project. The modes and their precedence across scopes are on Cloud Agent security and network access.

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. come in two deployment shapes, and the split decides where your code lives during a run. That last part is probably the whole decision if you are regulated. Self-hosted Cloud Agents run much of the infrastructure inside your own VPC: you keep more control over the environment and you configure your own retention. Cursor-hosted agents are simpler to stand up, but some code necessarily passes through Cursor Cloud while the agent works.

Most connectivity issues come from proxies buffering streaming responses. The documentation includes curl tests that simulate the requests Cursor makes. To check whether SSL inspection is active, run curl -v https://api2.cursor.sh |& grep -C1 issuer: and look at the certificate: you should see Amazon RSA, and seeing your proxy provider (such as Zscaler) means SSL inspection is intercepting the connection.

The two streaming tests are the ones worth learning to read, because both fail by looking like they passed. The HTTP/1.1 check should print line by line across five seconds; everything arriving at once at the end of those five seconds means the path buffered it. The HTTP/2 check should print once a second, and the same all-at-once ending means bidirectional streaming is not getting through. Neither test fails loudly. The difference between a pass and a fail is timing alone, so the buffering case tends to arrive as a complaint about speed.

Work through the checks in order. Each step isolates one layer, so by the time you reach the bottom you know whether the problem is the firewall, SSL inspection or the proxy buffering streams. Most of the time it turns out to be the last one.

1. 1Test basic connectivity to api2.cursor.sh.
2. 2Check whether SSL inspection is active and consider excluding the Cursor domains above.
3. 3Verify streaming works with the HTTP/1.1 SSE and HTTP/2 bidirectional curl tests from the docs.
4. 4Confirm firewall rules allow *.cursor.sh and related domains.
5. 5Review proxy logs for connection errors or timeouts.
6. 6Test from a machine outside your network to isolate network-specific issues.

Step six is the one I would move up if the room is arguing about whose problem this is. A machine outside the network settles that question in about a minute. The five checks above it tell you what to fix, and that is the right order once the proxy is the agreed suspect.