The Model Context Protocol gives AI agents a standard way to reach real tools and data, which makes MCP security everyone’s problem, including the people nobody told.
Before MCP, connecting an AI assistant to a company’s ticketing system or code repository usually meant weeks of integration work and at least one tense meeting. The Model Context Protocol has turned much of that into a configuration step, which developers love and security teams tend to find out about later.
As a security researcher at CredShields, I think MCP security deserves far more attention than it gets. Every MCP server a team installs hands an AI agent a new set of actions, often backed by a real credential, and those actions can slip past the review a new API would get. Nobody plans for this. It is simply very easy to add one more server on a Friday afternoon.
What MCP Actually Does
MCP is an open protocol, introduced by Anthropic in late 2024, that standardises how AI applications connect to external tools and data. An MCP server exposes capabilities, such as querying a database or creating a ticket. An AI application connects to that server as a client, and the model decides when to call each tool based on the conversation and its instructions.
Think of it as a universal adapter for AI agents. Universal adapters are wonderful right up until you check what got plugged in.
The protocol solved a real integration problem. It also placed one layer between AI agents and many of the systems they touch, and that layer is where the new risks sit.
How MCP Changes the AI Attack Surface
MCP security risks mostly come down to what a server can do and who gets to influence the model that calls it. Five patterns stand out, and none of them call for a particularly clever attacker.
Servers Can Change After Approval
Many MCP clients ask a user to approve a server or tool once. If the server’s tool definitions change later, the agent can keep calling a tool that now behaves differently from the one that was approved. It is the software version of signing a contract and later discovering page two was swapped.
Tokens Carry More Scope Than the Task Needs
An MCP server usually holds a token for the service it connects to. If that token has broad scopes, any instruction that reaches the model can, in principle, use them. A server built to read one repository might hold a token that can write to every repository in the organisation, because someone picked the scope that made the error message go away.
Retrieved Content Can Steer the Agent
When an agent reads an email or a shared document through MCP, that content enters the model’s context. Instructions planted inside it can push the agent toward other tools on the same connection. Your agent reads an attacker’s email with exactly the same diligence it gives yours.
Local Servers Run With the Developer’s Privileges
Many MCP servers run on a developer’s own machine. They inherit that user’s file access and network position, so a malicious community server installed from a package registry reaches as far as any other software the developer runs. Installing one takes a single command, and very few people read the source first.
Why Existing Security Reviews Miss MCP
Most application security processes were designed around code a team writes and ships. MCP servers often arrive as third-party packages or a single line in a config file, and the risk comes from how they combine with a model that follows natural-language instructions. Few review checklists were written with the possibility that the software might be persuaded by an email.
At CredShields, our view is that good MCP security starts with treating every MCP server like any other API that holds credentials and accepts untrusted input. It is an unglamorous framing, and it puts MCP servers back inside the testing and access reviews teams already run.
An MCP Security Checklist for Security Teams
None of this needs a new team or a fresh budget line. Each step below maps to a risk described above.
- Inventory every MCP server in use, including the ones developers installed locally and forgot to mention.
- Review each server’s token scopes and cut them to what the tool needs.
- Pin server versions and re-review whenever tool definitions change.
- Treat retrieved content as untrusted input and test how the agent responds to planted instructions.
- Log every tool call with the credential it used, so you can reconstruct what an agent did.
Frequently Asked Questions About MCP Security
A few common questions about MCP security, answered briefly.
What is MCP in AI?
The Model Context Protocol is an open standard for connecting AI applications to external tools and data through MCP servers.
Is MCP secure?
MCP is a connection standard, so the security of a deployment depends mostly on the servers you install and the permissions their tokens carry.
How do you test an MCP server?
Test it like any API that holds credentials. Check its token scopes, then plant instructions in the content it returns and see whether the agent can be steered into tools it should never use.
If your team is connecting AI agents to internal tools, or suspects someone already has, CredShields One lets you find security issues across the applications those agents reach, with AI doing the work of finding them. For anything that needs a deeper manual test, the CredShields penetration testing team can scope an engagement with you, and this sample report shows what you get at the end.
