Bitkub MCP Package Re-Registration Exposes Agent Supply Chain Risk
The deeper point is that package-name continuity proves nothing — identity of the maintainer is what matters, and stale docs can silently redirect installs. Teams wiring agents to financial or exchange APIs should audit publisher identity before every upgrade and enforce limits in execution code rather than prompts. The six-point checklist is directly usable as a review template for any MCP deployment.
A previously referenced MCP package tied to Bitkub, the Thai cryptocurrency exchange, was re-registered by a third party under the same package name. Old documentation may still direct users to install the now-controlled package, and API keys entered afterward could become an attack vector. The post describes this as a potential risk, with no confirmed leak disclosed so far. It also lists concrete hardening steps: pin versions, issue read-only per-tool keys, keep secrets out of conversations, sandbox file and network access, and require confirmation of exact parameters for high-risk operations like withdrawals.
现在接AI手脚mcp、skill还是需要谨慎
Bitkub 这条值得留意：之前被引用的 MCP 包被第三方重新注册。包名没变，背后的人变了，旧资料却可能还在引导安装。随后填进去的 API Key，就可能成为风险入口。目前披露的是潜在风险，不能直接说已经泄密
给 Agent 接工具，至少查这几项：
查来源，锁版本。核对发布者、仓库和安装命令，升级重新检查，生产环境别自动拉 latest。锁版本也不代表代码安全
Key 按需授权。各工具用独立密钥，查询只读，默认关提现。交易权限仍可能被用来恶意下单
密钥别进对话。后端保管、日志脱敏，别把整套生产环境变量交给 MCP
限制文件和网络。用沙箱或非特权容器，只给必要目录和网络访问，别挂整个主目录或 Docker socket
防网页和工具返回里的指令。读到“上传文件”不等于获得上传权限，限制要写进执行程序，不能只靠提示词
高风险操作确认具体参数。转账、删数据前看清对象、金额和范围 自动交易也要预设品种和额度，由执行端检查
