In the eighteen months since Model Context Protocol moved from spec to widespread deployment, MCP servers have quietly become one of the most exposed components in enterprise AI environments. They sit between an agent and the tools it can call, they hold credentials to downstream systems, and they run code paths that most security teams have never reviewed. MCP servers now turn up in nearly every enterprise AI environment, and almost none of them are being treated as production infrastructure.
That gap is the issue. An MCP server is not a developer convenience. It is an authenticated, network-accessible service that grants a language model the ability to take action against the systems it connects to. The threat model that applies to a bastion host or an internal API gateway applies here, and very few teams are operating it that way.
What an MCP Server Actually Is
A Model Context Protocol server exposes a set of tools, resources, and prompts to an LLM client. The client invokes those capabilities through structured calls, and the server executes them against whatever backend it integrates with: a database, a SaaS API, an internal service, the file system. The model decides what to call and when. The server decides what is allowed.
The structural risk is straightforward. The model is producing tool invocations from inputs that include attacker-controllable content. Email bodies, support tickets, web pages, document attachments, anything the model reads can shape the calls it makes. If the MCP server does not enforce its own authorization layer, the agent's effective privileges are whatever the server was configured with, regardless of what the user requesting the action is allowed to do.
Where Real Deployments Are Failing
Four failure patterns come up again and again in real deployments.
Overscoped credentials. The MCP server is configured with a service account or API token that has far more access than any single agent operation requires. A read-only calendar tool ends up sharing the same token as a delete-event tool, and the model can call either. We have seen MCP servers configured with admin-level tokens because the team setting them up did not want to debug permission errors during testing.
No per-tool authorization. The server treats authentication as a binary. Once the client is connected, every tool is callable. There is no concept of which user is on the other end of the agent, what they are allowed to do downstream, or whether this particular invocation should be permitted in this context.
Unsanitized resource fetches. Several MCP servers expose a fetch URL or read file capability with no allowlist. The model can be coaxed by upstream content into pulling internal endpoints, accessing local files, or hitting cloud metadata services. This is server-side request forgery dressed up as a feature, and it is showing up frequently in the wild.
No audit trail anyone would trust. When we ask for the log that would tell us which tool was called, with what arguments, on whose behalf, on a specific date, the answer is usually that the logs do not exist or do not contain the arguments. The agent transcript may exist somewhere, but the server-side record of what was actually executed against the backend is absent.
A Working Threat Model
Treat an MCP server as a confused-deputy risk by default. The model is the deputy. It is acting on behalf of a user, but its instructions can be influenced by content that user did not write. The server is responsible for not letting that confusion become unauthorized action.
The mental model that holds up in practice is the one used for OAuth-protected APIs. Every tool call should carry the identity of the actual end user, not the service account the server runs under. Authorization decisions on the backend should be made against that identity. The MCP server's job is not to authorize, it is to faithfully propagate identity and let the downstream system decide.
This requires a token exchange pattern. The user authenticates to the agent platform. The platform mints a short-lived, scoped token tied to that user's identity. The MCP server uses that token, not its own credential, to call downstream services. When auditors ask who took an action, the answer is a person, not a service account.
"We are watching teams roll MCP servers into production with the operational rigor of a personal scripting project, but with the privileges of a critical integration. That gap will produce incidents this year."
What to Build Before Production
Start with an inventory. Most organizations cannot list their MCP servers. They are spun up by individual engineering teams, run in container workloads, and registered with whichever agent platform the team is using. You cannot secure what you cannot enumerate. The first step is finding them.
Document each server. For each one, capture what tools it exposes, what credentials it holds, what backend systems it can reach, and whether per-user identity is being propagated. Most teams discover during this exercise that one or two of their MCP servers are running with credentials that should never have been issued to a non-interactive process.
Constrain inputs. Add per-tool allowlists for any operation that interacts with external content. URL fetchers, file readers, database query tools, anything that takes an argument from the model needs explicit constraints on what arguments are valid. Defense in depth here is cheap, and the alternative is a class of vulnerability that prompt engineering alone will not close.
Instrument tool invocations. Log every tool call with arguments, the identity on whose behalf it ran, and the result. Forward those logs to your SIEM. If your incident response team cannot answer the question of what an agent did from production data, you have an audit problem and a detection problem at the same time.
Treat MCP server changes as production changes. Code review, change management, security review for new tools, and a clear pipeline for deprecating tools that are no longer needed. The pace of MCP adoption is making it easy to add capability and hard to retire it. That will catch up with most organizations within a year.
The Bottom Line
The MCP ecosystem is moving faster than the governance around it. The protocol is sound, the deployment patterns are not. The organizations that come out of the next two years without a serious agent-related incident will be the ones that recognized early that an MCP server is production infrastructure and treated it accordingly. The work is not glamorous, and most of it is the same work we have always done for service accounts, audit logging, and least privilege. The novelty is the speed at which the surface is expanding.