AI agents are moving from experiments into production workflows, and the Model Context Protocol (MCP) is becoming the connective layer that enables those agents to access enterprise data, applications, APIs, repositories, and automation tools. That makes MCP powerful, but also security-critical. As organizations adopt agentic AI, they need to understand not only how MCP improves connectivity but also how it creates new visibility, governance, and attack-surface challenges.
What Is MCP and Why Does It Matter for Enterprise AI?
The Model Context Protocol is an open standard that gives AI systems a consistent way to discover and interact with external tools, data sources, and business systems. A concise way to define it is this: MCP is a standardized control plane for connecting AI agents to enterprise context and actions.
That matters because enterprise AI only becomes useful when it can reach the systems where work happens. A support agent may need to query a ticketing platform. A coding assistant may need to inspect a source-code repository. A finance assistant may need to retrieve database records. An operations agent may need to invoke an internal API or start a workflow.
MCP functions as a one-to-many abstraction layer. Instead of building separate integrations for each AI application and system, organizations can expose tools, resources, and prompts through MCP servers. AI clients can then call APIs, query databases, read files, retrieve context, and trigger workflows through a shared protocol.
Adoption has moved quickly. Anthropic introduced MCP in November 2024 as an open standard for connecting AI assistants to systems where data lives. By 2025, OpenAI, Microsoft, and Google had announced or documented MCP support across products and services.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation-directed fund co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, AWS, Cloudflare, Bloomberg, and others. MCP is now widely treated as the emerging default standard for agentic AI connectivity.
How MCP Architecture Creates Security Exposure
MCP uses a client-server architecture. An AI application acts as the host and runs one or more MCP clients. Those clients connect to MCP servers, which expose tools, resources, and prompts. A server might provide access to a Git repository, a database, a SaaS application, a cloud account, or an internal API.
This resembles a traditional API model, but MCP changes the interaction pattern. MCP servers do not simply return static data. They describe available tools to AI systems, influence agent context, and execute actions on behalf of connected clients. In agentic workflows, the model may decide when and how to invoke those tools based on instructions and context.
That creates attack paths that differ from traditional API risk. A user gives an instruction, an AI agent interprets it, an MCP client selects a tool, an MCP server executes an action, and downstream systems respond. Each handoff can introduce a policy, validation, or visibility gap.
MCP servers are also often privileged intermediaries. A single server may sit between an AI agent and source-code managers, databases, cloud services, internal APIs, file systems, or observability tools. If that server is over-permissioned or poorly secured, it becomes a high-value target.
The protocol was designed for flexibility, and that flexibility has helped adoption. But it also means many controls are left to implementers. Authentication, authorization, input validation, tool approval, session handling, logging, and policy enforcement are not uniformly enforced at the protocol level. Two MCP servers performing similar functions may therefore have completely different security postures.
Core MCP Security Risks Organizations Face Today
MCP security risk spans identity, authorization, prompt integrity, session handling, context management, and software supply chain exposure. Four areas deserve immediate attention.
The first is access control. MCPs do not require authentication or role-based access control at the protocol level. Strong deployments can add those controls, but early implementations may rely on local trust assumptions, shared credentials, or overly permissive access to tools. If an MCP server can read repositories, query databases, or call internal APIs, weak access control at the MCP layer can become weak access control across every connected system.
The second is tool poisoning and prompt injection. In a tool poisoning attack, a malicious or compromised MCP server embeds hidden instructions in tool descriptions, metadata, prompts, or outputs. An AI agent may treat those instructions as legitimate context and perform unintended actions, such as leaking data, ignoring security instructions, or passing secrets to another tool. Prompt injection creates a related risk when agents process untrusted content from tickets, documents, repositories, webpages, or tool outputs.
The third is token and session weakness. Many MCP deployments depend on bearer tokens, delegated permissions, OAuth flows, or token passthrough patterns. Long-lived tokens, broad scopes, poor revocation, and weak session lifecycle management can let attackers move from the MCP layer into downstream systems. MCP also creates opportunities for confused deputy attacks, where a trusted component is tricked into using its authority in a way the user did not intend.
The fourth is insecure context serialization. MCP commonly exchanges structured objects over JSON-RPC. Without strict schema enforcement and isolation, malformed payloads, unsafe deserialization, path traversal, injection, and command execution risks can reach privileged tools or execution environments.
The MCP Server Discovery and Inventory Problem
MCP servers are becoming a new form of shadow IT. They are easy for developers to deploy, frequently built with open-source frameworks, and may run on workstations, in containers, in CI/CD systems, or in cloud environments. A developer can quickly connect an AI assistant to files, repositories, credentials, logs, databases, or internal APIs without creating a formal security review process.
That creates a visibility problem. Without continuous MCP server discovery, security teams cannot answer basic questions such as: Which servers exist? Where are they running? Who owns them? Which tools do they expose? Which agents use them? What data can they access? Are they authenticated? Are they sanctioned? Have permissions changed?
A one-time audit will not be enough. MCP environments change as developers test frameworks, add tools, update credentials, or expand permissions. Security teams need a live inventory that captures location, owner, tool exposure, authentication status, access scope, runtime behavior, and sanctioning status across endpoints and cloud environments.
This should feel familiar to teams that have dealt with shadow APIs: unknown endpoints, unclear ownership, undocumented data exposure, and inconsistent controls. MCP servers create a similar challenge, but with an added complication. They do not only expose data to applications. They expose capabilities to AI agents that can reason, choose tools, and initiate actions.
Real-World MCP Security Incidents That Illustrate the Risk
MCP is still relatively new, but documented research already shows why security teams need controls before broad deployment.
Researchers have demonstrated tool parameter injection attacks against open-source MCP agents, showing how unsanitized inputs can expose sensitive server data or influence tool execution. These cases highlight two common failure modes: inputs are trusted too early, and logging is insufficient to reconstruct what happened after the fact.
GitHub-related MCP scenarios have also shown the danger of excessive repository permissions. In one class of attacks, an MCP-connected tool with broad repository access could read content from a private repository and write it into a public repository without the user fully understanding the action path. The issue is the blurred boundary among user intent, tool permissions, and downstream API actions.
The Anthropic MCP Inspector vulnerability offered another warning. MCP Inspector is a developer tool for testing and debugging MCP servers. In 2025, researchers reported CVE-2025-49596, a critical remote code execution vulnerability involving browser-based attacks against local developer environments. Reports described how a malicious website could trigger commands on a developer machine under certain conditions, prompting a patch in version 0.14.1. The lesson for enterprises is direct: even vendor-provided MCP tooling requires security review, version management, and controlled use.
MCP Security Best Practices for Enterprise Deployment
Organizations should treat MCP as production connectivity infrastructure, not as a developer convenience. The first requirement is authentication and authorization for every MCP interaction. Unauthenticated MCP servers should not have access to sensitive tools, data, or workflows. Where OAuth is used, follow OAuth 2.1 guidance, enforce explicit per-client consent, restrict scopes, bind tokens to intended audiences, and avoid unnecessary token passthrough.
Least privilege should apply at every layer: user, agent, client, server, tool, and downstream system. A server built to read documentation should not have write access to source-code repositories. A server used for analytics should not be able to modify cloud infrastructure. Tool permissions should be reviewed whenever servers are updated or new capabilities are added.
Sandbox MCP servers to reduce the impact of path traversal, command injection, arbitrary code execution, privilege escalation, and resource exhaustion. File-system limits, container isolation, runtime constraints, and network egress controls can all reduce blast radius.
Strict JSON-RPC schema validation should be enforced before requests reach execution environments. Tool parameters should be sanitized, outputs should be treated as untrusted, and deserialization should happen only in controlled contexts.
Comprehensive audit logging is also essential. Security teams need a traceable sequence of activity across sessions, including who initiated the request, which agent and client were involved, which server received the call, which tool was invoked, what authorization decision was made, what downstream system was touched, and whether any RBAC violation occurred. Useful logs should include relevant HTTP header data, authorization events, tool execution records, session identifiers, and abnormal outcomes.
Finally, vet third-party MCP servers before production use. Community servers should be evaluated like third-party packages, container images, or open-source dependencies. Review source code where possible, scan for malicious behavior, understand required permissions, validate authentication behavior, and test in a non-production environment before connecting them to sensitive systems.
Building an MCP Governance Program from the Ground Up
MCP security cannot depend on individual developer discipline. Enterprises need governance that makes secure adoption the default.
Start with discovery. Security teams need a full inventory of MCP servers across endpoints, developer workstations, cloud instances, containers, CI/CD systems, and production infrastructure. Once discovered, classify each server by risk based on data sensitivity, exposed tools, authentication posture, access scope, external exposure, business criticality, and sanctioning status.
Controls should then be applied according to risk. Low-risk experimental servers may need basic guardrails and expiration policies. High-risk servers may require strong authentication, strict authorization, sandboxing, approval workflows, continuous monitoring, and formal change management.
Continuous monitoring keeps the program current. Monitoring should detect new MCP servers in near real time, distinguish sanctioned from unsanctioned deployments, identify changes in tool exposure, and flag behavior that suggests misuse or compromise.
MCP governance should also connect to existing enterprise security programs. IAM teams need to understand how users, agents, clients, and servers are authorized. EDR teams should see MCP tooling on endpoints. Cloud security teams should track MCP servers in cloud environments. API security teams should monitor the downstream APIs that agents call through MCP. SIEM and incident response teams need enough telemetry to reconstruct agent-driven activity.
This is where MCP security connects directly to API security. AI agents create business impact by calling tools, APIs, databases, and workflows. MCP sits in the middle of that action path. Securing it requires visibility into both the MCP layer and the APIs and systems it reaches.
MCP Security Starts with Visibility
Every major technology shift creates new infrastructure that security teams eventually have to govern. For cloud adoption, it was unmanaged cloud accounts. For APIs, it was shadow APIs. For AI agents, MCP servers are rapidly becoming the next visibility challenge.
The risk is not MCP itself. The protocol solves a real problem by giving AI systems a standardized way to interact with enterprise applications, data sources, and workflows. The challenge is that organizations are deploying MCP servers much faster than they are establishing controls around them.
Security teams cannot protect what they cannot see. Before they can evaluate authentication models, review permissions, or detect tool-poisoning attempts, they need to know which MCP servers exist, which systems those servers can access, and which AI agents are using them.
As AI agents become embedded in business processes, MCP servers will increasingly resemble APIs: critical connectivity infrastructure that requires continuous discovery, monitoring, and governance. Organizations that establish visibility now will be in a far stronger position than those trying to secure an MCP ecosystem they never knew existed. Get a Surface Assessment to Find Every MCP Server in Your AI Infrastructure.
Frequently Asked Questions about MCP Security
What makes MCP security different from standard API security?
Traditional API security focuses on predictable client-to-server interactions. MCP adds an AI decision layer, dynamic tool discovery, delegated authority, and context that can influence agent behavior. That introduces risks such as tool poisoning, prompt injection, confused deputy attacks, and unintended agent actions.
How do I find all the MCP servers running in my organization?
Use continuous discovery across endpoints, cloud environments, developer workstations, containers, CI/CD systems, and production infrastructure. The inventory should capture location, owner, exposed tools, authentication status, connected systems, access scope, and sanctioning status.
What is tool poisoning in MCP, and how does it work?
Tool poisoning occurs when a malicious or compromised MCP server hides instructions in tool descriptions, metadata, prompts, or outputs. An AI agent may treat those instructions as legitimate context and perform unintended actions.
Does MCP require authentication by default?
No. MCP does not mandate authentication or RBAC at the protocol level. Organizations need to implement identity, authorization, consent, token, and policy controls for any MCP server connected to sensitive data or actions.
What is the confused deputy attack in MCP, and how can I prevent it?
A confused deputy attack happens when a trusted MCP component uses its authority in a way the user did not intend. Prevent it with explicit consent, narrow OAuth scopes, audience-bound tokens, per-tool authorization checks, and policy decisions that consider the user, agent, client, server, tool, and requested action.
How should I evaluate a third-party MCP server before using it in production?
Evaluate it like a third-party package, container image, or open-source dependency. Review source code when possible, scan for malicious code, understand required permissions, validate authentication behavior, test in a non-production environment, and monitor behavior before connecting it to sensitive systems.