Back to Blog

MCP Security Checklist: How to Govern Tool Access Before Your AI Agents Do Something Expensive

MCP Security Checklist: How to Govern Tool Access Before Your AI Agents Do Something Expensive

MCP moved from developer experiment to enterprise infrastructure faster than most security teams expected.

On December 9, 2025, Anthropic said that the Model Context Protocol had grown to more than 10,000 active public servers and had been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, and other AI products. That matters because MCP gives agents real access to systems that change data, move code, and trigger workflows.

Security teams should treat that shift as a perimeter change.

Why MCP Changes the Security Conversation

Most teams first encounter MCP through a product demo. The pitch is simple: connect your AI assistant to GitHub, Slack, a database, or an internal system, and it becomes more useful.

The security implication is just as simple: an agent that can call tools can inspect code, modify issues, query customer data, kick off jobs, or trigger follow-on actions in other systems.

GitHub made that reality much easier to operationalize when it announced on September 4, 2025 that its remote MCP server was generally available with OAuth-based authentication, stronger guardrails, and centralized MCP policy control across Copilot environments. In practice, that means more teams will enable MCP because setup friction is dropping.

The problem is that convenience tends to outrun governance.

The First Mistake: Treating MCP Like a Plugin Problem

MCP is often described as a connector layer. That description is technically true and strategically incomplete.

A connector problem asks whether the tool works.

An identity and execution problem asks five harder questions:

  • Which agents can call which servers?
  • Which servers expose read access versus write access?
  • Which actions require human approval?
  • Which logs are retained if something goes wrong?
  • Who owns review when a new MCP server appears in the environment?

If your team cannot answer those questions quickly, MCP is already operating ahead of its control model.

Scope Is a Security Boundary

One of the most useful details in the Claude Code MCP documentation is also one of the easiest to overlook: MCP servers can be configured with different scopes.

Claude Code documents three of them:

  • local scope for personal, project-specific use
  • project scope through a .mcp.json file in the project root
  • user scope for cross-project access

Those scope choices define a trust model.

The same documentation says project-scoped servers are designed for team collaboration, stored in .mcp.json, and prompt for approval before use. That prompt exists for a reason. A shared MCP configuration can quietly become shared tool access. In other words, a repo can become a distribution layer for agent capabilities.

Security teams already understand this pattern from CI configuration, browser extensions, and infrastructure-as-code. MCP deserves the same treatment.

The Five Control Areas That Matter Most

1. Inventory and Ownership

You need an inventory of approved MCP servers, their owners, and their intended use. That inventory should include:

  • server name and purpose
  • data sources or systems it touches
  • read versus write capabilities
  • authentication method
  • business owner
  • technical owner
  • review date

If you cannot produce that list, visibility is the first control gap to fix.

2. Authentication and Least Privilege

MCP access should inherit the same least-privilege standard you already apply to service accounts and automation. GitHub's GA announcement is useful here because it highlights OAuth 2.1 + PKCE and centralized control instead of long-lived personal access tokens as the preferred model.

That is the right direction.

Teams should prefer:

  • short-lived credentials over static tokens
  • scoped OAuth where supported
  • separate identities for different agent roles
  • approval for high-consequence write actions
  • revocation paths that are easy to test

If an MCP server requires broad, long-lived credentials to be useful, that should slow the rollout down.

3. Approval Boundaries

Not every tool call needs a human in the loop. High-consequence actions do.

AWS made this point clearly in its April 2, 2026 security guidance for agentic AI systems. The post argues that deterministic external controls should be the starting point for agentic security and that higher autonomy should be earned through ongoing evaluation.

That maps well to MCP governance.

The useful question is "which actions are routine enough to automate, and which actions change production state, sensitive data, or customer impact?"

Examples that usually deserve approval or explicit policy gates:

  • write access to production systems
  • external communications sent on behalf of the company
  • actions involving customer or regulated data
  • repo changes that bypass normal review flows
  • changes to secrets, IAM, or deployment configuration

4. Audit Trail and Forensics

If an agent makes a bad call through MCP, you need more than a chat transcript.

A usable audit trail should show:

  • which identity initiated the action
  • which MCP server was used
  • which tool was called
  • what parameters were passed
  • what policy checks ran
  • whether a human approved the step
  • what changed as a result

Without that, incident review turns into guesswork.

5. Vendor and Server Due Diligence

Anthropic's MCP announcement matters for another reason: if the ecosystem really is operating at the scale it described, then many teams will end up evaluating third-party MCP servers they did not build themselves.

That means security review needs to cover both the host product and the server package.

Ask before enabling any MCP server in production:

  • Who maintains it?
  • How is authentication handled?
  • What logging exists?
  • Can permissions be scoped narrowly?
  • Does it support approval checkpoints?
  • How is the server updated?
  • What happens if the upstream maintainer changes behavior?

A 12-Point MCP Security Checklist

Use this as a minimum bar:

  1. Maintain an approved inventory of MCP servers.
  2. Assign both a business owner and technical owner to each server.
  3. Document read, write, and execution capabilities.
  4. Prefer OAuth or short-lived credentials over long-lived tokens.
  5. Separate high-risk write actions from low-risk read actions.
  6. Require approval for sensitive or irreversible actions.
  7. Log every tool call with identity, timestamp, and outcome.
  8. Review .mcp.json usage as a shared-security control with clear ownership and change review.
  9. Restrict project-scoped server additions to trusted workflows.
  10. Re-certify server access on a defined schedule.
  11. Test revocation and kill-switch procedures.
  12. Include MCP activity in incident response reviews.

What Good Looks Like

Good MCP governance makes tool use legible.

The healthiest teams will be able to answer three questions on demand:

  • Which agents can act in our environment?
  • What can they reach?
  • What stops them from doing the wrong thing?

That is the standard to aim for.

The teams that get there first are the ones that treat MCP as part of identity, change management, and runtime control from the start.

If you want to pressure-test your current setup, book an AI Agent Risk Review. The useful output is a concrete map of tool access, approval boundaries, and audit gaps.