Buyer guide · agentic harnesses
MCP hardening for coding agents
MCP servers extend agents with filesystem, shell, and network tools. Treat each install like granting operator access — allowlist servers, scope folders, fail closed, and log calls; ignore files do not block MCP.
Who this is for: Security-conscious platform and engineering teams rolling out MCP-enabled coding agents (Cursor, Claude Code, Cline, Goose) who need allowlists, scoped access, logging, and fail-closed behaviour before production repos.
What actually matters
- Each MCP server install is equivalent to granting filesystem, shell, or network access — not a harmless plugin.
- Org allowlists and approval workflows must exist before developers install servers ad hoc.
- Folder and network scope per server must match the repo’s data classification.
- Harnesses should fail closed on unknown tools — silent attempts bypass security intent.
- Tool-call logs must persist beyond the live UI for post-incident review.
- .cursorignore and .clineignore do not block MCP or approved shell commands.
- MCP configs should align across Claude Code, Cline, Goose, and Cursor so one permissive bypass does not spread.
ACE recommendation
Ship a short MCP allowlist with the rollout guide, require security review before any server reaches production repos, and audit tool logs weekly during the first pilot month.
Set up the shortlist
Useful comparisons
How to run this decision
- 01Draft a short MCP allowlist document: approved servers, owners, scopes, and review cadence.
- 02Require security sign-off before any new server reaches shared or production repositories.
- 03Configure each harness to reject unknown tool requests rather than silently attempting them.
- 04Enable or export tool-call logs to your SIEM or audit store during the pilot month.
- 05Train developers that ignore files do not protect against MCP — scope servers instead.
- 06Audit MCP configs weekly in the first pilot month; trim unused servers.
Common pitfalls
- Treating MCP as “just integrations” without filesystem and shell risk assessment.
- Letting each developer install personal MCP servers on company repos.
- Assuming .cursorignore protects secrets from MCP read tools.
- No persistent logs — incidents become unrecoverable he-said-she-said.
- One developer’s permissive Claude Code MCP config becoming the team template.
Ask before you buy
- Which MCP servers are on the org allowlist, and who approves new installs?
- Does each server’s folder and network scope match the repo’s data classification?
- Does the harness fail closed when an unknown tool is requested, or silently try anyway?
- Are tool calls logged and reviewable after an incident — not only live in the UI?
- Do developers know .cursorignore and .clineignore do not block MCP or approved shell commands?
- Are Claude Code, Cline, Goose, and Cursor MCP configs aligned so one bypass does not become the team default?
More buyer guides
Related decisions
Other harness buyer guides that answer the next question after this one.
Buyer guide
Editor vs terminal: which coding assistant workflow fits?
Choose the surface your team will actually use before comparing model quality.
Buyer guide
How to roll out an agentic harness without losing review discipline
A staged rollout pattern for teams that want speed without turning generated patches into unowned production risk.
Buyer guide
Agentic harness pricing: seats, tokens, and overage
Compare subscriptions and usage-based plans by the work they enable, not the number printed on the landing page.
Buyer guide
Coding-assistant myths in 2026: what the product pages blur
A myth-versus-reality check for coding assistants whose pricing, editor surfaces, privacy paths, and autonomy are easy to collapse into one misleading label.
Buyer guide
Enterprise AI coding assistant procurement checklist
A compact procurement block for security, legal, IT, and finance teams evaluating coding assistants beyond the demo and the seat price.
Buyer guide
Local LLM coding setup: Ollama, LM Studio, llama.cpp, and MLX
Pick a local inference stack and wire it to an agent harness without the usual traps — wrong ports, tiny default context, bad quants, and mismatched API prefixes that make agents look broken when the model is fine.