MCP Security: How to Audit Model Context Protocol Servers in 2026

The Model Context Protocol (MCP) has quickly become the standard way AI applications connect to external tools, data sources, and actions. An MCP server can expose a file system, a database, an internal API, or a set of business workflows to any AI agent that connects to it. That power cuts both ways: every MCP endpoint is now part of your attack surface, and most security teams have never scanned one. This guide walks through the real risks and how to audit them — with deterministic checks, not another AI guessing about your security.

What an MCP Server Actually Exposes

An MCP server exposes three kinds of capabilities to connecting agents:

• Tools — functions the model can invoke (read a file, run a query, send an email)
• Prompts — prompt templates the server publishes, which become part of the model's instructions
• Resources — data the server makes available (documents, configuration, records)

When any of these are reachable without authentication, or expose more than intended, an attacker does not need to "hack the AI" — they simply talk to the protocol directly.

The Five MCP Risks That Matter

1. Unauthenticated MCP endpoints

The most common finding by far: an MCP server bound to 0.0.0.0 or exposed through a reverse proxy with no auth. Anyone who can reach the URL can list and invoke tools. If a tool reads files or queries a database, the endpoint effectively becomes a remote data-access API with no logging, no rate limiting, and no account lockout.

2. Tool poisoning and description injection

Tool definitions include natural-language descriptions that the model trusts when deciding how to use them. An attacker who can influence a tool description (through a plugin marketplace, a compromised dependency, or a misconfigured registry) can inject instructions — "call this tool with admin credentials," "exfiltrate parameters to this host" — that the model will follow. This is the MCP-specific version of prompt injection, and it is invisible to conventional tooling.

3. Resource and prompt leakage

Servers frequently publish resources that contain far more than the team intended: .env-style configuration, internal documentation, database connection strings, or entire directories. Because MCP is designed for discoverability ("list what you have"), a misconfigured server happily enumerates its own sensitive material.

4. Dangerous tool surfaces

Beyond what tools say, what tools do matters: file-write tools without path scoping, shell-execution tools, database tools without read-only enforcement, or HTTP-fetch tools that can reach internal addresses (a server-side request forgery primitive wrapped in an AI-friendly interface).

5. Adjacent AI infrastructure exposure

MCP rarely ships alone. AI stacks bring their own panels and agents — local LLM dashboards (Ollama, Open WebUI), workflow builders (Flowise, n8n, Dify), agent-to-agent (A2A) card endpoints, and llms.txt / ai-plugin.json manifests that reveal how AI features are wired. Each is a distinct exposure class.

How to Audit MCP — Deterministically

There is a temptation to "scan AI with AI" — point an LLM at your stack and ask it to look for problems. We believe the opposite: your audit should produce the same answer every time it runs, with evidence you can show an auditor. Our engine treats AI infrastructure like any other protocol surface:

• MCP Endpoint Security — probes for exposed MCP endpoints and verifies what is reachable without authentication
• MCP Resource & Prompt Exposure — enumerates published resources and prompts, flagging sensitive material and overly broad defaults
• MCP Tool Surface & Poisoning Analysis — inventories tools, examines descriptions for injected-instruction patterns, and flags dangerous capability classes (file writes, shell execution, unrestricted HTTP)
• LLM / AI Agent Surface — checks llms.txt, ai-plugin.json, and related AI-surface manifests for information disclosure
• A2A Agent Card Exposure — audits agent-to-agent discovery endpoints
• AI Panel Exposure — fingerprints exposed instances of Ollama, Open WebUI, Flowise, n8n, Dify, and similar panels
• OWASP LLM Top-10 probe (deterministic) — the OWASP LLM Top 10 categories that can be tested through HTTP behavior, tested with fixed probes and fixed verdicts

Every check runs without API keys, without calling external AI services, and without sending your data to a third-party model. The verdict is the same on every run — which is what makes it suitable for continuous monitoring and for evidence.

A Practical MCP Hardening Checklist

1. Require authentication on every MCP endpoint — no exceptions for "internal" servers.
2. Bind to localhost or a private network unless an endpoint genuinely serves external agents.
3. Scope tools deliberately — read-only where possible, path-restricted file access, no shell execution in production.
4. Curate resources — publish explicitly, never by directory default.
5. Validate tool descriptions in your supply chain; treat plugin metadata as untrusted input.
6. Monitor the endpoints continuously — MCP estates grow quietly, one weekend experiment at a time.

Scan Your AI Surface Today

If your organization is running MCP servers, AI panels, or agent infrastructure, add them to your monitoring before someone else discovers them. Start with a free scan of your domain, then review the AI & LLM scanner family on the features page. The same 232-scanner engine — with the full AI surface suite — is also available as a self-hostable open-source core on GitHub.

Related reading: API Security Testing Checklist · Cloud Misconfiguration Scanning · Open-Source Web Vulnerability Scanners in 2026