Cursor Enterprise Deployment Patterns: MDM, Package Managers & Cloud Distribution

Three methods cover the full range of enterprise fleet management: MDM for policy-enforced deployment, package manager scripts for developer-controlled installs, and direct download for smaller teams or rapid rollouts.

Cursor documents MDM deployment for three vendors: Omnissa Workspace ONE, Microsoft Intune (Windows and macOS) and Kandji. Download the relevant build from cursor.com/downloads and follow your vendor's standard app deployment workflow. Cursor does not push or manage files through your MDM — configuration and update cadence are owned by your IT or security team.

Hooks — scripts that run at specific points in the Cursor agent workflow — can reach developer machines three ways:

• Project hooks: commit .cursor/hooks/ to the repo so every engineer gets them on clone.
• MDM-based distribution: deploy hook files through your existing MDM tooling as a managed package or script.
• Cursor cloud distribution: configure hooks in the Enterprise admin dashboard and Cursor automatically delivers them to every client machine when a team member logs in. No MDM required.

Cloud distribution is the simplest option for teams already on Enterprise — it eliminates a separate MDM configuration step and keeps hooks in sync as you update them.

Most corporate proxies work transparently. The common failure mode is a network that blocks HTTP/2 — ZScaler is a documented example. If developers report slow connections or auth failures, enable HTTP Compatibility Mode under Cursor Settings → Network to fall back to HTTP/1.1.

By default Cursor auto-updates on each launch. For fleets that require controlled rollouts, manage updates through your MDM by deploying specific build versions and disabling the auto-update mechanism via MDM policy. Cursor publishes builds for all platforms at cursor.com/downloads; version history is available for pinning.

This is the single most common enterprise misconception. Self-hosted or private workersCloud-agent machines that run inside your own network so they can reach internal systems; the model inference still calls external providers. move the cloud-agent container — the runtime that clones your repo, runs commands and executes the agent loop — onto your own infrastructure. They do not move model inference. The container still calls Cursor's model providers over the network for every completion.

What you do gain from a private worker is network reachability and isolation. Because the container runs where your internal services live, the agent can clone from an internal-only Git host, pull from a private registry and call an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server that is not exposed to the public internet — none of which a Cursor-hosted worker can reach.

Cloud agents run with broad capability by default, so the Enterprise admin dashboard exposes per-org controls that constrain what a run can reach, how long it lasts and where it can land. Set these before you turn agents loose on real repos.