The Model Context Protocol, introduced by Anthropic in November 2024, is an open standard for connecting AI models to tools and data. An MCP server exposes capabilities, such as query the ticketing system, read this repository or send a message, and an agent calls them. Adoption was fast because the problem it solves is real: every team was writing its own integration layer. The result is a new kind of server in a lot of environments, often stood up quickly, often by people who are not the security team, and often reachable in ways nobody intended.

What an MCP server is, in security terms#

Strip away the protocol and an MCP server is an API that performs actions on behalf of whoever can talk to it, with credentials it holds. That description should sound familiar. It is a privileged service, and it needs the controls privileged services need: authentication, authorization, least privilege, logging and testing. The difference is the caller. The caller is a model, and models can be talked into things.

What goes wrong#

  • No authentication. Early MCP deployments, especially those using network transports, frequently had none: anyone who could reach the port could call every tool. The 2025 revision of the specification added OAuth 2.1 based authorization for remote servers; many servers in the wild still predate it or ignore it.
  • Over-broad tools. A tool named run query that accepts arbitrary SQL, or execute command that accepts a shell string, turns any prompt injection upstream into database access or code execution.
  • Tool poisoning. In April 2025 Invariant Labs described attacks in which malicious instructions hidden in a tool's own description manipulate the model into misusing other tools or exfiltrating data. The description is read by the model, not the user, so the user never sees it.
  • Confused deputy. The server acts with its own credentials on behalf of a caller whose identity it does not check, so a low-privilege user, or an injected instruction, inherits the server's access.
  • Secrets in reach. Servers configured with long-lived API keys and tokens become a single place to steal them all.
  • Unknown servers. Agents are often configured by developers against servers nobody in security knows exist, inside and outside the perimeter.

What to check before deployment#

  • Reachability. Who can connect to this server, from where? If the answer includes the internet, it needs authentication today.
  • Authentication and authorization. Does the server verify the caller, and does it enforce what each caller may do, or does every authenticated caller get every tool?
  • Tool surface. List every tool and its parameters. Any tool that accepts free-form code, queries or commands needs a hard reason to exist.
  • Credentials. What does the server hold, how scoped is it, how is it rotated, and could it be read-only?
  • Descriptions. Read every tool description as if it were untrusted input to the model, because it is.
  • Logging. Every tool call, with the caller and the arguments, somewhere the security team can see it.

What to keep checking#

MCP servers change. Tools get added, descriptions get edited, credentials get widened to unblock a feature. A server that passed review in March is a different server in June. Discovery has to find MCP servers the way it finds any other exposed service, by looking at what is actually reachable; validation has to attempt them as an outsider would: connect, enumerate tools, try to call them without credentials, and follow what a successful call reaches.

How SecureX360 treats them#

SecureX360 counts MCP servers as part of your AI attack surface alongside LLM applications and agents. Discovery finds the ones attached to what you own; validation tests them as a connecting client would, from the outside; and anything that gets through reaches the owner with the transcript and the tool calls as proof. The protocol is new. The discipline is the one you already know: no privileged service goes untested, and none stays tested for long.