MCP Security for AI Developer Tools

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.

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. approvals and least-privilege scoping reduce risk, but they still depend on how the model behaves. Hooks work differently. A hook is a script that Cursor runs at a fixed point in the agent loop, so the policy runs whether or not the model cooperates.

Cursor's docs list hooks for the agent loop, for Tab completions and for workspace startup. These matter most for security:

• beforeSubmitPrompt runs after you press send and before the request goes out. It can block the prompt, and it sees the files and rules attached to it.
• beforeReadFile can stop a sensitive file from being sent to the model, and afterFileEdit sees each edit the agent makes.
• beforeMCPExecution and beforeShellExecution return a permission decision, allow, deny or ask, before an 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. tool call or a shell command runs.
• preToolUse fires before every tool call, and a matcher can narrow it to one tool type, such as Delete.
• stop runs when the agent finishes, for logging or final checks.

Cloud agents run the command hooks in your repo's .cursor/hooks.json. On Enterprise plans, they also run the team and enterprise hooks configured in the dashboard, so a security team can build a control once and ship it to every member. Hooks from every level run, and a deny from any of them blocks the action. Hooks matter more in a cloud agent, because it doesn't use Run Modes and never asks you to approve an action.

Check the gaps before you rely on them. Hooks don't run during the read-only turns a cloud agent sometimes starts with. beforeMCPExecution doesn't run in cloud agents yet, but preToolUse still fires for tools on HTTP 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, as MCP:<tool_name>, and can deny the call. Dashboard hooks don't take per-hook options such as failClosed.

The desktop app, by default, waits only a short time for hooks to load before it sends a prompt. On Enterprise, if a hook must run on the first prompt after a restart, turn on Block until hooks are ready in the dashboard's hook settings.

Keep it off the public internet. When one security engineer weighed letting a coworker run a locally exposed AI tool, he settled on a setup that was safe and still usable: a locked-down private network connector that the coworker could reach from a phone.

The tool's own docs recommended Tailscale. He used Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. to have the agent write the Terraform in an infra/ directory, with defaults taken from the docs and nothing open to the internet. Then a security subagent looked for risks before he opened the pull request.

Scope first. Approving fewer tools is configuration that takes minutes, and every tool you leave out is one less thing a hook has to police. On Enterprise, admins set that scope for the whole team in the dashboard's 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, which approves servers and limits which of their tools run automatically. Hooks are scripts you then own and keep working across the IDE, the CLI and cloud agents.

If you write hooks first, you can end up encoding policy for a server that should never have been approved. That is maintenance spent making a bad grant survivable. Save hooks for what scoping can't reach: screening a prompt before it reaches the model, and any rule that has to hold when the model does not cooperate.

In mcp.json, as a placeholder instead of a value. A project server is configured in .cursor/mcp.json in the repo, so if you commit that file, it travels to everyone who clones the repo. A personal server is configured in ~/.cursor/mcp.json and stays on your machine. Put ${env:DATABASE_URL} in the server's env block, and each person supplies the variable from their own environment. The committed file then names the server without carrying the secret.

The transport sets the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition.. A stdio server is a local process that Cursor runs for one user. A remote server reached over HTTP reaches as far as its API token does. In a local agent, put only its read and search tools on your allowlist, so its create, update and migration calls still get checked before they run. A cloud agent never stops to ask, so check which account the token belongs to before the server goes near a cloud agent or a production system.