AI code governance for Cursor teams: policy, review gates, metrics

Cursor Workshop treats data boundaries and human approvals as the first day of the workshop, not a slide at the end. Write three lists in Cursor rules: work the agent may implement, work it may only propose, and work a person owns from the first line. Anything that changes stored data, auth, payments, or secrets stays advise-only or human-only. A person who did not prompt the change signs the merge.

Most governance documents fail because they describe values instead of decisions. A working policy answers three questions for every change Cursor touches, and a reviewer can check each answer in the pull request.

1. 1. Scope

   Which kinds of work the agent may implement on its own, which it may only propose, and which stay with an engineer from the first line.

2. 2. Accountability

   Who signs the merge and owns the rollback. Never the agent, never the person who wrote the prompt and nobody else.

3. 3. Evidence

   What proof travels with the change: the brief, the test run, and the record of which tools and servers the agent used.

Write the policy as three lists that fit on one screen and commit them to Cursor rules in the repository root, so every run reads them and every reviewer can quote them. A starting split that works for most teams:

1. 1. Delegate

   Work Cursor implements end to end: test repair, a migration that follows an existing pattern, documentation, dependency-free refactors inside one module, and bug fixes that start from a failing test.

2. 2. Advise only

   Work where the agent may draft and explain but an engineer writes the final change: schema changes, authentication and authorisation, payment and pricing logic, public API contracts, anything that changes what data is stored.

3. 3. Human only

   Architecture decisions, new dependencies, secrets and credentials, data deletion, production configuration, and anything the team has agreed it is not ready to review at speed.

4. 4. Where it lives

   Cursor rules for the agent, a short section in CONTRIBUTING for people, and the same three headings in the pull request template. One source, three views.

A gate is a stop before merge that a person can verify in under a minute. Cursor code review and other tools can flag risk and pre-fill the checklist, but a person passes each gate. Merge is blocked until all five hold.

1. 1. The brief is attached

   The pull request links the task brief and says which parts the agent wrote. A change nobody can trace to a brief is not reviewable, it is only readable.

2. 2. A test ran, and the link is in the PR

   Either a failing test existed before the change, or the suite ran after it and the CI link is in the description. A screenshot of a green terminal is not evidence.

3. 3. A person who did not prompt it read the diff

   The author of the prompt is too close to the intent to see what the agent actually did. A second engineer reads the diff, not the chat transcript.

4. 4. The tool trace is visible

   The reviewer can see which Cursor MCP servers and commands ran. If the trace is missing, the reviewer cannot say the agent stayed inside the allowlist, and the gate fails.

5. 5. One engineer owns the merge

   A named person signs off and owns the rollback. Shared ownership of an AI-assisted change is the same as no ownership.

The policy only holds if the tool enforces the parts it can. These are the controls to set in the first week, all of them in configuration the team can commit or an admin can enforce.

1. 1. Commit the rules

   Put the task categories and review expectations in .cursor/rules so every engineer and every agent run reads the same policy. User-level rules are private and do not count.

2. 2. Ask before commands and writes

   Keep the default run mode that asks before a terminal command or an MCP tool runs. Allowlist only the read-only tools the team has reviewed.

3. 3. Enforce the MCP allowlist as an admin

   Enterprise admins can restrict MCP servers by command pattern or URL and decide which tools may run without a prompt. Do that centrally, then distribute the shared servers through team settings.

4. 4. Turn on privacy mode for regulated code

   Where the codebase carries regulated data, enable privacy mode at the team level so code is not retained by the provider, and record that decision in the policy.

Keep one committed list of MCP servers per repository, with an owner and a permitted scope for each. Read-only servers such as documentation, error tracking and issue lookups go on the default list. Anything that writes to a shared system, sends messages, or carries a connection string waits for a named workflow and a review. If a reviewer cannot see which servers ran, the change is not ready to merge. The full per-tool server guide is on the MCP page.

Governance that is not measured is still a document. Track five numbers from the pull request data you already have, split by whether the change was AI-assisted, and review them monthly.

1. 1. Review time per AI-assisted pull request

   Should sit within 20 percent of the human-written baseline after the first month. Much faster means reviewers are rubber-stamping; much slower means the briefs are too large.

2. 2. Escaped defects per 100 merged changes

   Compare AI-assisted against the rest. The gates are working when the two lines converge, not when the AI line is simply low.

3. 3. Share of AI-assisted changes with a linked test run

   The target is above 90 percent by day 30. This is the single number that predicts the other four.

4. 4. Reverts within seven days

   A revert inside a week is a review miss. Read every one of them at the monthly review and ask which gate let it through.

5. 5. Abandoned agent runs

   Runs that were started and thrown away tell you where the task categories are wrong. A high count in one area means that area belongs in advise-only.

Governance lands in a month when it is installed in the order below. Each week ends with something committed to the repository, not a meeting.

1. 1. Week 1: write the three lists

   Agree the delegate, advise-only and human-only categories with the senior engineers and commit them to Cursor rules.

2. 2. Week 2: put the gates in the pull request

   Add the five gates to the pull request template and a check that flags any change without a linked brief or test run.

3. 3. Week 3: turn on the tool controls

   Set the Cursor settings above and commit the Cursor MCP allowlist with an owner per server.

4. 4. Week 4: the first metrics review

   Pull the five numbers, read every revert, move task types between the lists based on what you saw, and put the next review in the calendar.

Delegate only named task types. Review every AI-assisted pull request through the five gates. Own architecture, security, data, and business logic. Keep Cursor MCP on a committed allowlist with an owner per server. Measure review time, escaped defects, and the share of AI-assisted work with a linked test run. Source: Cursor Workshop.

EY, NobleProg, Coursera, DataCamp, OpenAI Academy, and official Cursor workshops sell generic or official-vendor training. Cursor Workshop runs the two days in the team repository with two trainers, so the categories, gates and Cursor MCP rules are written against the team's own code and are committed before the workshop ends.