Cursor Enterprise: Model & Integration Management (Allowlists, MCP)

From the Enterprise admin dashboard, admins set allow or blocklists at two levels: the provider (block all Anthropic models, for example) or an individual model configuration. A May 2026 update added the ability to filter by specific model attributes (speed tier and context window size), so admins can restrict to cheaper fast models or require high-context models for certain workloads.

• Block an entire provider to prevent all of its models from appearing in the model picker.
• Block specific model versions while leaving the rest of that provider available.
• Filter by speed or context window to enforce a cost or capability floor.
• Enable block new providers by default so newly released models don't appear until explicitly approved.

Turning on block new providers by default hands someone an approval queue, which is the part the setting does not advertise. A model ships, nobody on the team can select it, and the days between release and approval get read as the picker being broken rather than as policy. Decide who watches that queue before you turn the switch on.

When someone reports a model missing, start at the provider level. A provider block hides every version at once and looks identical from the picker to a single blocked model, so the narrower check first just costs you a round trip.

Cursor provides models from four providers on Enterprise plans: OpenAI, Anthropic, Google Gemini and xAI. The exact model list moves as providers release new versions, faster than a policy document tends to, so admins read the current set in the model management section and approve or block each one there.

A bring-your-own API key routes requests through your own account, and it covers more providers than the model list above, including Azure OpenAI and AWS Bedrock. The table shows where the option exists today.

Enterprise customers can supply their own API keys for supported providers. Requests using a BYO key route through the customer's provider account at that provider's published rates, plus the Cursor Token Rate. This is the standard pattern for:

• Organizations with existing enterprise agreements with a model provider.
• Teams that need specific rate limits or data residency guarantees from the provider.
• Finance teams that want AI costs to flow through a single provider invoice.

Blocking a provider and restricting personal API keys are separate settings, and the first does not stand in for the second. Cursor's hardening checklist names both in the same step. Decide the allowed model list, then decide whether members may configure keys of their own at all. The BAA page has the retention half of that argument.

Enterprise admins can allowlist or blocklist 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, the external integrations that give agents access to databases, APIs and internal tools. Admins configure this centrally so members get a consistent, reviewed set of integrations rather than each individual managing their own MCP list.

1. 1Open the admin dashboard model and integration management section.
2. 2Review the 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 team members have connected (or propose to connect).
3. 3Add servers to the allowlist to make them available; add to the blocklist to prevent use.
4. 4Publish the approved list; team member 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. pickers reflect the admin configuration.

I used to read that allowlist as a capability decision, which servers an agent gets to call. That undersells it. .cursorignore covers indexing, agent file reading and context selection, and 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. tools cannot honor it, so an approved server with filesystem or database reach can return content you excluded. Review a server for what it can read, not only for what it lets the agent do.

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. control goes deeper than a server on/off switch. Admins choose which servers an agent can connect to, and then which individual tools inside each server are available. Each tool gets its own setting: auto-run, where the agent calls it without a prompt, or require manual approval, where a person confirms before the call fires.

A single internal CI server can expose a dozen tools, of which maybe two actually ship anything. You might let list_pipelines and read_logs run on their own while forcing manual approval on trigger_deploy. The agent stays useful for read work and slows down before it touches anything that ships.

A pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. Press Enter for the full definition. packages the pieces a workflow needs into one installable unit: hooks, rules, skills, sub-agents and 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. Instead of asking every engineer to wire up the same five integrations by hand, you ship one plugin and the whole team gets the same setup. Which makes a plugin a unit of governance too, since approving one approves everything inside it.

Plugins come from marketplaces. Cursor runs a first-party marketplace, and organizations can stand up private team marketplaces of their own. The marketplace and plugins page covers the manifest and the install side; what matters at the admin end is that a private marketplace holds plugins your org defines, discoverable for members to install or auto-installed so everyone lands on the approved setup.

When one engineer writes a rule that works well, an admin can promote it to a team rule and apply it to the whole org. After that the rule applies the same way on every surface a team member touches, instead of living in one person's settings where, realistically, nobody else goes looking for it. The table below shows where a promoted rule shows up.

A concrete case: a rule that tells a Databricks workflow to query only blessed tables. Promote it as a team rule and every engineer's agent respects the same table allowlist, and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. flags a pull request that reaches past it. A team rule steers the model rather than binding it, though, so pair it with an enforcement hook when the table list is a control you would show an auditor.

Beyond model and 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. controls, admins can set global agent run settings that apply across the team: default model for new agent chats, permission levels for agent actions (read-only vs write), and the repo allow/blocklist for 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.. These settings establish a team-wide baseline that users can override within any bounds admins permit.

Read the default-model setting next to the Cursor Router controls, since its Impose Auto option can lock the model picker to Auto outright.

Both come late. Cursor's admin quickstart reaches pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. Press Enter for the full definition. and 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. governance only after the org-wide switches are set, enforced Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition., the Run Mode policy, distributed hooks and network allowlisting, and it puts the model allowlist and the personal-API-key decision later still, below identity and extension controls.

The model allowlist answers a procurement question, which vendor sees the code and what the tokens cost, and it says nothing about what an agent does once a developer starts one. Run modes and hooks answer that. The 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. allowlist sits differently, since per-tool approval does bound capability, but only for the tools an agent reaches through a server. A shell command that does the same damage is still a run-mode question. Invert the order and you probably spend the review cycle agreeing a model list while any developer who wants Run Everything can still switch to it, with nothing in the path to stop a command.

Part of the model decision is settled before you open the list, since non-ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. Press Enter for the full definition. models require admin approval regardless. The half that team size actually moves is the 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. one, and that is the part I would revisit as the org grows. On a ten-person team the inventory is short enough to read by name, and the allowlist starts to matter at the size where nobody can list every server in use.