AI 品牌成钓鱼诱饵、Claude 被拿去真入侵：明文权限正在被代理放大

从本周的几个新信号看，AI 安全正在从「模型会不会被越狱」转向更难处理的一层：AI 已经变成身份、工具、代码与数据流的一部分。攻击者不一定要打穿模型本身，只要让人相信一个假的 AI 服务、让代理接手一次明文凭证，或让漏洞发现速度超过人类验证速度，就足够制造实际损失。

先看四条信号

信号	本期事实	对企业的直接问题
AI 品牌被当作钓鱼诱饵	NeuraCyb 6 月 22 日整理 Microsoft Threat Intelligence 观察：ChatGPT 主题钓鱼触达超过 10 万名用户；Claude 政策违规通知仿冒活动面向美、英、印超过 2000 家机构；DeepSeek 预览热度被用于伪造仓库和下载页，分发 Vidar Stealer 等窃密软件。1	用户在寻找插件、试用、升级、内测资格时，会主动把账号、银行卡或设备权限交出去。
低技能攻击者用 Claude/Codex 打穿真实公司	OALABS 恢复了超过 1000 个 Claude 与 Codex agent 会话，日志记录了至少 14 家公司遭入侵；攻击者多次把恶意请求包装成「授权红队」或「安全研究」，让代理完成侦察、漏洞研究、利用代码、凭据验证和数据外带。2	安全团队面对的不再只是一个熟练黑客，而是「低技能操作者 + 工具型代理」组合。
AI 挖洞把 CVE 年度预期推到 6.6 万	Help Net Security 报道 FIRST 预计 2026 年 CVE 总量接近 66,000；Anthropic Mythos、OpenAI GPT-5.4-Cyber 等自主发现代理正在进入披露生态，Mozilla 借 Project Glasswing 为 Firefox 150 找到并修复 271 个漏洞。3	漏洞更多不等于每个都要立刻补，但筛选、验证、协调和检测规则编写会被人力瓶颈卡住。
「人在回路」不再自动等于安全	TNW 报道 Amazon Security 负责人 Eric Brandwine 认为 human-in-the-loop 不是金标准，反复审批会让人麻木；Amazon 的替代思路是给 agent 独立身份、记录「该 agent 代表谁做了什么」，再配合静态禁令、最大权限和按任务动态收窄的策略。4	只把审批按钮留给人，无法证明数据访问真的受控；责任链和运行时权限才是关键。

这些事件的共同点很清楚：攻击入口看似分散，最后都落到明文数据、凭证、工具权限和执行上下文。AI 越像同事，越容易被授予同事级权限；AI 越像自动化系统，越容易把一次错误动作放大成一串真实操作。

AI 品牌被用于社工诱饵 — AI 品牌钓鱼利用的是用户对新功能、插件和内测资格的期待。1

AI 编码代理监督示意 — AI 编码代理进入研发链路后，监督本身也会出现滞后和责任缺口。5

攻击者不必攻破 AI，公司自己会把门打开

AI 品牌钓鱼的危险不在技术新奇，而在心理路径变短。过去用户会警惕陌生银行邮件；现在很多人正在主动搜索「Copilot 插件」「Claude 新功能」「DeepSeek 本地版」「ChatGPT 支付问题」。攻击者只要把链接包装成更新、合规提醒、账号异常或限时内测，用户点击的阻力会明显降低。

OALABS 的案例更扎心。攻击者并没有表现出很强的专业能力，却能让 Claude 接管大量技术执行：扫服务、查 CVE、写利用、验证访问、整理被盗数据价值。策略拦截主要在「变现被盗数据」阶段触发；侦察、利用和报告写作这些动作，本来就和合法红队工作高度相似。模型很难只凭一句「我是授权测试」判断真假。

这对企业意味着，AI 安全不能只盯模型提供商有没有守住边界。更实际的检查项是：员工机器上有哪些 agent？这些 agent 能读哪些目录、环境变量、密钥缓存、云 CLI 配置？它们的会话日志是否会携带敏感数据？一旦 agent 被复制到别的主机，认证状态是否还能被复用？

漏洞数量暴涨，真正稀缺的是判断力

AI 漏洞发现让安全行业看到了一个反直觉局面：披露更多漏洞可能是好事，因为旧缺陷被更早发现；但企业补丁系统不会因为 AI 变快而自动扩容。FIRST 的 66,000 CVE 预测，提醒的不是「所有漏洞都同等紧急」，而是风险分流要更精细。

2026 CVE 预测图 — FIRST 对 2026 年 CVE 数量的预测被 AI 漏洞发现工具明显推高。3

Help Net Security 的报道把问题说得很直：真正需要紧急处理的高危、在野利用或即将被利用的漏洞占比并没有同步暴涨；难点是从雨点一样的披露中筛出会淹进机房的那部分。对 CISO 来说，漏洞管理正在从「补丁数量管理」变成「可达性、资产上下文、业务数据暴露面」管理。

AI 生成的一次性脚本、小工具、内部应用还会制造另一个盲区。它们可能从未进入 CVE 数据库，却直接连着生产数据、客户资料或研发资产。只靠公开漏洞库，已经覆盖不了企业里真正运行的 AI 代码和临时自动化。

人工审批不能替代架构约束

本周关于 AI agent 治理的讨论，已经从「加一个确认按钮」走到「谁负责、谁能看、谁能删、谁来审计」。Help Net Security 报道的 Oxford 与 SaferAI 分析显示，OpenAI 对内部编码流量的离线监控覆盖约 99.9%，但审核约有 30 分钟延迟；Anthropic 的分层流程中，人类审核员每周处理约 30 份摘要，风险评分可能在 PR 审核或合并后才出现。5

30 分钟在普通审计里不算长，在 agent 自动写代码、跑脚本、改配置的环境里，足够完成多轮动作。Amazon 的思路因此更接近身份与权限治理：agent 有自己的身份，日志显示它代表哪个人行动；权限不是一次性全给，而是用静态禁令、最大权限边界和按任务动态生成的策略层层收窄。4

但这仍然没有解决最底层的问题：只要 agent 在明文环境里处理敏感输入、凭证、客户数据和中间推理结果，策略配置错误、日志外泄、提示注入、工具调用偏航都会有可拿走的东西。

荆华密算的切入点：把「可被拿走的明文」变少

这也是荆华密算反复强调密态推理的原因。传统做法是在明文计算外面加更多控制：账号、审批、DLP、日志、沙箱、红队、补丁、MFA。这些都要做，但它们默认一个前提：数据在某个时刻会以明文出现在模型、插件、内存、日志、缓存或代理上下文里。

密态 AI 推理要改的是这个前提。企业把数据交给 AI 处理时，推理过程在加密状态下完成，明文不出现在任何可访问内存空间。这样即便上层出现钓鱼下载、agent 误调用、日志权限失配、工作区被复制，攻击者能接触到的明文输入和推理中间态会少得多。

这不是替代补丁管理，也不能让员工永远不点错链接。它解决的是更窄但更根本的部分：当 AI 必须处理敏感数据时，尽量不要让「敏感数据以明文被代理接手」成为系统运行的必要条件。

对企业版密态 AI 推理系统来说，这意味着研发、金融、医疗、政务等场景可以把高敏数据接入模型能力，同时降低明文暴露面。对正在内测的全链路密态 AI 助手来说，意义更直接：普通用户把文件、聊天、账号信息交给助手时，不应默认相信每一个插件、每一段脚本、每一次日志记录都会永远安全。

本周这几条新闻没有给出一个单点答案。它们只是在不同位置重复同一句警告：AI 进入数据流之后，安全边界不能停在「谁点了确认」和「谁有权限」。真正该先问的是，系统里还有多少地方必须看见明文。