Model Context Protocol servers are spreading through enterprise environments for the simple reason that they make AI useful. They give agents the reach needed to move beyond chat and act inside the systems where work happens. A developer connects an agent to GitHub, Slack, a database or a cloud API, and suddenly the model can retrieve context, trigger workflows, inspect repositories, query records, and operate across the tools that run the business.
Security teams need to recognize what changed. AI adoption no longer looks like employees experimenting with a chatbot in a browser. It now looks like developers wiring autonomous systems into the enterprise control plane.
MCP is an open standard that defines how AI models interact with external tools, APIs and data sources through a standardized server interface. The definition sounds orderly, but the deployment reality is anything but. Each MCP server becomes an integration layer running inside your environment, accepting instructions from an AI model and acting with whatever permissions the server received at deployment time.
What MCP Is and Why Security Teams Should Care
MCP was developed by Anthropic and has since been adopted as an open standard across the major AI framework ecosystem. LangChain, AutoGen and cloud provider agent toolkits all support it. The architecture has three tiers: an MCP client (the AI model or agent issuing instructions), an MCP server (the integration layer that translates those instructions into real API calls), and the underlying resource being accessed, such as a GitHub repository, an S3 bucket, a Slack workspace or a Postgres database.
The security-relevant properties of this architecture are specific:
- MCP servers run as processes, often with elevated credentials provisioned during development using personal access tokens or broad service account permissions.
- They accept tool-call instructions from any compliant MCP client. The MCP specification doesn’t mandate authentication between the client and server at the transport layer. A server listening on a local or container port is by default an open interface.
- Developers are deploying them without a security review. MCP servers appear in Docker containers, cloud VMs and developer laptops. They are provisioned as a natural part of an AI agent build, not as an infrastructure change that triggers a security review.
When security vendors are shipping detection products for a new attack surface, that surface is already being exploited in the wild. Your developers are almost certainly ahead of your security policy on this one.
The Attack Surface Anatomy of an MCP Server
Prompt Injection via MCP Tool Results
When an AI agent calls an MCP server tool, fetching a webpage, reading a file or querying a database, the returned content is added to the model's context as trusted input. The model has no native mechanism to distinguish legitimate tool output from injected instructions embedded within it. This creates a direct vector for poisoning the RAG (Retrieval-Augmented Generation) pipeline.
An attacker who can influence the output of any tool called by the MCP server can inject instructions into the model's reasoning chain. For example, an attacker can insert an instruction block into a public README on a GitHub MCP server with access to public repositories. The agent fetches the file as part of a normal workflow; the model reads the instructions as context; it executes them.
Overprivileged MCP Server Credentials
MCP servers need credentials to access underlying resources. In practice, developers provision those credentials at development time, and the patterns are consistently bad. Personal access tokens with organization-wide read/write scope sometimes end up in MCP server configuration files, environment variables passed to Docker containers, or hard-coded in server source code.
The nonhuman identity problem has driven cloud breaches for years, now reproduced in an infrastructure layer that most organizations haven't begun to inventory. The credential stored in an MCP server's environment is as valuable to an attacker as an exposed AWS key in any other context and significantly less likely to have been rotated or scoped appropriately.
Lateral Movement via Chained MCP Tool Calls
The most architecturally novel risk is lateral movement through chained tool calls. An AI agent with access to multiple MCP servers can be manipulated to execute a sequence of calls that individually appear authorized but collectively cross trust and classification boundaries in ways no single call would trigger. Because this traffic originates from a trusted container, traditional network segmentation rules often fail to catch the anomalous behavior.
Consider a realistic enterprise agent: it has a GitHub MCP server for reading source code, an AWS MCP server for describing infrastructure, and a Slack MCP server for internal communication. Each tool call, viewed in isolation, is individually authorized. This can be chained to read source, enumerate infrastructure, and exfiltrate to external Slack channels. This attack executes through legitimate API calls made by a trusted process.
Building an MCP Security Program from Zero
Most organizations are starting from an empty inventory. The good news is that the framework for addressing this mirrors what worked for shadow API governance a decade ago, with some agentic-specific additions. The three functional areas are discovery, policy and runtime detection. The key is to build the registry, define the policy, and make compliance the path of least resistance. Organizations also need to instrument the runtime so security teams can detect where MCP servers drift from policy, operate without approval, or expose tools and data in ways the registry never captured.
Step 1 — Discovery: Know What's Running
- Scan cloud environments for MCP server process signatures and known framework ports
- Query your software inventory for MCP-related package dependencies
- Ask your developer platform team for AI agent workflows in production or active development
- Map every MCP server to the credentials it holds and the resources it can reach
Step 2 — Policy: Define What's Allowed
- Define approved servers, approved tools per server, and data classification limits
- Require scoped service identities for all MCP server credentials and no personal access tokens in production
- Mandate structured logging on all registered MCP servers
Step 3 — Runtime Detection: Catch What Slips Through
- Monitor for unexpected outbound connections from MCP server processes
- Alert on tool-call chains that cross-data classification boundaries
- Flag MCP server credential usage outside normal hours or geographic patterns
Why Cloud Security Is the Foundation
MCP servers are not abstract. They run as compute workloads inside the same cloud environments your security team already manages. They assume identities such as service accounts, access keys and IAM roles drawn from the same identity fabric your cloud security already covers.
Organizations with mature cloud security foundations are substantially better positioned to extend those controls to MCP than those starting from zero. Least-privilege identity governance, container workload visibility and cloud-native behavioral monitoring are foundational to security.
The convergence of AI and cloud infrastructure was always going to create new security obligations. MCP is the first of those obligations to arrive at scale. The question isn’t whether your organization will have an MCP attack surface. The question is whether your security team will have visibility into it.
This is where Palo Alto Networks bridges the gap. Cortex Cloud API Security and AI-SPM automate the exact framework outlined above. We handle the discovery phase by automatically mapping your AI inventory across your cloud infrastructure. We operationalize risk assessment by assessing the risk posture of the models and APIs in use. And we deliver cloud runtime security by continuously monitoring for anomalous tool-call chains and data exfiltration.
Stop flying blind with unmanaged AI integrations. Get a demo of Cortex Cloud API Security and AI-SPM today.