AI Coding Security Checklist

Four controls decide whether security will sign off: who has access, what the policy allows, how data moves and whether anyone measures adoption. Settle them before the pilot starts, because they apply whichever tool you pick.

The owner column matters as much as the controls. A control with no named owner goes unchecked until someone has to answer for it. If nobody owns identity, for example, nobody checks that people who leave lose access.

Security does not own all four. Identity is IT's system of record, and policy is engineering leadership's call about what the team may ship. Adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and it will ask about both.

Data flow is the question that stalls approvals, so answer it before the review meeting. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of the answers come from the vendor's documentation and your own configuration. Ask the vendor for anything the documentation leaves out, and note where each answer came from.

The stack below breaks a rollout into layers. Policy comes first because the other layers carry it out. Identity controls who gets access, workflow moves code from prompt to merge, and measurement shows whether the rollout is working.

Start narrow, and expand only when the pilot earns it.

1. 1Week 1: pick one team, one repo and three realistic tasks.
2. 2Week 2: write the workflow standard from the pilot.
3. 3Week 3: train champions and add policy guardrails.
4. 4Week 4: expand only after quality, cost and review load are visible.

Treat the four weeks as an order, not a deadline. The first two weeks mostly show you what your standard should say. A pilot too broad to watch closely can't teach you that, so it starts with one team and a few real tasks. Pick the team that will tell you when something breaks, even if another team would produce a better-looking result. Put policy and training in place before the rollout grows, because both are harder to add once people have formed their own habits.

Expansion is the step to slow down. After a good pilot, the pressure to widen access can arrive before the evidence does. Before you add teams, answer three questions with numbers: did review load go up or down, what does a developer cost per month, and did quality hold.

Record the same numbers before the pilot starts, so you have a baseline to compare against. Two more weeks of the same pilot cost less than a rollout you have to walk back, so run them if any answer is still a guess.

Cursor ships often, so advice about it can go out of date. The table summarizes Cursor's recent releases, so you can check this page against the current product. For each release's date and sources, see What's new in Cursor 2026.

Sort every item into one of those two groups before you sign anything. Deterministic controls block an operation whatever the model proposes: approvals, hooks, sandboxing and file system permissions. Best-effort controls only make the bad path less likely. That group includes the Run Mode allowlist, .cursorignore and team rules. The model attempts to follow rules, but Cursor calls them suggestions, not guarantees.

A hook counts as a boundary only if it fails closed. By default, Cursor lets the action through when a hook crashes or times out, so set failClosed: true on any hook the checklist relies on. Hooks set up in the dashboard don't take that option, so define a boundary hook in a hooks.json file.

Read the .cursorignore item twice. It keeps files out of agent file reading and context selection, and it is not a security boundary. A user can still open an ignored file by hand, and terminal commands 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 can still read it. For anything you would have to report, Cursor's guidance is to use file system permissions or to encrypt the data.

Auto-review sits in between. It runs allowlisted calls, sandboxes shell commands when it can, and routes the rest through a classifier. Cursor describes both the allowlist and the classifier as best-effort and says to combine the allowlist with hooks, so don't list Auto-review as the control itself.

A misfiled item does its damage late. The checklist passes and gets filed while it describes protections that don't hold, and nobody finds the gap until the review that follows an incident.

Not automatically. Cloud agents run command-based hooks from .cursor/hooks.json in your repository, plus team hooks and enterprise-managed hooks on Enterprise plans. User-level hooks in ~/.cursor/hooks.json don't load, because the cloud VM has no access to your home directory configuration.

So a hook an engineer tested on their own laptop may not exist in a cloud run at all. Prompt-based hooks don't run there either, because cloud agents run command-based hooks only.

Some repository hooks are missing too. beforeMCPExecution, afterMCPExecution and sessionStart are deferred for cloud agents. sessionEnd doesn't apply, and neither do the Tab hooks, because Tab completion is an IDE feature. Cloud agents also sometimes start in a read-only environment for early exploratory turns. Hooks don't run during those turns, and they start once the agent has a writable environment.

Treat where a control runs as part of the control. Give the checklist a column for where each control applies: local, cloud or both. Without that column, a control that only covers local runs reads as if it covers cloud runs too.

Because people route around it. Cursor's guidance is to allowlist Cursor domains such as *.cursor.sh and to exclude them from SSL inspection. The reason it gives is what happens otherwise: users disable security to "make it work".

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. have their own outbound policy, with three access modes: Allow all network access, Default + allowlist, and Allowlist only. We would start from Allowlist only, the strictest mode, if your team can absorb the work of adding destinations as they come up. Enterprise admins can lock the team-level setting so members can't override it. 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. network policy is set per server either way.

Three, and Cursor publishes each one. Cloud Agent environment snapshots are deleted after 30 days of inactivity, and each start or resume extends the expiry by another 30 days. Conversation history is kept indefinitely by default. Enterprise admins can set a retention window of Indefinite or 90 days for the team's Cloud Agent data, with custom windows in early access. Deleting an individual account removes that user's data within 30 days.

Older checklists list a fourth number: indexed codebases expiring after 6 weeks of inactivity. That no longer applies. Cursor's search docs say Instant Grep builds its index on your machine, and that Cursor does not store embeddings of your codebase for search.

One Cursor page reads differently. The privacy and data governance page says the encrypted repository copies a Cloud Agent works on are deleted after the agent completes. The Cloud Agent security pages say the cloned code can stay in snapshots under the 30-day inactivity window. Quote both, and ask Cursor which one governs your setup.

Put these numbers in the document, not in a follow-up email. The reviewer can check them against Cursor's pages without your help, so quote them exactly instead of rounding them.