Large language models are only as useful as the context and actions they can access. Vendors have shipped many bespoke integrations: this plugin talks to Slack, that one hits your database. The Model Context Protocol (MCP) is an open standard for how assistants discover tools, read resources (files, tickets, docs), and call procedures in a consistent way. If you use an AI-powered editor or agent framework in 2026, you will almost certainly touch MCP-shaped configuration.
From a security perspective, MCP is not “just another API.” It is a trust boundary between your model, your developer machine, and whatever servers and commands you wire in. This primer explains the idea in one sitting and lists the mistakes that actually burn teams.
TL;DR
- MCP standardizes how assistants list tools, fetch context, and invoke capabilities hosted by MCP servers
- Every MCP server is code you are trusting with filesystem, network, or cloud access—review it like a dependency
- Secrets belong in vaults and env injection, not in committed JSON configs next to your dotfiles
- Least privilege: scope tokens, read-only modes, and separate profiles for experiments versus production repos
- Combine with EDR and normal SDLC controls; MCP does not replace code review or supply-chain hygiene
The Mental Model
Think of an MCP host (the IDE or agent runtime) as a broker. It connects to one or more MCP servers that advertise tools (functions the model may call) and resources (data sources the model may read). The host enforces transport (often stdio for local servers or TCP with TLS for remote), passes user consent prompts where implemented, and feeds results back to the model.
That architecture is powerful because it composes: the same server can be reused across products that speak MCP. It also means a malicious or compromised server can exfiltrate everything the host exposes to it—often far more than a single REST endpoint would have allowed in older integrations.
Why Security Teams Suddenly Care
Traditional developer risk focused on npm packages and pasted Stack Overflow. Now a salesperson can install a “helpful” MCP bundle that reads private repositories, posts to internal APIs, or shells out to local binaries. The attack surface looks more like OAuth consent for robots: powerful, easy to misconfigure, and easy to copy from a blog post without reading the permissions block.
Practical Hardening Checklist
- Inventory servers the way you inventory browser extensions: who installed what, from which publisher, on which machines.
- Prefer local servers with explicit paths over fetching opaque binaries on first run unless you have checksum verification.
- Remote MCP over the public internet should use strong TLS, authentication, and ideally mutual TLS or SSO where available—not a shared static bearer token in a gist.
- Separate “research” and “production” identities so a model-triggered tool cannot accidentally touch prod cloud roles from the same profile you use for experiments.
- Log and alert on unusual tool call patterns if your platform exposes them; treat spikes like you treat abnormal Git activity.
Relation to “Vibe Coding” Risk
MCP does not create malicious intent in models, but it amplifies reach: more tools reachable from the same chat session means more blast radius when someone approves the wrong action or when generated code chains into a shell command. If your team is already thinking about EDR and script control for AI-assisted development, add MCP server governance to the same conversation.
Closing Thought
Treat MCP as privileged automation, not as passive search. Standards help interoperability; they do not remove your obligation to know what code runs on developer laptops. Document allowed servers, rotate credentials, and keep backups—then you get the productivity upside without turning every IDE into an unmanaged integration bus.