npm 新 2FA 规则与 AI 工具权限治理

在 AI 辅助项目中，最危险的一句话不是“代码运行失败了”。

而是“代码成功运行了，所以我把所有权限都交给了这个工具。”

7 月 31 日，npm 限制了那些配置为绕过双重身份验证（2FA）的细粒度访问 token 所能执行的操作。这类 token 将无法再执行创建或删除 token、更改 package 访问权限、添加维护者或更改 trusted publishing 设置等敏感操作。npm 表示，这些操作现在必须通过交互式 2FA 验证。

在此前 24 小时里，我没有发现更值得关注的 AI 或开发者工具动态，因此把搜索范围扩大到了七天。这项变更发生在三天前。

npm 还预告了下一道权限边界。它计划于 2027 年 1 月取消这类绕过 2FA 的 token 直接发布 package 的能力。自动化系统仍然可以读取私有 package，并把 release 暂存起来，但公开发布必须由维护者通过 2FA 批准。

这不仅仅是 package registry 的一个细节。对于任何使用 AI 构建产品的人来说，它都是一种很实用的运作模式：

让工具为不可逆操作做好准备，但不要自动把执行不可逆操作的权力也交给它。

实际发生了什么变化

眼下的变更针对的是 npm 细粒度访问 token，而不是所有类型的 GitHub 或 npm 凭证。绕过 2FA 的 token 再也不能借着便利性，摇身一变成为管理整个账户的万能钥匙。

这切断了一条非常危险的攻击链。如果攻击者拿到了其中一个 token，过去可以利用它更换维护者、创建更多凭证或修改 package 的访问权限。问题不只是凭证本身拥有很大的权力，而是它还能利用这些权力创造出更多权力。

计划中的发布机制变更让这种职责分离更加清晰：

自动化系统可以构建并暂存 package。

人类维护者可以看到即将公开发布的具体内容。

另一个经过身份验证的审批步骤负责将其正式发布。

npm 的 trusted publishing 文档建议使用短期、特定于 workflow 的 OIDC 凭证，而不是长期有效的发布 token。文档还介绍了一套围绕 staged publishing 构建的仅暂存配置：CI 可以准备 release，但在正式发布之前，必须由维护者通过 2FA 批准。

npm 的具体配置并不适用于每一种应用，但它背后的结构具有长期价值。

初学者可能对 AI 权限产生的误解

npm 的这项变更针对的是 package 凭证，而不是 AI coding Agent。我之所以把它的 release 模型应用到 AI 辅助工作中，是因为两者面对的是同一个权限问题：一个能够为变更做好准备的系统，并不一定需要同时拥有公开变更、向客户收费、删除数据或修改账户权限的权力。

初学者经常把权限当成一个非开即关的二元开关：

AI 什么都不能做，所以每一步都很慢。

AI 什么都能做，所以每一步都令人兴奋——直到现场变成一桩配有顶级自动补全功能的刑事案件。

其实还有一个更好的中间地带。

给予工具足够的权限，让它能够产出证据；对于难以撤销的操作，则保留一道独立的关卡。

在你接入更多工具之前，我已经免费开放了 AI App Builder Starter Prompts，帮助你先明确用户 workflow、范围、数据、约束，以及 AI 应该产出的验证证据。

三道关卡的工作流：准备、验证、发布

我会把一次 AI 辅助 release 划分为三道关卡。

准备

在这一关，AI 可以完成大量工作。

它可以检查 repository、编辑代码、运行本地测试、生成 build、起草 release notes、制定 migration 计划，以及暂存一个候选部署版本。它还可以解释自己修改了哪些文件，以及做出了哪些假设。

但“准备”阶段的终点应该是一个可供审查的产物，而不是对外界产生实际影响。

对于 Web 应用，这个产物可能是一次 preview deployment；对于移动应用，它可能是一个 archive 或 internal test build；对于 package，它可能是一个 staged version；对于 newsletter，它可能是一份已经填写完成、但没有发送权限的草稿。

工具的职责，是把模糊的意图转化成可以检查的候选结果。

验证

接下来，候选结果必须证明自己值得被正式发布。

验证方式应该与风险相匹配。修改按钮颜色，可能只需要一张截图和一次快速的 viewport 检查；修改身份验证功能，则可能需要使用两个账户进行测试，并验证 session 过期行为、密码恢复流程和权限控制；数据库 migration 则需要备份、dry run、行数检查和 rollback 路径。

对于大多数初学者开发的应用，我会要求提供五类证据：

变更摘要：用用户能够理解的语言说明发生了什么变化。

自动化检查：说明通过了哪些测试、build 或 linter。

人工流程：说明从头到尾完成了哪一条真实用户路径。

失败检查：说明输入错误、数据缺失或服务不可用时会发生什么。

回滚说明：说明如何恢复到上一个已知可用的状态。

你的 AI coding 工具可以帮助生成这五类证据，但不能仅仅因为输出里出现了一排绿色勾号，就被允许给自己的作业打满分。

发布

发布是最短的一道关卡，也是受到最严格保护的一道关卡。

用于 release 的身份应该只拥有完成此次发布所必需的权限。如果平台支持，应优先使用短期凭证。对于会改变外部世界的操作，则应要求一次独立确认。

• 推进一个已暂存的 package

• 将通过验证的 commit 部署到 production

• 向 app store 提交经过测试的 build

• 执行已经审查过的数据库 migration

• 发送已经批准的 email campaign

• 将支付集成从 test mode 切换到 live mode

这里最重要的词是“已经审查过”。发布操作必须指向在第二道关卡中通过验证的那个确切候选版本。如果代码在审查之后发生变化，就必须重新进行验证。

一张适合初学者的权限表

你不需要先组建一个企业级安全部门。只要为自己的项目写一张简洁的权限表即可。

这张表并不适用于所有项目。你的应用可能需要不同的条目。重点是，不要让权限在无意间被授予。

针对每一个工具连接，问自己三个问题：

• 这项权限能够产出哪些有用的证据？

• 如果指令或凭证有误，它可能造成什么损害？

• 能否把 live 环境中的操作与准备工作分开？

AI App Builder Starter Prompts 在这里也很有用，因为同一组范围界定和 QA prompt，既可以规定工具能够准备什么，也可以定义你期望在发布前看到哪些证据。

为什么暂停等待批准是一项生产力功能

人们一听到“人工批准”，脑海里就会浮现这样的画面：十二个人开了六个星期的会，只为讨论一个按钮。

这并不是我们的目标。

一道好的审批关卡应该足够狭窄。工具已经完成了耗时的工作，人类只需要根据清晰可见的证据回答一个小问题：是否允许这个确切的候选版本跨越这道确切的边界？

GitHub 在 7 月 28 日也采用了类似的思路。它宣布，公共 repository 中某些可能具有恶意行为的 GitHub Actions workflow 将被暂停，等待批准。只有拥有 write access 的协作者通过经过身份验证的 Web session 批准之后，workflow 才会运行。

这种暂停之所以有价值，是因为它恰好位于执行之前。它不需要一个人手动重新构建整个 workflow。

我希望小型 AI 辅助项目里的审批也是这种感觉：它应该是悬崖前的减速带，而不是道路起点处的停车场。

权衡：关卡太多会制造权限表演

你完全可能在这件事上做过头。

如果每次本地测试、preview build、拼写修正和可逆变更都需要人工批准，人们最终只会不假思索地一路点击确认。一个频繁弹出的关卡，最后只会沦为无人留意的背景墙纸。

另一个局限是，批准并不能证明候选版本一定安全。人类可能批准错误的 commit、误解验证证据，或者漏掉恶意依赖。双重身份验证保护的是执行批准操作的身份，并不会替你审查代码。

这正是三道关卡各有不同职责的原因：

• 准备阶段创建候选结果

• 验证阶段创建证据

• 发布阶段控制后果

不要把发布关卡当成测试的替代品，也不要因为已经完成测试，就把所有凭证都交给 build 工具。

接下来应该做什么

从你的项目中选择一个会影响 live 环境的操作：production deployment、数据库 migration、package 发布、app-store 提交、发送 email，或者启用支付功能。

明确写下：

• AI 可以准备什么

• AI 可以在测试环境中执行什么

• 必须具备哪些证据

• 谁或什么系统可以批准 live 环境中的操作

• 执行 release 的身份如何获得凭证

然后，移除准备阶段并不需要的所有权限。

你不必为了让 workflow 处于控制之中，就把它变得缓慢。你真正需要的是：让 AI 完成范围广泛、可重复的工作，同时让一个权限狭窄且经过验证的身份掌控不可逆的关键时刻。

如果你想立即在引导下行动，可以从免费的 AI App Builder Starter Prompts 开始。如果你想获得一条从创意走向发布的系统化路径，可以选择我售价 19 美元的实战手册 AI App Builder From Zero，其中涵盖范围界定、技术栈、项目规则、QA、部署和发布。

你还可以在这些平台找到我：

Medium：marcusykim
DEV.to：marcusykim
Website：marcusykim.com
X：marcusykim
LinkedIn：marcusykim

如果需要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。