How to roll out Cursor to an engineering team

What to settle before you roll out Cursor to an engineering team

Cursor speaks the Model Context Protocol, 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.

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 and Slack, with 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. Start from the catalog or read what the plans include.