21 个 MCP 服务的权限隔离实践

让 AI agent 操作 Kubernetes、数据库或企业协作工具，难点不只是接通 API，还包括限制它能看见什么、修改什么，以及谁来批准危险操作。dockndevai 把同一套治理规则放进 21 个开源 MCP server，累计获得 30,185 次 npm 下载。

作者最有价值的经验是：安全边界要落实在默认配置和工具注册阶段。同时，下载量不等于用户数，npm publish 成功也未必代表版本已经公开可用。

为什么只读默认值还不够

这套 Model Context Protocol（MCP）服务让 agent 通过统一协议操作真实系统，覆盖 Kubernetes、OpenShift、Kafka、ClickHouse、Debezium、PostgreSQL（Percona）、Grafana、Azure、OCI、Keycloak、GitHub Enterprise、Outlook、Teams、macOS、Android、iOS，以及检索自有文档的 RAG 服务。

作者强调的是操作范围可控，而不只是功能覆盖广。

所有服务默认只读。写入和管理工具只有在提升访问模式后才注册。对模型而言，当前模式下不能执行的工具，根本不会出现在可用工具列表里。

权限控制应该先限制模型能拿到什么工具，再约束工具如何执行。

这比把所有工具都交给模型、调用时再拒绝，多了一道前置边界。但隐藏工具不能替代执行端校验，后者仍要确认操作是否符合权限。

范围控制则通过允许列表和受保护资源完成：可以限定 namespace、数据库、组织或项目；受保护资源允许读取，禁止修改。即使开启写入，也不必把整套系统全部开放。

下面的命令把 Kubernetes MCP server 接入 Claude，并显式指定只读模式：

claude mcp add kubernetes -e K8S_MODE="read-only" -- npx -y @dockndevai/mcp-kubernetes

要看的是 K8S_MODE="read-only"。它声明了权限模式，但原文没有展示允许列表、受保护资源等配置的具体写法。

危险操作为什么要叠加多道门

作者给破坏性操作设置了多项条件：进入 admin 模式、显式开启操作开关、输入确认内容，并通过 MCP elicitation 向人发起审批。这里的 elicitation，可以理解为服务在操作过程中向人请求补充输入或确认。

这些条件分别限制权限、表达操作意图、核实确认内容，并引入人工审批。原文没有提供完整交互示例，因此不能据此判断每种客户端中的审批体验。

此外，套件提供 dry-run、JSON 审计日志和敏感信息脱敏。它们分别用于预演操作、记录行为和减少秘密信息暴露。

可选的本地风险守卫 laya-guard 使用设备端模型，把风险命令分为 allow、confirm、block。它只能收紧已有权限，不能放宽权限。这一点很关键：风险模型即使认为命令安全，也不能替它取得原本没有的授权。

21 个服务共同使用 mcp-core。作者希望维护一份经过审计的实现，避免各个服务复制安全逻辑后逐渐分叉。不过，原文没有交代审计主体、范围和结果，不能把这句话直接当成独立安全认证。

下载量和发布成功，各自说明了多少

套件累计有 30,185 次 npm 下载，目前每月约 8,000 次。作者主动提醒，npm 统计的是安装事件，其中包括 CI 重装、镜像和安全扫描器产生的流量。

他举出的直接证据来自另一处：mcp-laya 在 PyPI 上排除镜像流量后，计数大约减少 64%。这个数据说明安装量可能被显著放大，却不能拿来直接折算 npm 的真实用户数。

作者更看重每月约 8,000 次的持续趋势。这个取舍有道理，但月度数据同样包含自动化安装，只能作为持续使用或关注的信号。

另一个坑发生在最新的 mcp-github-enterprise 上：它遇到了 npm 的 staged publishing。npm publish 报告成功，公开可见的却只有 0.0.0-stage 占位版本，正式发布需要维护者通过 2FA 批准。

继续提升 patch 版本没有解决问题，作者给出的处理命令是 npm stage approve。原文没有列出触发该流程的具体条件，因此应把它当作这次发布的排障经验，而不是所有 npm 包的固定发布步骤。

我的判断

我认同「安全路径成为默认路径」的方向。相比只在提示词里要求 agent 谨慎操作，工具注册、资源范围和执行权限更适合承担安全边界。它们能在模型作出错误判断时继续发挥作用。

但这篇提供的是设计经验和个别实际案例，没有给出越权测试、误拦截率，或与其他权限方案的对照数据。laya-guard 的分类效果、审批增加多少操作成本，也都没说清。

共享 mcp-core 能减少重复实现和规则漂移，同时也让公共实现成为关键依赖。一处缺陷可能影响多个服务。采用这套方案时，需要检查公共库的权限实现和升级方式，下载规模本身不能回答这些问题。

能拿来做什么

• 给日常 AI 编程环境接入数据库或 Kubernetes MCP 时，先配置只读模式和明确的资源范围，再按具体任务开放写入能力。
• 在 Node 中开发 MCP server 时，按权限模式注册工具，并在执行端校验资源范围；不要只依赖工具描述提醒模型谨慎调用。
• 为删除、重置等操作保留独立开关、人工确认和审计记录，并验证 dry-run 实际覆盖哪些行为。
• 发布 npm 工具后，检查公开版本是否可安装；遇到 0.0.0-stage 时，排查 staged publishing，避免反复提升 patch 版本。