AI滥用进入工作流时代 企业安全如何应对
当AI开始连接企业知识库、开发环境、云服务与业务系统，安全管理需要回答一个更具体的问题：谁能通过AI，让哪个系统执行什么动作？Anthropic于2026年9月10日发布的威胁报告，为这一问题提供了来自实际调查的观察。值得企业重视的变化，是攻击者将模型、工具、身份和反馈连接起来，使跨环境操作更容易被重复执行，AI服务本身也成为攻击目标和可盗用资源。从云安全与AI治理的研究视角看，企业需要以完整工作流为防御单元，将身份授权、数据流向与责任归属纳入同一控制体系。
原报告覆盖七类滥用场景。本文选择其中与企业云环境、身份、应用集成及治理直接相关的技术案例，从云安全与AI治理视角讨论可落实的防御。报告披露的是经过选择的显著案例，能够帮助识别机制，但不宜用来推算所有企业的受攻击概率或AI带来的统一增益倍数。
以工作流为单位理解攻击
报告中的攻击仍大量依赖熟悉的入口：暴露的服务、失窃凭据、未修复组件和薄弱的应用配置。变化发生在这些入口之后。AI能够协助理解不同系统的输出，组织后续任务，调用工具并保存进展，让一名操作者更容易管理多个目标、多个环境和多条工作线。重复性劳动与任务衔接成本下降，原本不值得投入大量人工的目标，也可能进入攻击者的经济可行范围。
一个具体案例显示，操作者在约34小时内完成涉及2,100余组身份令牌、40余个企业租户的会话存储转储。这个数字不能作为普遍攻击速度，却足以提醒企业：身份失陷到下游扩展之间的处置窗口可能很短。
这意味着，企业不宜只围绕“AI能否生成恶意代码”安排防御。真正影响风险的是攻击者能够拿到什么身份、进入哪个环境、接触什么数据，以及在异常被发现之前还能完成多少有效动作。模型能力、编排效率与执行权限共同决定工作流的可达范围；其中任何一道可靠边界，都可能限制后续扩展。
同样需要保持清醒：自治程度与损害程度是两个维度。报告指出，人仍参与目标选择和结果审查，部分严重入侵由人逐步指挥。企业因此应优先保护高价值身份和敏感数据路径，衡量风险时减少对代理数量、调用次数或生成代码量的依赖。熟悉的补丁、身份治理、网络隔离与数据保护工作，在AI时代依然直接影响攻击成本。
图1 智能体工作流的权限边界
把AI凭据视为生产资产
AI访问凭据具有三重价值：可以转售的资产、由受害者承担费用的运行资源，以及将活动关联到合法账号的身份掩护。报告描述，一些操作者取得受害环境中的AI密钥后，将后续任务转移到这些密钥上运行。一次泄露因而可能同时带来费用损失、数据暴露和身份被二次滥用，并为后续活动提供资源。
这种资源循环值得进入企业事件响应模型。发现费用异常时，调查不能停在确认超额调用；还应检查调用来自哪个工作负载、凭据能够访问哪些服务、是否发生了异常工具执行，以及是否生成新的会话或授权。账单是线索之一，未出现明显账单异常也不能排除凭据在低速、分散使用。
治理的起点，是让每个AI工作负载具有可识别的身份、责任人、用途和权限范围。在平台支持的条件下，优先采用短期凭据、受限角色与任务级授权，减少个人长期密钥在开发、测试和生产之间流转。预算及调用配额有助于限制资源滥用，但不能替代数据访问控制。
报告还提醒，驻留的窃密组件可能继续收集轮换后的新凭据。因此，换密钥应与终端清理、会话撤销及派生授权检查联动。否则，企业完成了一次凭据更新，却没有切断泄露路径。
图2 AI凭据泄露会扩大业务风险
把提示注入防线落实到执行授权
报告披露，一家AI企业的自动化评估沙箱受到恶意指令影响，泄露了该环境持有的生产API密钥。操作者随后使用这些客户侧密钥继续开展活动。同一操作者随后在约四天内向约30家AI企业发起类似攻击尝试；这些目标数不代表成功攻陷数。这个案例揭示了明确的工程问题：当低信任内容能够影响工具行为，而执行环境同时持有高价值秘密时，内容处理功能可能变成跨越权限边界的入口。报告同时明确，泄露的是客户环境中的密钥，攻击者未侵入Anthropic自身系统。
对企业而言，知识库文档、网页、工单、代码仓库与工具返回都可能包含不可信内容。给模型增加“不要执行外部指令”的要求具有辅助价值，但真正的授权决定应由独立机制执行。模型建议调用工具，并不等于该调用已获得业务许可；能够读取某份文档，也不应自动获得修改生产系统或向外部发送资料的权限。
可实施的设计，是把内容处理环境与生产秘密隔离，由权限网关检查每次工具调用的身份、对象、参数和用途，并限制可访问资源及网络出口。敏感写入、权限变更和外部传输应具备更强授权与可追溯记录。连接器和工具协议需要纳入这条控制链；采用某一框架或协议，并不会自动形成安全边界。
验证时，应在授权测试环境中构造来自文档或工具结果的不可信指令，观察能否诱发越权读取、执行或传输，同时检查合法任务是否仍能完成。这样测量的是实际边界，而非模型对测试文本的表面回应。
明确AI供应链中的共享责任
企业采购的AI能力往往经过模型服务、代理网关、应用编排、工具连接器与终端客户端等多个环节。报告中的恶意转售案例表明，界面宣称的模型与实际请求去向可能不同；不可信客户端还可能成为凭据泄露入口。该观察不能推广为所有第三方服务都有问题，却说明企业需要掌握真实的数据和身份流向。
CSA于2026年6月22日发布的AI Controls Matrix v1.1区分模型、云服务、编排服务、应用提供商与企业客户五类参与者。其组织责任研究也强调明确责任、持续监测和可验证证据。这为跨团队治理提供了共同语言，具体责任仍须结合部署架构核验。
供应链审查因此应从产品清单进一步走向关系清单：谁接收请求，谁保留输入与输出，谁能够更换上游模型，谁持有调用密钥，谁批准工具动作，以及事件发生时谁能撤销哪些访问。对于高敏感业务，这些问题需要配置、日志和合同安排相互印证，不能只依赖产品名称或采购页面。
对于客户资料、源代码和业务文档，数据流图还应覆盖检索索引、缓存、日志、长期记忆与导出文件。删除对话是否同步清除相关副本，需要实际验证。审计日志本身也可能包含敏感信息，应采取必要的脱敏、访问限制与保留期限，避免为调查建立的新数据集合成为额外暴露面。
共享责任也应沿交接点划分。模型服务的安全机制、应用侧的提示与编排、云环境的隔离、企业身份授权和终端管理各有作用。采购外部服务并不会转移本组织全部责任；自行部署也不意味着供应商与组件风险自然消失。有效协作要让各方知道自己维护哪一道边界、保留什么证据，以及发生异常后如何共同遏制。
这也为企业采用统一的AI控制框架提供了实际价值：让采购、研发、安全、法务和业务人员能够围绕相同对象讨论风险，并将框架要求映射为系统设置、责任人和验证记录，避免制度与运行状态脱节。
用业务结果检验治理效果
模型拒绝了一条请求、平台封禁了一个账号、企业暂停了一项集成，都是可以记录的处置，但它们回答的问题不同。报告明确描述了这样的情形：云端服务参与软件开发，产物随后在本地运行；停用相关账号可以中断后续支持，却不能自动停止已部署的系统。企业撤销AI接入时，同样需要调查此前已经导出的代码、数据和授权是否仍在发挥作用。
因此，治理效果应沿实际事件链逐层确认：不当请求是否被限制，越权动作是否被阻止，凭据和会话是否真正失效，受影响环境是否恢复，以及相同行为是否换身份再次出现。每一层都需要相应证据。报告还显示，针对直接恶意请求的拒绝表现，与拆分成较小工程任务后的表现可能不同，说明单轮拒绝率不能代表整个工作流的阻断率。
企业可以重点跟踪有效暴露时长、凭据撤销完整性、授权演练中的越权动作阻断情况，以及合法业务完成率。指标应说明观察范围和未知项：无法识别全部受影响会话时，就不应声称完全撤销；起始入侵时间不清楚时，应分别报告已知活动窗口和估计范围。
安全价值最终体现在敏感访问被限制、损失窗口缩短、复发受到遏制，以及正常业务能够持续。告警变多并不必然代表治理变好；把所有任务都禁用，也无法证明企业获得了可用的安全能力。
图3 从访问封禁到风险消减
将安全控制嵌入上线与运营
企业可以先选择一条高权限或涉及敏感数据的工作流，梳理入口内容、代理身份、工具与业务系统。盘点应明确授权主体、不可信输入、会改变外部状态的动作，以及停止和恢复机制，再逐步扩大覆盖范围。
上线前，研发与安全团队应确认秘密与低信任环境隔离、权限与任务匹配、关键动作具备独立授权，日志能够关联请求与实际执行。运行中，应把AI调用异常与身份、终端、云访问及数据活动联动调查，由业务团队共同确定可接受的自动化范围。
人工审批需要呈现执行对象、权限范围、数据去向和可能后果。预先批准的低风险任务可以在限制明确、行为可追溯的条件下自动完成，将人工判断集中于异常、越界和影响较大的动作。
持续演练应验证恶意内容能否跨越权限边界、撤销凭据后旧会话是否失效，以及中止代理后遗留任务是否继续运行。同时记录恢复时间和业务影响，让问题在扩大部署前暴露。
这份报告对企业的启示，是以工作流识别风险，以身份与权限限制后果，以共享责任连接供应链，以结果证据检验治理。AI应用扩大到哪里，对执行主体、授权依据与恢复机制的掌握就应延伸到哪里。
参考文献
[1] Anthropic. Detecting and countering misuse of AI: September 2026. Published September 10, 2026.
[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.