Inside MCP Servers

Introduction

Modern AI assistants often need to fetch live data or execute actions beyond their base model. Model Context Protocol (MCP) servers provide a standardized way to bridge that gap. Think of an MCP server as local middleware or a plugin host for your AI model, a broker that securely exposes tools such as web search, databases, or file systems to the model through standardized calls.

The AI (the client) connects to the MCP server, which then interfaces with the external service. This isolates third-party API interactions from the model’s core and adds control, auditability, and security. Currently, the heart of MCP is JSON-RPC 2.0, a lightweight protocol for structured remote procedure calls.

Each request and response follows a simple JSON schema with fields such as jsonrpc, method, params, and id, allowing the AI to use one standard “language” across all tools. The MCP server handles the rest.

Deeper look at MCP messages

An MCP server translates the JSON-RPC requests from the AI into real API or system actions, then wraps the results back into JSON-RPC before returning them. This creates a controlled, uniform, and sandboxed environment.

Simplified Flow:

• AI → MCP (JSON-RPC): The AI sends a request.
• Dispatch: MCP validates, applies policy, and executes the tool.
• Outbound call: MCP performs the real HTTPS or DB action (no JSON-RPC in this one).
• Return: MCP wraps results in JSON-RPC and returns them to the AI.

This design ensures secrets (like API keys) stay within the MCP and never reach the AI model directly.

Because MCPs often use local HTTP or WebSocket, their traffic can be inspected in tools like Wireshark.

Sample used:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "brave_web_search",
    "arguments": {
      "query": "Indiana Jones"
    }
  }
}

This visibility is what makes packet inspection and protocol awareness essential for MCP deployments. The payload clearly shows JSON fields such as method and params when not encrypted. When encryption (TLS) is used as it should be—for instance, in remote MCP connections—deep packet inspection (DPI) by a Next-Generation Firewall (NGFW) becomes critical. Without decrypting and inspecting the traffic, the NGFW cannot recognize JSON-RPC structures or apply protocol-specific policies. Proper decryption and inspection are essential to enforce Data Loss Prevention (DLP), detect anomalies, and prevent unauthorized API exposure. Even with DPI enabled, evasion remains theoretically possible.

Local vs. Remote MCP Servers

• Local MCPs run on the same host or network segment for low latency and tight control.
• Remote MCPs operate mainly over HTTPS, using TLS and authentication for secure transport.

In both cases, the external systems they connect to use standard REST or GraphQL APIs, and not JSON-RPC.

Dark side of MCP servers

Let’s look at how bad actors are leveraging this new vector. In late September 2025, new research revealed a rising threat inside the MCP ecosystem. A team of security analysts examined publicly available MCP servers (around 16,000) and found twelve categories of attacks targeting configuration logic, initialization routines, and tool calls.

Some attacks achieved a 100% success rate in exploiting connected hosts. These malicious MCPs behave like legitimate ones, using the same protocols and requests, making them almost impossible to distinguish from legitimate useful ones.

Key Findings

• Many malicious servers can exfiltrate files, tamper with model responses, or spawn subprocesses.
• Once an AI client connects, the attacker gains its permissions.
• Different scanners tested on 120 malicious MCPs missed most cases; one detected only four.
• No current tool covers all attack categories identified in this study.

The reason why detection fails is because JSON-RPC activity is legitimate traffic, endpoint agents and network sensors rarely flag it. If TLS hides the payload, firewalls without DPI see only generic HTTPS. The research confirmed: “No existing auditing system protects against all identified MCP attack vectors.”

Securing MCP servers

Now that we understand what MCP servers are, how they operate, and the risks, here’s a consolidated checklist to secure them effectively:

Network & Transport

• Bind to localhost by default; use private ingress or service mesh for any remote access.
• Enforce TLS (mTLS for service-to-service) and decrypt JSON-RPC traffic where policy allows for inspection.
• Apply strict egress allow-lists; only approved domains and APIs should be reachable.

Authentication & Authorization

• Treat MCPs like browser extensions: approve, sign, hash, and pin specific versions.
• Verify origin, maintain an internal registry, and block unsigned or unverified connectors by default.
• Require per-client authentication with least privilege per tool, including rate limits and query-cost budgets.
• Make permissions visible and revocable.

Secrets & Identity Management

• Store credentials in a secure vault, and never in prompts, payloads, or environment variables.
• Rotate short-lived tokens frequently and redact secrets from all logs or captures.

Data Protection & Sanitization

• Validate inputs and schemas to block injection, traversal, or malformed payloads.
• Inspect outbound data for PII, secrets, or policy violations.
• Sanitize all outputs, strip hidden characters, and script fragments before reusing model responses.

Execution & Isolation Controls

• Run each MCP in its own container or sandbox (WASM or VM) with scoped filesystem and network limits.
• Disallow arbitrary command execution; if required, restrict to predefined safe commands.
• Use parameterized queries and return only necessary fields.

Visibility, Detection & Governance

• Log key events (tool name, method, argument hash, response size, allow/deny decision).
• Monitor for runtime anomalies: file writes, new subprocesses, or unexpected network calls.
• Enable controlled forensic capture for IR and compliance.
• Integrate MCP oversight into broader vulnerability management and change-control processes.

Final Thoughts

MCP servers are amazing bridges between AI and the external world. When built and secured correctly, they enable standardization, control, and visibility, without exposing sensitive data or unmanaged tool access. But as this research shows, trust without verification is not a viable option without incurring serious risk. Security teams must extend their threat models to include the connectors themselves, not just the models they serve.

Building trust in AI means securing not just the models, but also the connectors that empower them; because when governed properly, MCP servers don’t just link tools; they unlock the full power of integrated, auditable, and accountable AI systems.

---

References

1. Help Net Security. When Trusted AI Connections Turn Hostile: Researchers Uncover New Attack Surface in Model Context Protocol Servers. October 16, 2025.
2. Zhao, W., Liu, J., Ruan, B., Li, S., & Liang, Z. (2025). When MCP Servers Attack: Taxonomy, Feasibility, and Mitigation. National University of Singapore and Peking University.
3. OpenAI Developer Docs. Model Context Protocol (MCP) Specification – JSON-RPC over WebSocket.
4. JSON-RPC Working Group. JSON-RPC 2.0 Specification.
5. OWASP Foundation. OWASP Top 10 for LLM Applications (LLM01–LLM10). 2024.
6. Center for Internet Security (CIS). CIS Controls v8 - Control 13: Network Monitoring and Defense.