In 2024, the Model Context Protocol (MCP) aimed to become the USB-C of artificial intelligence — a single standard for connecting models, agents, and development environments to tools and data. By that measure, the protocol delivered: thousands of developers shipped servers, and enterprises wired them into agentic workflows at speed.
A security audit of the public server ecosystem, reported on The Hacker News, suggests the ecosystem around the protocol did not keep pace. Security researchers at OX Security examined 15,465 publicly available MCP servers and found recurring, systemic weaknesses: credentials embedded directly in server code or configuration, and tool definitions that grant far more access than any given workflow should require.
What the audit found
OX Security had already traced critical vulnerabilities in Anthropic's MCP ecosystem earlier in 2026. The new body of research widens the lens to the public server ecosystem itself, where the pattern is consistent rather than incidental.
Two categories of weakness dominate. The first is hardcoded or otherwise exposed credentials — API keys, tokens, and secrets that ship inside server packages or sit in public repositories. The second is over-permissive tool configuration: servers whose tool definitions expose broad capabilities, wildcard-style permissions, or actions far exceeding the narrow task an agent was deployed to perform.
The findings are described at the categorical level rather than through itemised counts. The full breakdown — how many servers leaked keys, how many carry wildcard permissions — has not been made public.
Why MCP design amplifies the risk
The uncomfortable part is structural. Unlike a traditional software supply-chain problem, where malicious code typically compromises a build or a runtime, MCP servers are invoked by design in agent workflows — with live credentials, often production ones. An over-permissive tool definition does not merely expose a vulnerability; it hands an autonomous process the authority to act.
The closest mental model is npm. The Model Context Protocol's ecosystem now looks like the early npm registry: fast growth, minimal vetting, uneven hygiene, and a long tail of packages that enterprises adopt without review. The difference is that npm packages mostly contain code that runs in isolation, while MCP servers execute real actions against real systems. The blast radius of a bad package is correspondingly larger.
That framing matters for anyone building internal agent tooling, not just for those shipping public servers.
What adopters should consider
The categories of weakness described in the audit point to a clear set of defensive priorities for teams running MCP servers in production:
- Inventory. Maintain an up-to-date list of every MCP server deployed in development and production environments, including the tools each exposes.
- Treat servers as untrusted code. Review tool definitions and server configuration before deployment; do not assume public servers have been audited.
- Rotate and scope credentials. Assume any key embedded in a public or shared server is compromised. Move to managed secret stores and short-lived, narrowly scoped credentials.
- Apply least privilege. Restrict tool permissions to the minimum the workflow requires, and review those permissions on a regular cadence.
For teams handling personal or regulated data, embedded credentials and over-broad tool permissions raise questions about data leakage, access control, and breach exposure that sit with security and compliance owners, not just developers. In Hong Kong, those obligations are most visibly framed by the Personal Data (Privacy) Ordinance, but the underlying hygiene issue — over-broad access granted to autonomous processes — is a technical problem that any regulatory lens will eventually have to parse.
The verdict
MCP as a protocol has succeeded. The ecosystem around it — the registries, the vetting, the credential hygiene — has not caught up.
MCP has not failed. It has arrived.
Editor's note: This article is based on summary material and headline-level reporting from the cited source. Attributions to OX Security and The Hacker News are drawn from the material available to us at time of writing; readers are directed to the original URL for the full report. No itemised audit figures have been invented or estimated, as the complete dataset was not accessible during preparation.
2024 年，Model Context Protocol（MCP）立志成為人工智能界的 USB-C——即連接模型、agents 與開發環境至工具及數據的單一標準。就這目標而言，該協議確實做到了：數以千計的開發者推出了 MCP servers，企業亦迅速將其整合到 agentic workflows 之中。
一項經 The Hacker News 報道、針對公開 server 生態系統的安全審計顯示，圍繞該協議的生態系統未能跟上步伐。OX Security 的安全研究人員檢視了 15,465 個公開可用的 MCP servers，發現一系列反覆出現、屬於系統性的弱點：憑證直接寫入 server 程式碼或配置之中，以及 tool definitions 所賦予的存取權限遠遠超出任何特定 workflow 的實際需要。
審計發現了甚麼
OX Security 早於 2026 年初已追蹤出 Anthropic MCP 生態系統中的多項嚴重漏洞。這項新研究擴大了視野，聚焦於公開 server 生態系統本身，顯示有關問題屬普遍模式，而非個別情況。
當中以兩類弱點最為突出。其一是寫死（hardcoded）或以其他方式外洩的憑證——API keys、tokens 及 secrets 被隨 server 套件發放，或存放於公開 repositories 之中。其二是過度寬鬆的 tool configuration：某些 servers 的 tool definitions 暴露了大範圍功能、萬用字元式（wildcard）權限，或執行遠遠超出 agent 原定任務範疇的操作。
有關發現只在類別層面描述，並未提供逐項統計。完整數據——有多少 servers 洩露 keys、多少帶有 wildcard 權限——尚未公開。
為何 MCP 的設計放大了風險
令人不安的地方在於問題的結構性質。與傳統軟件供應鏈問題不同——惡意代碼通常破壞的是 build 過程或 runtime——MCP servers 在 agent workflows 中本來就是按設計被呼叫（invoke）的，而且往往帶着生產環境的實際憑證。過度寬鬆的 tool definition 不單暴露漏洞，更是把行事的權力交給一個自動化程序。
最貼切的類比是 npm。MCP 的生態系統如今的情況，宛如早期的 npm registry：增長迅速、審核極少、衛生標準參差，並有大量企業未經審查便採用的長尾 packages。差別在於，npm packages 大多是於隔離環境中運行的代碼，而 MCP servers 則是針對真實系統執行真實操作。一旦出現「壞 package」，其爆炸半徑自然大得多。
這個框架對任何構建內部 agent tooling 的團隊同樣重要，並不限於公開發布 servers 的人。
採用者應注意的事項
審計所描述的弱點類別，為在生產環境中運行 MCP servers 的團隊指出了一套明確的防禦優先事項：
- 盤點（Inventory）。 為開發及生產環境中每一個已部署的 MCP server 維護一份最新清單，包括它各自提供的工具。
- 視 servers 為不可信代碼。 部署前必須審查 tool definitions 及 server 配置；切勿假設公開 servers 已通過審計。
- 輪換及限制憑證範圍。 應假設任何嵌入公開或共用 server 中的 key 均已被洩露。改用受管理的 secret stores，以及短效期、範圍嚴格限定的憑證。
- 實踐最小權限原則（Least privilege）。 將工具權限限制於 workflow 所需的最低水平，並定期複核這些權限。
對於處理個人數據或受規管數據的團隊而言，嵌入式憑證及過度寬泛的工具權限，會引發關於數據外洩、存取控制及違規風險的問題，而這些問題屬安全與合規主管的職責範疇，並非只關乎開發者。在香港，這些法律責任以《個人資料（私隱）條例》（Personal Data (Privacy) Ordinance，PDPO）最為清晰地體現；然而底層的衛生問題——賦予自動化程序過度廣泛的存取權限——始終是一個技術問題，任何規管角度最終都必須正視。
結論
MCP 作為協議，已經成功了。而圍繞它的生態系統——registry、審核機制、憑證管理衛生——則尚未追上。
MCP 並非失敗了。它只是才剛剛到來。
編者按：本文依據所引來源的摘要材料及標題層面報道撰寫。對 OX Security 及 The Hacker News 的引述，均取自撰稿時手上可用的材料；讀者可透過原始 URL 查閱完整報告。本文沒有虛構或估算任何審計的逐項數據，因準備期間未能取得完整數據集。