MCP and the New Access Control Problem

What MCP actually changed

Before Model Context Protocol and standards like it, wiring an AI agent up to a CRM, a codebase, a ticketing system, and an internal database meant writing and maintaining a custom integration for each one. That friction was, accidentally, a security control: someone had to deliberately build each connection, which meant someone had to think about what it should be allowed to do.

MCP removes that friction almost entirely. An agent can connect to an MCP server and immediately see every tool it exposes: read a database, send an email, push a commit, modify a record. That's the entire point of the protocol, and it's genuinely useful. It's also why the default configuration for most MCP integrations today is "everything the server exposes," not "exactly what the task requires."

Why this is an identity problem, not a networking problem

It's tempting to treat MCP access as a network or API-key question: is the connection encrypted, is the key rotated. Those matter, but they're not the core issue. The core issue is the same one IAM has always solved for human accounts: does this identity have exactly the access its job requires, and can you prove it?

An MCP-connected agent is an identity. It authenticates, it acts, and its actions have consequences in your systems. Treating that connection as a plumbing detail instead of an access grant is how an agent built to summarize support tickets ends up able to delete them too, because nobody scoped the permission down from whatever the MCP server exposed by default.

What proper scoping looks like

Three practices cover most of the risk:

• Scope by capability, not by server. "Connected to the CRM" is not a permission. "Read-only access to the customer records table" is. Most MCP servers support granular scopes; most default configurations don't use them.
• Treat every tool grant as an access decision. The same question you'd ask before giving an employee database access applies here: does this specific agent, for this specific task, need this specific capability? If the answer is "it might be useful later," that's a no.
• Log every call, and review it. An access grant without a review cadence degrades into standing, unmonitored access, whether it belongs to a person or an agent. MCP tool calls should feed the same review process as any other privileged access.

// default: everything the server exposes
{ "mcp_server": "crm-mcp", "access": "full" }

// scoped: exactly what the task requires
{
  "mcp_server": "crm-mcp",
  "tools_allowed": ["customers.read"],
  "tools_denied": ["customers.delete", "customers.export"],
  "rate_limit": 100
}

The uncomfortable part: most organizations can't answer this today

Ask most engineering teams which MCP servers their agents are connected to, and what those agents can actually do with them, and you'll get a partial answer at best. That's not a failure of any one team; it's a predictable result of a protocol designed to be effortless spreading through an organization faster than governance processes were built to track it. It's exactly the same pattern that made shadow IT a problem for SaaS a decade ago, moving faster, because agent tool access is often a few lines of config rather than a purchase order.

This is the same discipline we bring to AI agent governance more broadly: an owner, a scope, an expiry, and a review cadence for every agent identity, MCP-connected or not.