TL;DR
- MCP is an open standard that connects AI agents to tools, data, and APIs through one interface.
- Each MCP server gives an agent real power to read data and act inside business systems.
- MCP leaves most security decisions, including authentication, to the teams that deploy it.
- Top risks include tool poisoning, malicious servers, excessive permissions, and data exfiltration.
- Secure MCP with a live server inventory, least privilege, strong authentication, and runtime monitoring.
What is MCP?
Model Context Protocol (MCP) is an open standard that connects AI applications to external tools, data sources, and APIs. It gives AI agents one common way to find and use those capabilities.
Anthropic introduced MCP in November 2024. Many people call it the USB-C port for AI. One cable type works across many devices, and MCP applies the same idea to AI integrations.
Before MCP, teams wrote a custom integration for every pair of model and tool. Five tools meant five separate integrations to build and maintain. MCP replaces that work with one shared protocol. Developers build an MCP server once, and any compatible AI client can use it.
How MCP works
MCP uses a client-server design with three main parts:
- MCP host: The AI application a person uses, such as a chat assistant or a code editor.
- MCP client: A component inside the host. It connects to servers and passes requests and responses back and forth.
- MCP server: A small program that exposes a system to the AI. It sits between the agent and your databases, APIs, or files.
Each server can offer three kinds of capabilities:
- Tools: Actions the model can run, such as querying a database or opening a ticket.
- Resources: Data the model can read for context, such as documents or records.
- Prompts: Reusable templates that guide how the model uses the server.
Clients and servers exchange JSON-RPC messages. Local servers run on the same machine and talk through standard input and output. Remote servers use HTTP-based connections and behave much like API endpoints.
Here is a simple flow. A user asks an assistant to summarize open support tickets. The client asks the ticketing server which tools it offers. The model picks the right tool, and the server calls the ticketing API. The results flow back to the model, which writes the summary.
Why teams adopt MCP
MCP speeds up AI projects. Teams connect agents to CRM, ticketing, code, and cloud platforms without custom glue code. Servers work across many AI models, so teams avoid lock-in to one vendor.
MCP also powers agentic workflows. Agents can update records, open pull requests, and restart services on their own. That ability makes MCP useful. It also makes MCP a serious security concern.
Why is MCP security needed?
Every MCP server hands an AI agent real access to business systems. The agent can read records, change settings, and trigger workflows. Attackers who control the agent’s input can use that same access.
The protocol leaves most security choices to the teams that deploy it. The specification treats authorization as optional. Formal authorization guidance only arrived in March 2025. Many early servers still run without any authentication.
MCP security is the set of controls that protect MCP clients, servers, and the systems they reach. It covers identity, access, supply chain, data flow, and runtime behavior.
Four traits make MCP harder to secure than a normal integration:
- Agents act on untrusted input. Emails, documents, and web pages can carry hidden instructions that steer an agent.
- Servers hold powerful credentials. One server often stores tokens for several enterprise services at once.
- Anyone can publish a server. Public registries host thousands of third-party servers with little or no vetting.
- Security tools miss agent intent. A WAF or API gateway sees each request. It does not see why an agent chose a tool.
These risks already appear in real software. In 2025, researchers found a critical flaw in MCP Inspector, a popular developer tool. The bug, CVE-2025-49596, let attackers run commands on developer machines.
The OWASP Agentic Top 10 now covers many of these threats, including tool misuse and supply chain risk.
MCP vs. traditional API integration
MCP servers usually wrap existing APIs. The security model changes because an AI agent now decides which calls to make.
| Factor | Traditional API integration | MCP-connected AI agent |
|---|---|---|
| Who decides the call | Developer code with fixed logic | An AI model that decides at runtime |
| Input trust | Structured, validated requests | Natural language open to prompt injection |
| Permissions | Scoped service accounts | Often the end user’s full access |
| Behavior | Predictable and easy to test | Changes with prompts and context |
| Capability discovery | Fixed API specifications | Tool descriptions the model reads and trusts |
| Supply chain | Vetted SDKs and libraries | Third-party servers from open registries |
| Visibility | Logged at the API gateway | Tool calls often invisible to security teams |
Many MCP attacks end at an API. Classic flaws from the OWASP API Top 10 still apply behind every MCP server. An agent can trigger Broken Object Level Authorization (BOLA) by requesting records owned by other users. It can also exploit Broken Function Level Authorization (BFLA) to reach admin-only actions.
Strong API runtime protection therefore remains a core layer of MCP defense.
Top 10 MCP security risks
These risks appear across most MCP deployments. Each one gives attackers a path from the AI layer into real systems.
- Tool poisoning: Attackers hide instructions inside a tool’s description. The client passes that text to the model, and the model follows it. The agent may then leak data or call other tools in secret.
- Indirect prompt injection: An agent reads an email, file, or web page with hidden commands. Through MCP, the agent can act on those commands inside live systems.
- Malicious and look-alike servers: Attackers publish servers that copy trusted brands or package names. Installing one runs attacker code with the user’s own permissions.
- Tool name collisions: A rogue server registers a tool with the same name as a trusted one. The agent may call the fake tool and hand it sensitive data.
- Excessive permissions: Many clients run tools with the end user’s credentials. The agent inherits every right that user holds. Those rights can outlast the user’s session.
- Weak or missing authentication: Some remote servers accept requests without authentication or over plain HTTP. Anyone who finds them can list and call their tools.
- Plaintext credentials: Local configuration files often store API tokens as plain text. Malware that reads those files gains access to every connected service.
- Consent fatigue: A malicious server floods users with harmless approval requests. Tired users click through and approve a harmful action hidden in the stream.
- Data exfiltration: Unvetted servers can send prompts, context, and records to outside services. This traffic looks like normal MCP activity and slips past standard controls. Sensitive data discovery shows which APIs and tools expose regulated data.
- Shadow MCP and visibility gaps: Developers and employees add servers without security review. Teams cannot protect servers they do not know exist. Unmanaged servers are a growing form of shadow AI. Many wrap unmanaged APIs, and forgotten servers become zombie APIs that nobody patches.
How MCP attacks unfold
These three scenarios show how the risks above turn into real incidents.
A poisoned tool reads private files
A developer installs a free note-taking MCP server. Its tool description tells the model to read a local config file first. The model obeys and passes the file to the server. The developer only sees a normal note.
A support ticket hijacks an agent
A support agent uses MCP to reach the CRM and email. An attacker submits a ticket with hidden instructions. The agent follows them and emails customer records to an outside address. Each API call looks valid on its own.
One weak server opens the wider network
Attackers compromise one server through a vulnerable dependency. They reuse its stored tokens to reach databases and cloud services. One small server becomes a path into many systems.
The second scenario is a business logic attack. Signature-based tools miss it because no single request looks malicious.
MCP security best practices
No single control stops every MCP threat. Layer these practices across the full lifecycle of each server.
Build visibility first
- Keep a live server inventory. Track every local and remote server, its tools, its owner, and the systems it reaches. AI discovery and posture management automates this inventory. Map the APIs behind each server with API discovery and posture management.
- Approve servers before use. Allow servers only from verified sources. Check package hashes before each install. Vet the APIs behind each server with proven API testing capabilities.
Control identity and access
- Require strong authentication. Use OAuth 2.1 with short-lived, scoped tokens on every remote server.
- Apply least privilege. Grant each server only the access its task needs. Split read tools from write tools.
- Protect secrets. Store tokens in a secrets manager. Remove plaintext credentials from configuration files.
Contain and harden servers
- Sandbox every server. Run servers in isolated containers with limited file, network, and system access.
- Encrypt all traffic. Enforce TLS on every client-server connection and block plain HTTP.
- Stay current. Update servers to the latest protocol version and security fixes.
Watch runtime behavior
- Inspect tool descriptions and outputs. Scan them for hidden instructions before the model reads them.
- Monitor every tool call. Log who called which tool with what data. Flag unusual sequences.
- Keep a human in the loop. Require clear approval for deletes, payments, and bulk data exports. Payment tools need extra care, so review these 7 API security requirements for payment transactions.
- Test like an attacker. Use AI red-teaming to find poisoning, injection, and access flaws before release. Extend tests to each tool’s APIs with API red-teaming. Download the API red-teaming solution brief for details.
Runtime monitoring matters most because agent behavior changes after deployment. AI runtime protection catches abuse that pre-release testing cannot predict.
Plan for incidents and audits
- Prepare an incident plan. Define how to revoke tokens and isolate a server fast. Incident response tooling speeds up investigation.
- Map controls to regulations. Log tool calls and data access for audits. Governance and compliance reporting turns these logs into evidence.
How AppSentinels secures MCP
AppSentinels delivers API security, agentic AI security, and MCP security in one platform. Its Business Logic Graph maps how agents, tools, and APIs interact. This map shows what normal behavior looks like for each workflow.
- Discovery: Finds MCP servers, their tools, and the APIs behind them, including shadow servers.
- Posture: Flags weak authentication, broad permissions, and exposed tools.
- Runtime protection: Watches agent tool calls in real time. Blocks injection, abuse, and data exfiltration.
- Continuous red-teaming: Tests MCP servers against poisoning, injection, and business logic attacks.
Enterprises in banking, healthcare, retail, and media use AppSentinels to protect critical API ecosystems. A SASE vendor secures its own APIs with it. A technology enterprise tested business logic across 3,500 APIs in days.
Comparing vendors? Read our lists of the top 10 MCP security companies and the best agentic AI security platforms. For API vendors, see the top 10 API security companies. Then score each option with the API security buyer’s checklist.
Conclusion
MCP makes AI agents far more useful. It also turns every connected server into a path to your data and systems. The protocol leaves most protection to you.
Start with a full inventory of servers and tools. Lock down identity, isolate servers, and watch every tool call at runtime. Teams that secure MCP now can scale agentic AI with confidence.
Book a demo to see how AppSentinels finds, tests, and protects every MCP server your agents use.
Frequently Asked Questions
AppSentinels discovers MCP servers by analyzing traffic between AI agents, tools, and APIs. It builds a live inventory of servers, the tools they expose, and the systems they reach. This inventory includes shadow servers that teams added without security review.
Yes. AppSentinels inspects MCP tool calls and responses at runtime. It flags hidden instructions, unusual tool sequences, and attempts to move sensitive data. Security teams can then block the activity before it reaches business systems.
A WAF or API gateway checks each request against fixed rules. AppSentinels adds context across many calls. Its Business Logic Graph tracks agent identity, tool order, and data flow. This context exposes misuse that looks valid one request at a time.
Yes. AppSentinels runs continuous red-teaming against MCP servers and the APIs behind them. It tests for tool poisoning, injection, broken access control, and business logic abuse. Teams fix these flaws before attackers find them.
Yes. Most MCP tools call APIs behind the scenes, so AppSentinels secures that layer too. It discovers those APIs, tests them for flaws like BOLA and BFLA, and protects them at runtime. Teams secure agents and APIs from one platform.