点了“以后不再询问”，AI 就该一直有权限吗？

AI 智能体 "以后不再询问" 授权：长期权限的范围、时效与撤销机制梳理

点下 "以后不再询问"，并不等于 AI 就该一直、无条件地持有这项权限。一次点击想减少的只是弹窗打断，但系统保存下来的可能是一条长期生效的规则；真正稳妥的长期授权，必须把适用对象、操作范围、有效期限、额度边界和撤销方式讲清楚，并能在任务结束、预算用尽、人员调岗或政策变化后重新判断。近期 Claude Code 的相关调查把这个问题摆到了台面上：选择 "以后不再询问" 后，含密码、API Key 的完整命令会被写进本地配置文件，部分文件随仓库进入公开 GitHub，研究方在公开副本中发现了上千条敏感凭证；需要区分的是，凭据被暴露不等于这些凭据仍然有效或已被利用，事件本身也不需要恶意提示或账号被盗，正常审批流程就可能产生。下面把触发案例、权限分层、治理要求和自查处置步骤拆开梳理。

一、触发案例：Claude Code 配置文件中的敏感凭证

1. 授权是怎么把凭据存下来的

• 开发者让 AI 查询数据库、测试 API 或排查登录失败时，AI 会先准备一条带凭据的 shell 命令（例如 PGPASSWORD=密码 psql ...，或请求头里带 Authorization Token 的 curl），执行前请求授权。
• 选择普通 "允许"，命令只在本次运行；选择 "Yes, and don't ask again"（是的，以后不再询问），这条命令会被保存为长期允许规则，写入项目目录下的 .claude/settings.local.json。
• 保存的可能不是脱敏后的命令模板，而是完整命令，命令里的密码、Token 会原样进入配置文件。

2. 两组调查数据（口径分开看）

暴露凭证类型

• 数据库密码 379 条、Supabase 服务角色密钥 122 条，两类合计约占 Apiiro 样本的 36.3%。
• 云厂商凭证、私有密钥、包仓库 Token、AI 模型 API Key、SSH 登录凭证 43 条（部分涉及 root 账户密码）。
• 样本中包括数据库厂商管理员级云密钥、生产环境 Azure PostgreSQL 密码、Square 生产 Token、病历数据库所有者密码等；Apiiro 称有一家公司确认其暴露的 Key 当时仍在使用。

3. 防护为什么没拦住

• 按官方设计，.claude/settings.local.json 是个人本地配置，本不应提交进版本控制；Claude Code 首次在 Git 仓库内创建该文件时，会把它加入本机全局 Git 忽略规则。
• 但全局忽略规则不随项目走：项目复制到另一台电脑、在原本不是仓库的目录里新建仓库、文件已被 Git 跟踪、或手动创建配置文件时，新环境未必继承这条忽略规则，文件就可能被一起提交。
• 现有扫描工具存在盲区：1,122 个受影响文件中，Gitleaks 标出 564 个、TruffleHog 标出 643 个，两者都漏掉 215 个（约 19.2%）；写在 PGPASSWORD=、sshpass -p 或请求头里的密码，常缺少标准密钥格式，不容易被规则识别。

4. 官方回应与口径边界

• Claude Code 团队负责人在 Hacker News 讨论中回应：承认历史上没有内置敏感信息清理机制，团队正在研究如何避免此类问题；说明该文件本不应进入版本控制系统，创建时会自动加入 Git 忽略规则；建议使用 Auto Mode 减少手动维护允许 / 拒绝规则；同时认可 "敏感命令授权仍可能把内容写入配置" 的反馈，正在考虑改进；基础的 Secret Scanning 能力处于研究和原型验证阶段。
• 早在 2025 年 8 月，就有开发者在 GitHub Issue 中报告过批准命令明文存储凭证的问题，后续因长时间无更新被自动关闭。
• 口径边界：研究呈现的是凭据暴露这一事实，不等于这些凭据都仍然有效，也不等于已经被攻击者利用；整个过程不需要恶意提示注入或账号被盗，一次正常的审批就可能产生留存。

二、一次点击，到底保存了哪几件事

把 "批准这次执行" 保存成 "以后长期允许"，系统实际上替用户完成了一次转换。下面四件事含义不同，需要分别界定边界：

再往上一层，要区分业务权限和委托条件：一个账号 "能调用发券接口"，只说明它具备相应业务权限；"本次活动允许自动发券" 还包含指定门店、金额、时间窗口、总预算和委托范围。账号权限没有失效，不能直接推出这次活动的委托仍然成立。

三、长期授权应该具备的条件

长期授权可以成立，但它应当是一份有条件的委托，而不只是被记住的一次点击。

1. 有效期不必都是固定日期

• 任务完成即结束：一次性排查、迁移、分析任务，做完授权就收回。
• 额度用尽即结束：带预算、配额、调用次数的委托，额度扣完自动停止。
• 条件变化需重新判断：负责人调岗、业务对象变更、组织政策调整后，旧许可需要重新审核。
• 低风险长期重复任务：例如每天生成指定门店的经营摘要，可以持续运行，但范围要明确，且可查看、可修改、可收回。

2. 授权必须可见、可核对

一份清晰的委托记录至少应能回答：

• 当前还有哪些委托处于有效状态；
• 是谁在什么场景下批准的；
• 适用哪些业务、对象和操作；
• 已经消耗了多少额度；
• 出现什么变化时需要人工介入。

3. 撤销要区分三种状态

需要注意：关掉对话窗口不一定取消已排队的任务；删掉一条本地许可，也不一定让另一个执行节点立刻知道；已经发到用户账户里的结果，不会因为授权被撤销就自动消失。"取消后续操作" 不等于 "过去的影响已经全部撤回"。

4. 凭据管理与委托管理分开

• 保护访问凭据，解决的是能力不要落到不该持有的人手里。
• 管理委托条件，解决的是持有能力之后，当前究竟可以做什么。
• 凭据没有泄露，不代表承载的所有旧任务仍然合适；停止一项任务，也不必让整个账号下的其他正常业务一起停摆。

四、行业通行的分层护栏思路

参考编程 Agent 权限体系的常见设计，护栏通常分四层，由浅到深、由软件到操作系统：

风险分级参考：只读文件、本地可逆的编辑和测试脚本，适合作为长期允许；网络出站、依赖安装、Git 强推、批量删除、通配 MCP 工具等，影响范围大或不可逆，应保持询问或直接拒绝。高风险操作在产品设计上就不应提供 "不再询问" 选项。

五、个人与团队自查处置步骤

1. 排查留存

• 检查各活跃仓库的 .claude/settings.local.json、全局 ~/.claude/settings.json 中的允许规则。
• 一并查看共享的 .claude/settings.json、保存的 Agent 对话记录、memory 文件和部署笔记。
• 在 Git 历史记录中搜索该配置文件，避免只看当前工作区。

2. 先轮换凭据，再清理文件

• 发现暴露的密码、API Key、数据库凭证，第一步是撤销并轮换，而不是先删文件。
• 处理仓库历史、Fork 副本和已发布的镜像后，再用 git rm --cached 取消跟踪，并把路径加入项目 .gitignore；打包 Docker 镜像时在 .dockerignore 中排除 .claude/ 目录。

3. 调整命令与规则

• 命令中不写明文密码和 Token，改用环境变量或密钥管理器引用。
• 逐条审视允许规则：问自己 "如果以后都不再询问，我还会批准这条吗"；不会再批准的就删除，删除后只是恢复为再次弹窗。
• 真正认可的长期规则，提升到团队共享设置中评审维护；拒绝清单要覆盖当前技术栈里的高风险操作。
• 把授权审计变成定期动作，而不是一次性检查；发现自己开始不读提示就点同意时，就该重新梳理一遍权限列表。

【常见问题】

问题 1：点了 "以后不再询问"，AI 就等于一直有权限吗？

回答 1：不等于。"以后不再询问" 只是减少重复弹窗，保存下来的授权应当附带明确的操作范围、适用对象、有效期限和额度边界，并且可以被查看、修改和撤销；任务完成、额度用尽、人员或政策变化后，旧授权需要重新判断，不能因为曾经点过 "可以"，就支持未来每一次同类操作。

问题 2：Claude Code 的 "以后不再询问" 为什么会泄露密码和 API Key？

回答 2：选择该选项后，含凭据的完整命令会被写入本地 .claude/settings.local.json 作为长期允许规则，密码、Token 没有被脱敏；当这个本地文件被提交并推送到公开 GitHub 仓库时，敏感凭证就对外暴露。Apiiro 在 10 万余份公开副本中发现 1,122 个文件含真实凭证，GitGuardian 样本中也有上万条被识别出的敏感信息；但暴露不等于全部仍有效或已被利用。

问题 3：已经点过 "以后不再询问"，现在该怎么检查和收回 AI 权限？

回答 3：先排查本地配置文件、Git 历史、Agent 对话记录和共享设置里的允许规则；对暴露的凭据先撤销轮换，再清理仓库历史和公开副本。逐条评估每条长期授权是否仍愿意作为固定政策保留，高风险的网络访问、安装命令、强推和批量删除改为询问或拒绝；长期有效的规则要写进可评审的团队设置，并定期复核。

问题 4：长期授权在企业场景下需要满足哪些治理要求？

回答 4：企业需要能看清当前有哪些委托有效、谁批准、适用什么业务、已耗多少额度、何时需要介入；执行时按当前条件做最终检查，撤销时分别处理未开始、进行中和已生效三类动作；凭据管理和委托条件分开维护，活动结束、预算耗尽或负责人调岗后，旧任务应自动停止或重新审批，而不是带着同一个账号继续运行。

问题 5：哪些 AI 操作不适合设置成 "以后不再询问"？

回答 5：影响范围大或不可逆的操作不适合长期免询问，包括任意网络出站请求、依赖安装脚本、Git 强推、批量删除、通配授权的 MCP 工具，以及涉及生产数据库、密钥和支付接口的命令；这类操作应保持每次确认或直接拒绝，高风险操作在产品层面就不应提供 "不再询问" 选项，只读、本地可逆的测试和编辑才适合作为长期允许。

【参考资料】

• [2026-11-11]（点了 "以后不再询问"，AI 就该一直有权限吗？）腾讯云开发者社区
• [2026-11-11]（点一下「以后不再询问」，密码、API Key 全被上传！Claude Code 配置文件泄露数千条敏感信息，Anthropic 回应）网易（CSDN）
• [2026-11-07]（Claude Code's "Yes, and Don't Ask Again" Option Can Leak Passwords and API Keys to GitHub）Cyber Security News
• [2026-11-07]（Claude Code's "Don't Ask Again" File Exposes Passwords and Keys in 1,122 Public Copies on GitHub）Cybernoz
• [2026-10-14]（Runtime Security）GPTBots.ai 文档
• [2026-08-04]（The 'Always Allow' Trap: Auditing the Permissions You've Granted Your Coding Agent）pearpages

【免责声明】

本文基于公开安全研究、厂商文档与媒体报道整理，调查样本、凭证有效性和扫描覆盖率均对应各自研究时点与方法，不同工具和口径之间不能直接互相替代；文中涉及的配置路径、规则语法和产品功能可能随版本更新变化，具体以各 AI 工具官方文档为准。本文仅作权限治理与安全自查参考，不构成法律结论、安全审计意见或投资建议；涉及企业生产环境的授权调整，请结合内部身份体系、合规政策和专业安全评估后执行。