一句话定义：允许列表漂移（Permission Allowlist Drift）是指为了让工具少弹窗，随手点「不再询问」而累积起来的持久化白名单（persistent allowlist），随着时间不断膨胀，最终超出任何人最初授权时的意图，变成一份没有人审核过、也没有人记得的隐性放行清单。
问题的来源
以 Claude Code 这类能直接执行命令的编程助手为例：当它想运行一条命令、读一个目录或访问网络时，会弹窗问你「允许吗」。弹窗很烦，于是多数人会顺手勾上「不再询问（Don't Ask Again）」。这一次点击的后果不只是这一次放行：工具会把这条规则写进配置文件，从此对所有会话生效，可能是项目级配置，也可能是用户级配置，具体文件与层级以官方页面为准。
于是就会出现一种很难察觉的扩散：本来你只想放行「跑一次测试」，写入配置文件的却是「这类命令以后都别再问」；你用某个项目模板建了新仓库，模板里自带的允许规则也跟着继承了；配置文件被提交进版本库，公开代码托管平台上就出现了成片带着自动写入的「放行」条目的仓库，它们正是通过这种方式散落到公开仓库里的。
一个生活化的比方
公司前台的访客登记本。每次有访客，你都跟前台说「这位以后直接放进来」。一年后抽屉里堆了几百张免登记卡，你不记得给过谁，前台也不敢拦。更糟的是，这些卡片还有复印件——配置文件会被提交、被复制、被同事 fork。
为什么叫「漂移」而不是「错误」
因为每一步都是合理的：每一次点「不再询问」都在解决眼前的麻烦。问题出在累积后，整个系统偏离了最初的最小权限原则（principle of least privilege）。而且允许列表通常三个机制全缺：没有过期时间、没有复核环节、没有归属人。
与相邻概念的区别
| 概念 | 关注点 | 典型表现 |
|---|---|---|
| 允许列表漂移 | 授权规则本身的累积与失审 | 配置里越堆越多的「放行」条目，没人说得清哪来的 |
| 权限蔓延（permission creep） | 单个账号的权限越给越大 | 老员工离职时权限比入职时多出一圈 |
| 配置漂移（configuration drift） | 环境与基线逐渐不一致 | 生产机和 IaC 定义对不上 |
三者会叠加：允许列表漂移是权限蔓延在「工具级配置」上的一个具体分支。
对从业者的实际意义
一是把允许规则当代码看待：配置文件变更进 PR，要有人看 diff。二是拒绝宽泛通配，尽量精确到具体命令和具体参数，而不是「这类都行」。三是尽量限定作用域和时效，能只对当前目录、当前会话生效，就别做成全局永久。四是定期盘点：这半年加了多少条、谁加的、还有必要吗。五是别把本地的个人白名单顺手提交到公开仓库，提交前检查一眼。
对普通职场人
同一套逻辑也适用于手机 App 权限、办公 SaaS 的授权弹窗。「始终允许」永远是界面上最贵的那个按钮——它把一次判断换成了永久默认。方便和安全之间的账，单次看不出来，累计才见分晓。