What MCP Servers Are and Why IT Should Care
If your developers or power users are running Claude, Cursor, or any agentic AI tool this year, there’s a reasonable chance they’ve already connected it to an MCP server — and a near-certain chance that connection isn’t in your AI tool inventory.
on Unsplash
MCP (Model Context Protocol) is an open standard that lets AI assistants talk directly to external tools and data sources: databases, file systems, APIs, internal applications. Think of it as a universal adapter that turns a chat-based AI into something that can actually do things in your environment. Anthropic released the spec in late 2024, and the ecosystem has grown quickly. Developers love it because it dramatically expands what an AI assistant can reach without custom integration work. That’s also exactly what makes it a governance problem.
The Cloud Security Alliance published a detailed threat taxonomy covering 10 MCP-specific risks. Most of it is written for security architects and red teamers. If your job is AI governance for a 100-person company without a dedicated compliance team, you don’t need all ten. You need to know which ones change what you’re doing this week — and what to actually do about them.
Four of the ten are operationally urgent. The rest are real but either require attacker access you can address through existing controls, or they’re variants of problems you’re already managing elsewhere.
Excessive Permissions: The MCP Version of “Why Does This Bot Have Admin Access?”
This is the one most likely to bite you first, and it’s the most familiar shape. When someone installs an MCP server to connect their AI assistant to, say, a company file share or internal database, the server needs credentials and permissions to do its job. In practice, those permissions tend to get set wider than necessary — because scoping them down takes time and the person installing it is focused on getting the integration working, not on least privilege.
The CSA taxonomy calls this “Excessive Permissions” and flags scope creep as a secondary concern: even if the initial permissions were reasonable, MCP servers can accumulate access over time or across sessions without explicit reauthorization. That’s the same failure mode you see with OAuth apps that get broad scopes at install and never get reviewed again.
The practical question isn’t whether your developers understand least privilege in principle. It’s whether the MCP servers they’ve connected to have been reviewed by anyone at all, and whether those permissions are documented somewhere you can actually audit. If an employee’s AI assistant has read/write access to a production database through an MCP connection that lives entirely outside your tool register, that’s a shadow AI exposure, not just a security misconfiguration.
What to do: when you find MCP connections during your next AI tool discovery sweep — and if your developers are using agentic AI tools, you will find them — add the connected MCP server and its permission scope to your AI tool inventory alongside the AI client itself. Treat it the same way you’d treat an undocumented API integration.
Credential and Token Exposure in MCP Configurations
MCP servers authenticate to the tools and services they connect to. That means API keys, service account credentials, and access tokens end up stored somewhere — in configuration files, environment variables, or whatever secret management approach the person who set it up chose in the moment.
The CSA flags this as a distinct risk because the MCP layer adds a new attack surface for credential theft that most organizations haven’t thought through yet. This isn’t hypothetical: the same class of vulnerability showed up in Claude Code CVEs earlier this year, where improperly handled credentials in AI-adjacent tooling could be extracted by a malicious actor with the right access. The MCP threat model extends that surface. If an MCP server config is committed to a shared repository, stored in plaintext on a developer’s laptop, or accessible through a compromised AI session, the credentials it holds can move.
For mid-market IT teams, the governance question is straightforward: do you know where the credentials for your MCP-connected services live, and are they rotated on a schedule consistent with your existing API key policy? If you’ve already done work on AI vendor risk — specifically around how AI tools handle API keys for third-party services — this is the same problem one layer deeper. If you haven’t, this is a good forcing function to start.
Supply Chain Risk: Malicious and Abandoned MCP Servers
The MCP ecosystem is largely community-built. Most MCP servers come from individual developers or small open-source projects, not from vendors with security programs, SOC 2 audits, or a track record you can evaluate. The CSA identifies supply chain compromise as a top-tier risk, and the mechanics are already playing out in the wild.
The pattern the security community has started calling “rug pulls” applies directly here: an MCP server gets published, picks up a user base, and then either gets abandoned (leaving unpatched vulnerabilities in production) or gets taken over by a malicious actor who pushes a compromised update. The Clinejection incident — where a widely-used extension in the Cline AI coding ecosystem was found to contain malicious behavior — is exactly this shape. An MCP server you connected to three months ago and stopped thinking about is still running, still has credentials, and still has whatever permissions you granted at setup.
This is the shadow AI problem at an infrastructure level, not just an application level. When you build or review your AI tool inventory, MCP servers need their own entries: what server, what version, who maintains it, what data or systems it touches, and when it was last reviewed. “We connected it and it works” isn’t a governance posture.
For unapproved AI tools that employees have deployed at the MCP layer, you may not even know the inventory exists. That’s where discovery has to start.
Prompt Injection via MCP: Why This Changes Your Threat Model
Prompt injection is the top-ranked risk in the CSA taxonomy, and for good reason — but if you’ve been following AI security coverage, you’ve seen this one before. The short version: an attacker embeds malicious instructions in content that an AI agent reads through an MCP connection, and those instructions hijack what the agent does next. A document retrieval MCP server that pulls from external sources, a web browsing MCP that accesses attacker-controlled pages, a tool that reads inbound emails — any of these can become an injection vector.
I’ve covered prompt injection mechanics in depth in earlier posts here, so I won’t re-explain the attack chain. What changes in the MCP context is scope: because MCP-connected agents can take actions (write to databases, send messages, execute code, call APIs), a successful prompt injection doesn’t just produce bad output — it can trigger real downstream effects inside your environment. The blast radius is larger than a browser-based chatbot that hallucinates a wrong answer.
The governance implication is that MCP-connected AI tools need to be in a different risk tier than read-only AI assistants. An AI tool that can only generate text has a limited blast radius. An AI agent with active MCP connections to internal systems is operationally closer to a service account than to a SaaS app, and should be assessed accordingly.
What to Do This Week for MCP-Aware AI Governance
If you’re already running an AI tool discovery process, add one step: specifically ask your developers and technical leads whether they’re using any MCP servers or agentic AI tools with tool-use capabilities. Most AI governance inventories weren’t designed with this layer in mind. The tools employees are using — Claude Desktop, Cursor, Continue, Cline, and similar — may each have multiple MCP connections that are effectively invisible to a standard app-level discovery sweep.
For each MCP server you find, capture four things: what it is and who maintains it (individual developer, open-source project, or commercial vendor), what credentials or permissions it holds, what internal systems or data it touches, and when it was last reviewed or updated. That’s enough to slot it into your existing AI risk registry and assign an owner.
If you don’t have a structured way to do that yet, the lightweight process we use for shadow AI tool intake translates directly — see the Shadow AI Tool Intake process for a template you can adapt for MCP entries.
For teams that have done broader AI tool discovery work before, MCP is a new layer on a familiar problem. The shadow AI discovery approach we’ve documented works at the application layer; you’ll need to add explicit technical outreach to find what’s running underneath. On the permissions and credential questions specifically, loop in whoever owns your API key rotation policy — this isn’t a standalone AI governance issue, it’s where AI governance intersects with the controls you (hopefully) already have.
The CSA’s full taxonomy is worth bookmarking for your security team, but the operational priority is clear: MCP-connected agentic AI tools are the newest category of unapproved AI tools that most AI tool inventories are missing entirely. Start there.
If you want a structured place to track what you find, download the free AI tool register template — it’s set up to capture the fields that matter for AI vendor risk assessment, including the permission scope and data access details that MCP entries need.
