MCP server security covers two connected problems: securing the servers that give AI agents their capabilities, and governing the configuration artifacts that wire those capabilities in. An MCP server is not middleware in the traditional sense. It is the agent's hands: the thing that turns generated text into file reads, ticket updates, database queries, and outbound requests. Securing the agent while ignoring its MCP servers governs what the agent intends to do while leaving what it can actually do ungoverned.
What an MCP server is, in security terms
The Model Context Protocol connects agents to tools through servers that run in one of two modes, and the modes have different security shapes. A remote MCP server is a network service: the agent reaches it over a transport, an enterprise deployment requires it to authenticate the caller, and the server acts on downstream systems with credentials it holds. A local MCP server is a process the agent launches on its own host, exchanging messages over standard input and output, with whatever access the launching user has. Both extend the agent's reach. Neither is governed by anything the model was trained to refuse.
Securing remote MCP servers
Five disciplines apply, and they are the disciplines of any service that acts on behalf of callers. Authentication first: the protocol does not require authorization, so demand it. An enterprise remote server exposing consequential tools uses the specification's OAuth-based authorization framework and rejects unauthenticated access, because an unauthenticated MCP server is an open proxy into whatever it can touch. Credential handling second: the server holds credentials for the systems it acts on, which makes it a confused-deputy risk by construction; downstream credentials stay scoped to the server's declared function and terminate at the server; the specification itself forbids token passthrough, so a server calling a downstream API uses a token issued for that API, never the caller's. Transport third, encrypted and verified. Tool scope fourth: each tool the server exposes carries its own least-privilege manifest, with scope, data classes, and rate limits attached to the tool rather than stated in prompt text where the model can be argued out of them; this is an emerging practice rather than an established standard, which is a reason to demand it rather than wait for it. Reachability fifth: an MCP server lives inside the project boundary it serves, because a server reachable from two projects connects them regardless of how the network diagram draws the boundary, and its tool calls cross the session layer where they can be inspected, policied, and logged. One drift risk is server-side: pinning the client configuration does not pin a remote server's behavior, since tool descriptions, schemas, and methods behind a stable URL can change after review. Fingerprint the approved tool catalog and compare at connection time; catalog drift is configuration drift that happens where your pins cannot see it.
Securing local MCP servers
A local MCP server communicates with the agent over standard input and output rather than a network transport, but the server process itself can still make outbound network calls, so endpoint egress controls remain part of its security boundary. For the agent-to-server exchange, the enforcement point moves to match the capability. Session-layer inspection does not apply to a process pipe; what applies is everything that governs local software. The server binary or package is pinned by version and verified by hash at install, so what runs is what was reviewed. Process-level visibility on the endpoint records that the server is running and which agent launched it. The host's egress posture bounds what the server's own code can reach, exactly as it bounds any process. And the configuration that authorizes the server in the first place, the entry in the agent's server list, is a governed artifact, which is where the second half of this page takes over.
The attacks are already specific to this surface
Three patterns recur. A malicious server is arbitrary code execution packaged as a tool, installed with the agent's trust and the user's access. A poisoned tool description is subtler: descriptions are text the model reads, so a description can carry instructions, and an agent that loads the tool has been prompt-injected before the first call. And the rug pull: a server that was clean at review changes after approval, which is why pinning and drift detection are security controls rather than hygiene. None of the three is hypothetical. OWASP maintains a dedicated Agentic Skills Top 10 for this surface, and its primary case study is the 2026 ClawHavoc campaign, which seeded a public agent marketplace with hundreds of credential-stealing skills that spread through enterprise deployments on the trust the agents had already been granted; published counts vary with scope and date, from Koi Security's initial 341, later revised to 824, to the 1,184 in OWASP's case study. The campaign is evidence for the skill and configuration supply chain rather than for remote MCP authentication, which is why this page treats both surfaces.
The configuration is the supply chain
MCP servers arrive through configuration, and so does everything else that shapes agent behavior: skills, instruction files, rules files, prompt templates, and tool manifests. These artifacts shape what the agent attempts and which capabilities it knows how to invoke. That makes them part of the software supply chain whether or not anyone treats them that way, and a clean model wrapped in poisoned scaffolding produces the same outcome as a poisoned model in clean scaffolding.
The governance is the governance you already apply to code. Version control everything an agent reads as instruction or capability, so there is a history of what changed and who changed it. New skills and MCP servers enter through review and approval, the way a new dependency does, not through a marketplace click on a developer workstation. Approved components are pinned by version and verified by hash or signature at install. And the deployed state is checked against the approved state continuously, so an instruction file or server list that changed outside the process raises an alert instead of quietly redefining an agent.
Instruction files in repositories are an attack path
There is one consequence worth paying special attention to. A pull request that edits an instruction file changes agent behavior as surely as a pull request that edits source, and it should be reviewed with the same care, because it steers the same access. Repository-resident configuration is an inexpensive and often under-reviewed place to alter agent behavior.
Configuration decides what the agent is; the declaration decides what it may do
The two governance layers are deliberately separate. Configuration governance controls the artifacts that define the agent, MCP servers included. Declared authorization, enforced outside the agent's write control, decides what any version of that agent is permitted to reach and do. The point of the separation is that enforcement holds even when one of them is wrong: a malicious server that slipped review still cannot reach outside the project boundary, and its tool calls on governed paths still cross an inspection point it does not control.
Where the control plane fits
Ensage AI governs this surface from both directions: session-layer inspection and tool-call policy for network MCP traffic inside the enclave, configuration management that reconciles deployed state against approved and restores it on drift, and enclave reachability so that a poisoned server's reach is bounded even before it is detected.
