2026.09.23
32
报告中的攻击仍依赖暴露服务、失窃凭据、未修复组件和薄弱配置。变化发生在这些入口之后:AI协助理解系统输出、组织后续任务、调用工具并保存进展,使操作者更容易管理多个目标和环境。这可能降低任务衔接成本。
一个具体案例显示,操作者在约34小时内完成涉及2,100余组身份令牌、40余个企业租户的会话存储转储。这个数字不能作为普遍攻击速度,却足以提醒企业:身份失陷到下游扩展之间的处置窗口可能很短。
真正影响风险的,是攻击者能够取得什么身份、进入哪个环境、接触什么数据,以及在被发现前完成多少有效动作。模型能力、编排效率与执行权限共同决定工作流的可达范围,可靠的权限边界能够限制后续扩展。
自治程度与损害程度应分别判断。报告指出,人仍参与目标选择和结果审查,部分严重入侵由人逐步指挥。企业应优先保护高价值身份和敏感数据路径,持续做好补丁、隔离与访问控制,避免用智能体数量或生成代码量代替风险评估。
把AI凭据视为生产资产
AI访问凭据具有三重价值:可以转售的资产、由受害者承担费用的运行资源,以及将活动关联到合法账号的身份掩护。报告描述,一些操作者取得受害环境中的AI密钥后,将后续任务转移到这些密钥上运行。一次泄露因而可能同时带来费用损失、数据暴露和身份被二次滥用,并为后续活动提供资源。
发现费用异常后,还应检查调用工作负载、凭据可访问范围、异常工具执行及新增会话或授权。账单只是线索之一;没有明显超额,也不能排除凭据被低速、分散使用。
每个AI工作负载应有可识别的身份、责任人、用途和权限范围。在平台支持时,优先采用短期凭据、受限角色与任务级授权,减少长期密钥跨环境流转。
报告提醒,驻留的窃密组件可能继续收集轮换后的新凭据。因此,换密钥应与终端清理、会话撤销及派生授权检查联动,切断持续泄露路径。

把提示注入防线落实到执行授权
报告披露,一家AI企业的自动化评估沙箱受到恶意指令影响,泄露了该环境持有的生产API密钥。操作者随后利用客户侧密钥继续活动,并在约四天内向约30家AI企业发起类似攻击尝试,目标数不代表成功攻陷数。报告明确,Anthropic自身系统未被侵入。
这个案例揭示了关键问题:当低信任内容能够影响工具行为,而执行环境又持有高价值秘密时,内容处理功能可能成为越权入口。文档、网页、代码仓库和工具返回都可能包含不可信内容。模型建议调用工具,并不等于该调用已获得业务许可。
企业应隔离内容处理环境与生产秘密,由独立机制检查工具调用的身份、对象、参数和用途,并限制可访问资源及网络出口。敏感写入、权限变更和外部传输应有相应授权与可追溯记录;连接器和工具协议也应纳入控制链。
验证时,应在授权测试环境中,观察不可信指令能否诱发越权读取、执行或传输,同时检查合法任务是否仍能完成。这样检验的是执行边界,而非模型的表面回应。
识别交互数据的额外流转与二次使用
蒸馏是一种模型训练方法,本身并不要求使用真实用户的敏感信息。企业更应关注交互是否进入未预期的接收方、是否被改作其他用途。Anthropic明确指称,部分用户会话被送入Claude,涉及个人信息、药企内部资本支出预测,以及开发者配置中的服务令牌和应用密钥。
报告描述了三种应分别理解的路径。实时转发是将部分当前请求交由Claude处理,再向用户返回回答,这会改变实际模型处理方。事后重放是先保存用户与原模型的交互,再发给Claude用于生成、整理或评估服务商自己的训练材料;报告明确说,其中一个案例未显示直接以Claude回答服务当时的用户。留存转售则发生在中间路由服务:交互记录被保存并交易给第三方,成为其他训练流程的输入。这三种模式不能合并成“所有产品都在实时调用Claude”。
可以得出的准确结论是:报告所述用户内容进入了额外接收方的处理范围。原文对告知状态使用了不同强度的表述,其中一处明确表示不知道客户是否已被通知。公开材料不足以核验全部授权记录、留存期限和最终训练去向,不能据此认定全面未经授权的泄露,也不能推断Anthropic将收到的内容用于训练Claude。
获准为当前任务进行推理,不应被默认解释为同时获准转售交互、交由新的接收方处理,或用于其他训练目的。个人数据应核对处理依据与声明目的;企业文档、源代码和业务秘密还应核对数据所有者授权及合同约定。

明确AI供应链中的共享责任
企业采购的AI能力可能经过模型服务、请求转发网关、应用编排、连接器与终端客户端。报告中的恶意转售案例表明,界面宣称的模型与实际请求去向可能不同,不可信客户端还可能成为凭据泄露入口。这说明企业需要掌握真实的数据和身份流向。
AICM v1.1区分模型、云服务、编排服务、应用提供商与企业客户五类参与者;CSA的组织责任研究也强调明确责任、持续监测和可验证证据。具体分工仍须结合部署架构核验。
供应链审查应明确谁接收请求、保留交互、更换上游模型、持有密钥、批准动作,以及事件发生时谁能撤销哪些访问。高敏感业务需要配置、日志和合同安排相互印证。
企业侧网关日志通常只能证明请求发往哪个入口。服务方后端继续转发或事后重放,可能超出本地监测范围。因此,还需核对供应商披露、上游处理方、用途约定与审计证据;仅有第一跳网络记录,不能证明后续没有转发。
数据流图还应覆盖检索索引、缓存、日志、长期记忆与导出文件,验证删除对话是否同步清除相关副本。审计日志也应脱敏、限制访问并设置保留期限。各方应明确自己维护的边界、保留的证据和共同遏制异常的方式。
将AICM控制项落实为验证证据
CSA AICM v1.1及其AI客户实施指南提供了可核对的控制项。下表选取与本文案例直接相关的项目;右栏为企业验证建议,不构成完整符合性评价。适用性与责任划分仍需结合部署判断。

应区分处理方披露与在适用条件下取得同意或批准,并核对法律和合同要求。供应商无法提供证据的环节,应记录可见性缺口及残余风险,不能仅凭填写清单认定控制有效。
用业务结果检验治理效果
拒绝请求、封禁账号或暂停集成,都是可以记录的处置。报告描述,云端服务参与软件开发,产物随后在本地运行;停用账号可以中断后续支持,却不能自动停止已部署系统。企业撤销AI接入时,也应调查已导出的代码、数据和授权是否仍在发挥作用。
治理效果应沿实际事件链确认:越权动作是否被阻止,凭据和会话是否失效,环境是否恢复,以及相同行为是否换身份再次出现。每一项都需要证据。报告还显示,直接恶意请求与拆分后的小型工程任务,其拒绝表现可能不同,因此单轮拒绝率不能代表工作流阻断率。
企业可跟踪有效暴露时长、凭据撤销完整性、越权动作阻断情况和合法业务完成率。指标应说明观察范围与未知项:无法识别全部受影响会话,就不能声称完全撤销。

将安全控制嵌入部署与运营
企业可以先选择一条高权限或涉及敏感数据的工作流,梳理入口内容、智能体身份、工具与业务系统,明确授权主体、外部动作及停止和恢复机制,再逐步扩大覆盖。
部署前验证隔离、授权和日志关联,运行中联动调查AI调用、身份、终端和数据活动。人工审批应呈现执行对象、权限、数据去向及后果,把判断集中于异常、越界和影响较大的动作。
持续演练应检查恶意内容能否跨越权限边界、撤销凭据后旧会话是否失效,以及中止智能体后遗留任务是否继续运行,并记录恢复时间和业务影响。AICM的实际价值,在于将风险判断落实为系统设置、责任人和可验证结果。
参考文献
[1] Anthropic. Detecting and countering misuse of AI: September 2026. Published September 10, 2026. 文内页码对应原报告PDF。
[2] Cloud Security Alliance. AI Controls Matrix v1.1. June 22, 2026.
[3] Cloud Security Alliance. AI Organizational Responsibilities: Core Security Responsibilities. May 5, 2024.
[4] Cloud Security Alliance. AICMv1.1 Implementation Guidelines for AI Customers (AIC). June 22, 2026.