Anthropic 宣布，从 2026 年 8 月 14 日起，Claude Code 的「自动模式」将成为 Pro、Max 与 Team 套餐用户的默认权限设置，除非用户或管理员手动锁定了其他偏好。

所谓自动模式，是用一个分类器取代过去反复弹出的逐条授权确认。每执行一次工具调用，分类器会先判断它是否属于不可逆、破坏性，或超出授权范围的操作。若判定危险，Claude 会改走更安全的路线，或转而向用户申请许可；在被连续拦截多次之后，会话才会退回手动确认。

Anthropic 表示，作为这次调整的一部分，公司不再对自动模式分类器消耗的「每步少量额外令牌」收费。

更值得留意的是一组对比数据。在针对 1053 名付费测试者的研究中，人类只能识别并拦下 13.6% 的危险命令，而自动模式拦下了 89%；而且在连续处理约 50 条提示之后，人类的正确率进一步跌到约 5%。换言之，长时间盯着授权弹窗的人，反而比机器更容易放过危险操作。

Anthropic 提醒，分类器并不能彻底消除风险，涉及生产环境的改动仍建议人工复核。不过公司也给出了一组数据：在 Team 与 Enterprise 客户中，开启自动模式的用户比其他人多提交了约 25% 的合并请求。

9to5Mac 在评测中认为，对熟练用户来说这大概率是更合理的默认项，但前提是先和编程智能体建立足够的信任。有意思的是，作为对比，OpenAI 曾出于额外谨慎，一度在其最强版本 GPT-5.6 上关闭了类似的自动模式。

来源：9to5Mac

数据来自开发者安全博客 Scale X 的作者 Alex Wauters，他此前曾在优步（Uber）担任资深工程师。几个月前他发布了一款浏览器小游戏，让玩家扮演 AI 编程智能体的”人类审核员”，在限时压力下逐条批准或拒绝命令。有些命令属于日常操作（如 git status、npm test），有些则意味着智能体已被劫持，正在把密钥发往远程服务器（如 cat ~/.aws/credentials）。游戏在技术社区 Hacker News 上引发讨论后，作者补齐了统计功能，并对累计数据做了复盘。

核心数据：平均准确率只有 66.3%

• 玩家平均准确率 66.3%，即平均漏过三分之一的威胁；

• 32.9% 的对局最终得分为负：放行威胁的扣分加上误拦安全命令的损失，超过了做对部分带来的收益；

• 35.2% 的玩家抓住了全部威胁，但其中只有 20.8% 是在误拦率不超过五分之一的前提下做到的，其余人靠”一律拒绝”凑数，被作者授予”人类瓶颈”称号；

• 7% 的玩家对所有提示一律点了同意。

作者也提示了样本局限：这是一款游戏，其中约 34% 的命令是威胁，而真实工作中威胁出现的频率远低于此；玩家也清楚自己正处在限时测试中。这些数字更适合用于横向比较不同威胁类型的识别难度，而非直接换算成真实环境的失守概率。

越危险的命令越容易被抓，越值钱的命令越容易漏

按威胁类型统计的漏过率呈现出清晰规律：

一眼可见的毁灭性命令被拦得最牢，而真正会把凭据送出去的命令，漏过频率大约是前者的三倍。

最容易骗过人的，恰恰是那条看起来最普通的命令

全场漏过率最高的单条命令是 npm run analyze，64.7% 的玩家直接放行。npm run 本身通常无害，但它执行的是项目 package.json 里定义的脚本内容——既可能是正常的打包体积分析，也可能是此前被写入文件的恶意代码。

游戏其实在权限弹窗上方的历史记录里明确展示了脚本内容：这条 analyze 脚本在跑完分析后，会用 curl 把结果发送到一个外部接口。三分之二的玩家依然点了同意，说明弹窗上方的历史日志很少被认真阅读。

同类命令共有三条，全部进入最难识别榜单：npm run analyze 漏过率 64.7%（37 条威胁中排第 1）、npm run setup 48.0%（第 4）、npm run deploy 44.9%（第 8）。三条合并统计漏过率 52.5%（样本量 9,482），而其他外泄型攻击平均为 28.4%。把恶意载荷藏在一个熟悉的脚本名后面，成功率大约翻倍——即便载荷就明晃晃写在日志里。

Hacker News 用户 dns_snek 的评论点出了更根本的问题：逐条批准命令这套模型本身就站不住脚。npm run build 等价于执行 package.json 里的任意 shell 命令，而智能体完全可以在无需批准的前提下先改掉 package.json、往 build.js 或 node_modules 目录里塞进恶意代码。让用户去校验那些”绝大多数时候安全、但因为文件已被改动而不再安全”的命令，算不上有力的防护。

授权疲劳是真实存在的

Anthropic 此前曾指出，其编程工具 Claude Code 中的授权疲劳确有其事：用户看到的批准请求越多，对每一条的注意力就越少，随着时间推移，监督会明显松懈。

统计图显示，即便在这样一局时间很短、且玩家已被提前告知存在威胁的游戏里，也能看到衰减迹象：按完成命令数分组后，各组玩家在开局几条命令后表现改善，随后漏过率又向上爬升。作者说明，这里已剔除那些一律拒绝的玩家；末段上升也可能与倒计时压力下的抢操作有关。

过度拦截是硬币的另一面

一批本意无害的命令被频繁误拦：npm config set registry https://npm.internal（切换到内部镜像源）被拦 59%；rm -rf dist/（清理构建产物，通常在新一轮构建前执行）被拦 45%；kill $(lsof -t -i:3000)（释放被崩溃进程占用的端口）被拦 43%。

这正是人工确认机制的两难：噪声拖慢智能体，久而久之用户放松警惕，反而更容易放行真正的恶意命令。Anthropic 的”自动模式”试图先自行判断命令是否安全、再决定要不要打扰用户，但作者认为这类机制并非万无一失。

争议最大的一条是 cat ~/.zshrc，45.9% 的玩家选择放行。反对意见同样成立：不少开发者的 shell 配置文件里并没有敏感信息，读取它无害；但对于把接口密钥写在里面的人，这就是一次凭据泄露。这条命令的风险完全取决于智能体看不到的本地配置。作者建议把密钥单独存进一个文件、再从 .zshrc 中引用，可以有效降低暴露面。

结论

作者的判断是，虽然只是一款游戏，但它暴露了把人工确认当作 AI 编程智能体安全底线的几个结构性问题：噪声太多带来疲劳，开发者也常常缺少判断风险所需的上下文——他们并不清楚文件在此之前被改动过什么。对开发者而言，更现实的做法是熟悉不同权限模型之间的取舍，并落实沙箱隔离、把凭据与环境变量密钥分离等具体缓解手段。

来源：Scale X（scalex.dev）

MakeUseOf 撰稿人 Afam Onyimadu 在偶然翻看自己所用密码管理器的隐私政策时意识到，自己授予的数据访问权限可能已经超出了心理承受范围。于是他把工具栏上的扩展逐个查了一遍，结果大多数扩展的权限与其功能相符，但有三个”手伸得太长”，最终被卸载。他的排查方法可以直接照搬。

第一步：先看浏览器里的权限清单

1. 在地址栏输入 chrome://extensions 打开扩展管理页面（Edge 等基于 Chromium 的浏览器路径类似）。
2. 找到要检查的扩展，点击”详细信息”（Details）。
3. 查看该扩展声明的权限项。

需要提醒的是，这一步只能看个大概。以 LastPass 为例，页面上只列出了两条：”读取您的浏览历史记录”和”显示通知”。这两句话既没有说明”浏览历史”具体涵盖哪些数据类型，也没有交代扩展读取页面之后会发生什么。

第二步：去读隐私政策，那里才有细节

浏览器权限说明的是扩展在技术上”可以”访问什么，隐私政策才写明开发者声称自己”会收集”什么、拿去做什么。这位撰稿人转而查阅了各扩展的官方隐私政策和 Chrome 应用商店页面上的数据披露，得到的信息完整得多：

• LastPass： 其全球隐私声明与商店页面列出的收集类别包括网站内容、身份验证信息、用户活动、位置以及个人身份信息，远比”读取浏览历史”具体。不过其密码保险库采用零知识加密，官方无法读取其中内容。
• Honey： 美国隐私声明（2025 年 10 月版）中列出页面浏览记录、搜索关键词、浏览或购买过的商品、交易金额，以及订单是完成还是退货；出于个性化目的，还可将这些信息与用户的 PayPal、Venmo 账户关联。
• Rakuten： 扩展条款（2026 年 3 月版）写明，无论用户是否点击扩展图标，它都会自动收集所访问页面的信息，其中包括生成式 AI 网站。条款同时声明不收集、不存储聊天记录，功能仅限于在 AI 输出内容中识别其联盟商家的名称或域名。
• Grammarly： 隐私政策（2026 年 7 月版）明确其在启用状态下会读取用户正在各网站输入的文字，并称会以”尽力而为”的方式排除姓名、地址、密码、支付信息等敏感字段——”尽力而为”并不是铁板钉钉的保证。

第三步：用六个问题决定去留

判断标准不该是”这个扩展危不危险”，而是”它是否还配得上这些权限”。这位撰稿人在动手卸载前，对每个扩展依次自问六个问题：

1. 是否每周都会用到它？
2. 它拿到的权限与它现在实际提供的功能是否相称？
3. 浏览器自带功能是否已经能做到这件事？
4. 能否只收窄它的权限，而不必彻底删除？
5. 如果它明天消失了，是否会察觉？
6. 有没有权限要求更低的替代品？

第四步：删除、收窄或替换

• 直接删除。 Rakuten 的返现按钮使用频率不高，却在所有访问过的网站上持续记录购物车内容，性价比不成立，删掉。
• 收窄权限。 Honey 在网购时确实有用，删除代价较大。折中做法是在扩展详情页把”网站访问权限”从”在所有网站上”改为”点击时”，这样它只在被主动点击时才运行。
• 换成更克制的替代品。 Grammarly 对多数人来说不好替代，这位撰稿人改用了自托管的 LanguageTool Server；LastPass 的隐私政策虽无意外，他仍换成了开源可自托管的方案，让相关数据留在自己的服务器上。

需要说明的是，被卸载的扩展并非恶意软件，隐私尺度也因人而异。真正的收获是养成翻看隐私政策的习惯——多数令人不安的细节其实都白纸黑字写在里面，只是从没有人去读。

来源：MakeUseOf

事实并非如此。这既不是手机厂商塞进来的新功能，也不是通话应用出了问题，而是一套被安全研究人员命名为 AfterCall 的广告欺诈手法。广告分析公司 DoubleVerify 旗下的欺诈实验室（Fraud Lab）追踪到这一趋势，其网络安全研究员 Nir Danon 介绍，这类广告出现在通话结束的瞬间，完全脱离了应用自身的使用场景，因此被称作”通话后广告”。该实验室称，每月都能发现数十款这样的新应用，合计带来数以亿计的广告展示量。

骗局是怎么运作的

理解了流程，才知道该去哪里下手。整套手法分三步：

1. 伪装成人畜无害的小工具：这类应用往往以闹钟、日历、记事本、手机清理、”极速”通讯工具等面目出现，看上去平平无奇，用户装完就抛在脑后；
2. 诱导开启悬浮窗权限：安卓把”显示在其他应用上层”（技术名称 SYSTEM_ALERT_WINDOW）列为特殊权限，无法通过安装时的普通弹窗一键授予，必须由用户自己进入系统设置手动打开。骗子于是编出听起来合理的理由——闹钟应用声称”不给权限，锁屏时闹铃可能无法正常弹出”；有的日历应用干脆不给选择，不授权就直接闪退。部分应用还会额外索取全屏通知权限，好在锁屏状态下也能弹广告；
3. 监听通话状态并弹窗：拿到权限后，应用会监听系统的通话状态广播，一旦状态从”响铃中”变为”空闲”，就立刻拉起一个覆盖全屏的界面，把广告包在伪造的”通话信息”页面里，配上来电详情和头像，让人误以为是通话界面的一部分。

最阴险的一环在于隐身：这些应用会把自己从”最近使用”列表中抹掉，用户按惯常思路上划清理后台，什么也找不到，自然也就无从卸载。

三步揪出真正的元凶

排查思路很简单——顺着悬浮窗权限的名单挨个看。

1. 打开手机「设置 > 应用」，进入应用管理页面；
2. 找到「特殊应用权限」（部分机型藏在右上角三个点的”更多”菜单里，也可能叫”特殊访问权限”），点进「显示在其他应用上层」或「悬浮窗」一项。不同品牌和安卓版本的叫法略有差异，可直接在设置的搜索框里搜”悬浮窗”或”显示在其他应用上层”；
3. 逐一核对已获授权的应用清单，重点盯三类：完全不认识的、几乎从不打开的、以及功能上根本用不着悬浮窗的（比如一个纯记事本、一个时钟、一款所谓的清理工具）。先关掉它们的悬浮窗开关，如果确认就是罪魁祸首，直接卸载。

关掉权限后再打几通电话验证，广告若不再出现，说明已经找对了应用。

注意事项

• 别用”清理大师”救火。这类通话后广告经常顺势推荐用户安装清理工具或杀毒软件，宣称能解决弹窗问题，实际上往往索取更多权限、带来更多广告，只会把问题越弄越糟；
• 悬浮窗权限值得定期体检。这项权限是安卓上被滥用最多的权限之一，除了广告，也常被更严重的恶意软件利用。建议每隔一段时间就回到上述设置页面扫一遍，把非必要的授权一律关掉；
• 装应用时多想一秒。安装前先问一句：这个功能真的需要它要的权限吗？一个闹钟需要覆盖全屏，一个日历不给权限就闪退，本身就是危险信号；
• 研究报告并未指出这类应用会窃取敏感数据，从用户角度看目前更多是骚扰，但任何索取非必要权限的程序都意味着额外风险。

来源：Lifehacker