Appearance
共享自动化的身份与凭证：谁在跑、拿谁的钥匙、炸多大
第二部 · Agent 实践 · 第31章
撰写日期：2026-07-13
结论
团队共用的自动化脚本，最隐蔽的坑不在业务逻辑，在"用谁的身份运行、拿哪一把钥匙"。作者本机测着全对，发给同事整段失效——因为脚本悄悄绑在了作者个人的身份上。
共享自动化的第一个设计问题不是"功能怎么写"，是"它以谁的身份运行"。个人身份的凭证会让作者本机成为唯一能跑的机器，而这是只在交付那一刻才暴露的隐性耦合。
1. 运行身份：用应用 / 租户令牌，别用作者的个人 token
个人 OAuth 出来的 user token，权限和身份都绑运行者本人。脚本一分发，别人没有等价 token，凡是依赖个人身份的调用全报权限错。
| 个人 user token | 应用 / 租户 token | |
|---|---|---|
| 权限绑定 | 运行者本人 | 应用本身，与人解耦 |
| 可分发 | 换机器就失效 | 一次配置、多机可跑 |
| 暴露时点 | 交付给同事时才发现 | —— |
代价是要在平台后台为应用身份单独开对应 scope（比如读群消息的租户级权限）。一个好用的回归验证手段：把 user token 文件指向一个不存在的路径，看脚本是否还能跑通——能跑，才证明它真的不依赖个人身份。
2. 能力敏感度决定凭证隔离粒度
共享 App 的凭证，本质是"谁拿到谁就全都能用"。所以：
- 别往共享 App 上加高敏感的私域权限（读个人邮箱、下私人发票）。加一个，等于让所有能碰到这套凭证的进程 / 人都潜在可及这项能力。
- 高敏感能力应当另建一个"可用范围仅本人"的独立应用，与团队共享自动化彻底隔离。
一句话：能力的敏感度，必须和承载它的凭证的可见域匹配。
3. 前端永不持有长期令牌
给"仅本人可用"的管理后台做鉴权，把爆炸半径压到最小：
| 措施 | 作用 |
|---|---|
| 细粒度、安装范围限单一资源、默认短时过期的应用令牌 + PKCE | 令牌就算泄露，也只影响单仓库 + 数小时 |
| 密钥只进服务端加密存储，浏览器只持 HttpOnly 会话 ID | 前端零长期凭证，XSS 偷不到整账户权限 |
| 登录后按身份白名单二次校验，非白名单立即清会话 | 拿到身份不等于放行 |
把个人长期 token 放进浏览器，等于把整账户权限交给前端脚本。
4. Scope 的最后一公里
两个只在真接的时候才踩到的隐性事实：
- OAuth scope 是自由字符串，猜出来的会被平台判无效。 把某个写权限想当然写成
xxx:write，平台可能直接报"无效权限标识"——正确标识得查官方真值（很多"读写合一"的 scope 本身就含写，不需要另加:write）。 - 改代码 / 改申请清单，不会自动升级已经签发的旧令牌。 令牌在签发那一刻就冻结了当时的 scope 集合；改了申请范围，必须重新走一次授权流程才生效。
5. 密钥落地纪律
| 纪律 | 说明 |
|---|---|
| 密钥只进本机 600 权限、且被 gitignore 的 env 文件 | 不入库、不打包、不进日志 |
| 密钥一旦出现在对话 / 截图里，即视为泄露 | 应立即在平台侧重置，而不是"应该没人看到" |
| 自建协作服务发号，首日就把安全基线做进登录流程 | 首次登录强制改初始密码 + 强制开启二次验证，而不是发一封"建议开启"的邮件 |
初始密码等于邮箱这类弱默认，只有配合强制门才安全；上线首日流量最大、也最容易被顺手跳过安全步骤。
我的判断
设计共享自动化时，我现在先问三个问题，再问功能：它以谁的身份跑？这把钥匙谁能拿到、能碰多大范围？钥匙漏了，炸多大？ 身份用应用级、能力按敏感度隔离、前端零长期凭证、密钥落本机——把爆炸半径设计在前面，比出事后补要便宜得多。