MCP Security for AI Developer Tools

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. security review is a governance question before it is a tooling one. Four controls decide whether security can sign off: who has access, what the policy allows, how data moves, and whether anyone is measuring adoption. The table assigns each an owner.

The owners column matters more than the controls themselves, which I realise is a slightly odd thing to say about a governance table. But a control with nobody's name against it is a control nobody checks, and it fails at exactly the moment someone has to answer for it. The usual mistake is assuming security owns all four. They don't. Identity is IT's system of record, policy is an engineering-leadership call about what the team is allowed to ship, and adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and they will ask about both.

Data flow is the one that stalls approvals, so answer it before the meeting rather than during it. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of that comes straight from the vendor's documentation and your own configuration. It's dull work, but it turns a vague objection into a specific one, and specific objections are the kind you can actually close.

A rollout works when it starts narrow and earns its expansion. One team, one repo and a few real tasks in week one, with policy and training in place before anyone scales it wider.

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.

Four weeks is a shape, not a rule. The dates matter much less than the order, and the reason to start with a single team is that those first two weeks are mostly you finding out what your standard should even say. You can't write that from a pilot too broad to watch properly. Pick the team that will tell you when something doesn't work, rather than the team most likely to hand you a good result.

Expansion is where this usually goes wrong. Not because anyone's careless, either — the pilot went well, someone senior noticed, and now there's pressure. That's a hard thing to say no to. Before you add teams, though, check that you can answer three things with numbers instead of impressions: did review load go up or down, what does a developer actually cost per month, did quality hold. If any of those is a shrug, another fortnight of the same pilot beats a rollout you have to walk back.

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 the model behaving. Hooks are different: they are actual shell scripts that execute deterministically at lifecycle points, so a policy fires whether or not the model cooperates.

There are roughly a dozen trigger points across the IDE and CLI. The ones that matter most for security:

• Prompt submit - inspect the prompt before it ever reaches the model.
• File read / file write / file delete - gate what the agent can touch.
• 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 and before MCP access - vet an external call before it runs.
• Terminal tool call - gate shell commands the agent wants to run.
• Stop hook - runs when an agent finishes a turn, for logging or final checks.

Hooks also run in cloud agents, and they can be pushed centrally so a security team builds the control once and ships it across every team and agent type. A before-prompt hook can even audit which rules are in context for compliance.

Don't put it on the public internet. When one security engineer evaluated letting a coworker run a locally-exposed AI tool, the balance he landed on was safe but still usable: a private network connector, locked down, reachable from a phone.

Scope first. Approving fewer tools is configuration, it takes minutes, and it shrinks the surface a hook would otherwise have to police. Hooks are shell scripts you then own and keep working across the IDE, the CLI and cloud agents.

Write them first and you can end up encoding policy for a server that should never have been approved. That is real maintenance spent making a bad grant survivable. My read is that hooks earn their keep where scoping cannot reach: screening a prompt before it reaches the model, and anything you need to hold when the model does not cooperate.

Of the dozen or so trigger points above, I'd guess most teams only ever wire two or three.

In mcp.json, as a placeholder rather than a value. A project server sits in .cursor/mcp.json at the repo root and travels with the repo to whoever clones it; a personal one sits in ~/.cursor/mcp.json and stays on your machine. Put ${env:DATABASE_URL} in the env block and each person supplies the variable from their own environment, so the committed file names the server without carrying the secret.

Now, the line in that config that decides blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. is the transport. A local stdio process Cursor runs is scoped to one workspace. A remote server reached over HTTP, holding a broad API token, reaches as far as that token does, which is the same feature with a much longer arm. Approve the read and search tools, leave create, update and migration tools unapproved, and check which account the token belongs to before any of it goes near a production system.