# How to roll out Cursor to an engineering team > Roll out Cursor to an engineering team in an order that stays reversible: scope first, one role, narrow rules, then the systems people ask for. **TL;DR** Decide what the team may reach before you hand anybody an endpoint. Put everyone on one role, write restrictions against that role rather than against people, start with the two or three systems engineers ask for first, and check the audit trail after a week. Widening later is one rule change. Narrowing after a surprise is a conversation. ## What to settle before you roll out Cursor to an engineering team Cursor speaks the [Model Context Protocol](https://modelcontextprotocol.io/), so the rollout question is not whether it can reach your systems but which ones it should. The temptation is to connect everything and let people discover what is useful. It works for a week and then produces a question nobody can answer, which is what an engineer's agent touched in a system that matters. Settle three things first. Which systems are in scope. Which operations in those systems the team needs, as opposed to which ones exist. And who is accountable for widening the list later, because that request will arrive within days. Scope narrowly on purpose. Two or three systems that engineers already ask for beats a full catalog, because the first week produces a usage record you can read, and reading it is how you learn what the next rule should be. Widening later is a single rule change that lands in about two minutes. Narrowing after somebody has built a habit is a conversation with a team. ## One role, not a role per person Each member holds exactly one role, enforced by a unique index. That constraint shapes the whole rollout, so it is better designed around than worked around. Put the engineering team on one role. Write your rules against that role. When somebody joins, they get the role and inherit every rule already attached to it, with no per-person setup and nothing to forget. Resist the per-user exception for as long as you can. A user-targeted restriction replaces role rules entirely rather than layering on top of them, so granting one engineer a narrow extra permission silently discards every role rule that would otherwise have constrained them. That is a sharp edge, and it cuts in the direction of too much access rather than too little. Roles form a strict subset chain, from `Guest` through `Member`, `Team Admin`, `People Admin` and `Org Admin` to `Org Owner`, each tier built by spreading the one below. Most engineers belong at `Member`. Whoever administers the rollout needs enough to manage restrictions, which is a deliberate step up rather than something to hand out broadly. If the team signs in through your identity provider, the mechanics of that are [a separate layer from authorization](/blog/mcp-server-with-sso/). Two seats cost nothing and are worth using. `Auditor` is free and read-only, so a security reviewer who wants to watch the first month does not consume a license or need somebody else's login. `Guest` is free as well. ## Write the restrictions before anyone connects Restrictions decide which connectors and which individual tools a target may reach. Targets are `role` or `user` only, and the organization default is the absence of any rule, which means allow-all. There is no org-wide switch to flip, so the rules you write against the role are the whole of your policy. The behavior to know before you write your first rule is the allowlist stage. It engages on the presence of an allow rule rather than on its contents, so an allow rule naming nothing denies everything. That is the strictest rule the system can express and it is reachable by accident. Blocks and allows are also not symmetric. A block matches on the tool name or on the pinned operation. An allow matches on the pinned operation only. The reason is that a tool's advertised name can be changed by whoever edits the connector's documentation, so a name is a token the governed party controls, while the operation is not. Enforcement runs at four points against the same resolver, so a rule is not a single door check: browse, connect, advertise and execute, plus a final check on the fully-substituted outbound URL. ## Start with the systems engineers ask for first For most engineering teams the first requests are the tracker and the place the team talks. Both are in the catalog: [Jira](/connectors/jira/) and [Slack](/connectors/slack/), with [Confluence](/connectors/confluence/) close behind when documentation is the bottleneck. Connect each account once. Clients then point at one address, `POST /mcp`, standard MCP over Streamable HTTP behind OAuth, and sign in. There are no per-toolbox URLs and no embedded tokens, so nothing has to be distributed to each engineer and nothing has to be collected back later. Expect the tool list to collapse. Past 30 tools, connected tools sit behind two meta-tools, `search_tools` and `execute_tool`, and the threshold counts catalog operations and connected tools together. The control-plane catalog alone is dozens of operations, so one connected app is usually enough to trip it. This is the normal case, not a degraded one, and `execute_tool` is only a naming indirection that unwraps to the same name and arguments through the identical gates. ## Freeze the arguments that must not vary Some arguments should never be the model's decision. A project key, a workspace, a channel that output belongs in. Frozen parameters handle this with two effects at once. Frozen keys are stripped from the advertised schema, so the model never sees them and cannot reason about changing them. Frozen values are merged over caller arguments at execution, so passing the key anyway cannot un-freeze it. The full precedence runs entry defaults, then caller or model arguments, then frozen parameters last. This is usually a better tool than a block rule for the class of problem where the operation is fine and only its target needs pinning. Blocking a write removes a capability the team asked for. Freezing its destination keeps the capability and removes the failure mode. ## Read the trail before you widen anything After a week, the audit trail tells you what the team actually used, which is rarely what the rollout plan predicted. One entry is written per tool-call attempt, succeeded or failed, and both name the account. The recorded connection is the one actually reached, taken from the execution rather than from the intent, so the answer to which workspace an agent wrote to is in the record rather than inferred from it. `actor_kind` is a stored field with `ai_assistant` among its values, so agent activity is separable from human activity without guessing from a user agent string. Argument names and counts are logged. Argument values never are. That is worth knowing in both directions: it is why the trail is safe to expose to reviewers, and it is why the trail cannot tell you the contents of what was written. The trail is append-only and eventually consistent, so a row may take a moment to appear. ## Where this goes wrong Two failure modes are common enough to plan for. The first is scope creep through exceptions. Each individual request is reasonable, and user-targeted rules replace role rules rather than adding to them, so a handful of exceptions leaves you with people whose actual reach nobody can state. Push changes into the role instead, even when that widens access for a few people who did not ask. The second is treating the rollout as finished once it works. The useful checkpoint is a month in, reading the trail and asking which permitted operations were never used. Those are the ones to remove, and they are visible only after real use. One thing this does not give you: an MCP server never sees a user prompt, so no endpoint of this kind can be protected against prompt injection, and Elaichi's is not. Access rules, scope limits, output redaction and the audit trail all hold on every call. Model judgment is not among them. The same reasoning applied to a wiki is in [keeping private pages private](/blog/connect-notion-to-chatgpt-privately/). Start from [the catalog](/connectors/) or read what the [plans include](/pricing/). ## FAQ ### How long does it take to change what the team may reach? A change to a role or to a restriction takes effect within about two minutes, across the endpoint, the console and the REST interface alike. Removing or suspending a member is faster: every live grant is revoked in the same transaction as the membership change, and the grant is re-read on every call, so the next call is the boundary. ### Should each engineer connect their own accounts, or should the team share one? Personal connections keep each person inside what they are already allowed to reach in the underlying system, which is usually what an engineering team wants. The cost is that offboarding has to resolve them: a personal connection referenced by a toolbox entry has to be transferred or deleted before the member can be removed. ### What stops the model from using a tool nobody intended? Restrictions decide which connectors and tools are reachable, and tools withheld by a restriction are never advertised, so the model does not see them. Frozen parameters go further by stripping specific arguments from the advertised schema entirely and merging fixed values over whatever the caller sends. ### Can we try this before committing to seats? There is a 14-day trial with no credit card required to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. ## Read next - [Running an MCP server with SSO for a whole company](/blog/mcp-server-with-sso/) — An MCP server with SSO answers who is calling. It does not answer what they may reach, and the gap between those two questions is where most rollouts get stuck. - [Connect Notion to ChatGPT without oversharing](/blog/connect-notion-to-chatgpt-privately/) — To connect Notion to ChatGPT without exposing private pages, the connection has to carry each person's own access rather than a shared workspace credential. - [Running your own MCP servers, or not](/blog/running-your-own-mcp-servers/) — Running your own MCP servers is cheap for one team and expensive for a company. The line is not the servers, it is credentials, revocation and the audit trail.