The word people use to describe an MCP server determines which controls they apply. And almost everyone uses the wrong word.
What the name changes
Calling it a plugin triggers a set of expectations: one-command install, limited scope, risk contained within the hosting application. None of that holds here. An MCP server executes code, carries credentials, reaches the network and produces irreversible effects in third-party systems.
Calling it a workload triggers a different set: it needs its own identity, segmentation, logging, a named owner, a lifecycle, and vendor assessment when it comes from outside. Every one of those expectations is the correct one.
This is not semantics. Classification decides whether the component enters the asset inventory or stays invisible to the security programme.
The reclassification test
For each MCP server in your environment, answer five questions. They are the same ones you would ask of any production service:
- Which identity does it use, and is that identity its own or borrowed from a human?
- Who can reach it, and where can it reach out to?
- Where do its logs go, and does anyone read them?
- Who is the human owner when it breaks at two in the morning?
- If the maintainer abandons the project, what is the plan?
If these questions feel excessive for the component, that is because it was classified as a plugin. If they feel obvious, the reclassification already happened.
Why the industry is getting this wrong again
The same thing happened with containers. For years a container was treated as a packaging detail — until the market realised it was an execution unit with its own identity, network and surface. Then came admission control, image scanning and runtime policy.
MCP sits at the same point on the curve, with one difference: adoption is faster and the posture tooling does not exist yet. Teams that reclassify now apply mature controls to a new component. Teams that wait will apply new controls to an already-spread problem.
