AI智能体把网络攻击周期压缩到数小时：企业安全防线需要怎样调整？

【软盟资讯·新闻导读】多份安全研究资料显示，AI智能体正在把网络攻击中的侦察、凭证搜寻和横向行动压缩到数小时。企业安全体系的重点，也需要从“能否发现”转向“能否在机器速度下及时限制、复核和止损”。

攻击周期被压缩，变化不只是“速度更快”

9月上旬，多家安全媒体援引Unit 42、Google威胁情报组织及相关研究资料，披露了AI智能体参与网络攻击活动的最新观察。其中一项由Unit 42应急响应团队追踪的事件显示，攻击者借助前沿AI模型和定制化代理框架，在不到10小时内完成了原本可能需要人类攻击者约两周才能完成的大量工作。另一份Google威胁情报资料则称，攻击者利用多智能体框架，在不到六小时内窃取了大量账户凭证。

这些信息需要谨慎理解。现有资料并不能证明相关攻击已经完全脱离人类控制，也不能据此推断所有企业都面临同等规模的自动化入侵。但它们共同指向了一个清晰变化：攻击者不再只是把AI当作聊天工具，而是开始让不同智能体承担侦察、信息整理、结果判断和任务衔接等工作。人类负责设定目标和边界，机器则持续执行被分派的战术任务，攻击过程因此获得更高的连续性和响应速度。

过去，安全团队往往根据攻击阶段安排防守节奏。发现异常后，分析人员需要确认告警、调取日志、联系系统负责人，再决定是否冻结账户或隔离主机。如果每个环节都依赖人工排队，数小时的攻击窗口就可能已经足以造成权限扩散、敏感信息暴露或开发流程受影响。

新的风险在于，攻击者可能以更短间隔重复尝试，并根据结果调整后续行动。防守方面对的不是一次静态入侵，而是一个能够持续观察、判断和重新规划的自动化过程。企业原有的“发现—研判—审批—处置”链条，如果仍以较慢的人工作业为中心，就会出现告警已经产生、但处置权限还没有到位的情况。

自动化侦察让企业的暴露面更容易被串联

从公开资料看，相关攻击活动涉及的并不一定是罕见漏洞。Unit 42资料提到，攻击者通过面向公众的服务获得初始进入机会，随后利用自动化侦察智能体梳理内部微服务，并在代码仓库中搜索暴露的令牌和服务密码。资料还提到，攻击者曾试图利用企业代码应用和基础设施配置扩大访问范围，但部分篡改行为受到分支保护机制阻止。

这类风险提醒企业，攻击面并不只存在于互联网入口。公共接口、云资源、代码仓库、持续集成与持续交付流程、基础设施配置，以及AI服务之间的连接，都可能被攻击者放在同一条路径上观察。过去分属不同团队管理的资产，在智能体看来可能只是可以连续尝试的任务节点。

自动化侦察的危险也不在于“看得更快”这么简单。智能体可以把看似零散的信息放在一起：某个服务的访问关系、代码中的配置痕迹、账户权限范围、云资源之间的调用关系，可能被组合成一张更完整的内部路径图。对于企业而言，单个问题未必会立刻造成严重后果，但多个低风险暴露点一旦被串联，整体风险就会迅速上升。

开发团队尤其需要重新审视代码和配置管理。资料中提到，攻击者曾关注代码仓库中的硬编码令牌、服务密码和基础设施配置。即使企业设置了分支保护，能够阻止未经授权的代码修改，也不代表泄露的凭证会自动失效。代码安全、凭证生命周期、构建流程和云权限，不能再被当作彼此独立的治理事项。

攻击编排正在成为新的风险放大器

AI智能体带来的关键变化，是可以把多个工具和任务编排到同一个循环中。根据Unit 42相关资料，调查人员观察到的活动涉及超过50种可映射到MITRE ATT&CK框架的技术。报道强调，真正显著的不同并不一定是出现了全新的攻击方法，而是多个已知环节被更高效地串联起来。

Google威胁情报资料也提到，攻击者使用AI编程聊天机器人、智能体指令和预先配置的操作手册，组装出能够自主运行的攻击框架，部分故障排查和网络地址轮换过程无需人工持续介入。资料同时指出，目前尚未观察到针对实际目标部署的完全自主攻击链条。这一限定很重要，它说明相关能力仍然存在边界，但并不意味着企业可以等待“完全自主攻击”出现后再调整防御。

企业需要关注的是非人身份和自动化工作流的权限。一个由智能体调用的服务账号，如果拥有跨环境访问能力，风险就不再局限于某个单一应用。它可能成为进入代码平台、云资源、数据系统或AI服务的跳板。尤其是长期有效、权限过大的访问凭据，一旦泄露，传统的密码轮换和人工审批可能难以及时跟上攻击节奏。

供应链同样需要纳入检查范围。Google资料提到，攻击者曾在开源软件生态中发布经过篡改的组件，向代码仓库注入恶意内容，并针对AI编程工具可能读取的隐藏项目目录放置凭证窃取程序。对于使用第三方依赖、模型上下文协议服务器或AI编程助手的团队而言，安全审查不能只检查最终代码，也要观察依赖来源、构建过程、开发工具权限和自动生成内容的落地位置。

防守体系要先收紧权限，再提高响应速度

企业不一定需要立刻采购一套全新的安全产品，但需要重新检查自动化系统究竟能做什么、能接触什么，以及在什么情况下必须停下来等待人工确认。

第一项检查是权限隔离。云账户、代码平台、构建服务、数据服务和AI应用应尽量使用用途明确的非人身份，避免多个系统共享一个长期有效的高权限凭据。权限应与具体工作负载和任务范围绑定，能使用短期授权就不要依赖长期密钥，能只读就不要默认授予修改和删除权限。开发、测试和生产环境也应保持清晰边界，避免一次凭证泄露就扩大到多个环境。

权限隔离不能只看账号名称，还要检查实际调用链。一个看似普通的自动化任务，是否能够读取源代码中的敏感配置？是否能够修改构建流程？是否能够访问生产数据？是否可以调用企业内部的AI服务？这些问题需要通过权限清单和实际操作路径核对，而不是只依赖系统默认角色。

第二项检查是日志监测。企业应确保身份登录、凭证使用、代码仓库访问、云资源调用、配置修改、构建任务和AI服务调用都能够留下可关联的记录。单个异常事件可能并不明显，但如果同一身份在短时间内访问多个不相关系统，或者在非正常工作流中读取大量配置、频繁创建任务、改变访问来源，就应被视为需要进一步核查的信号。

日志的价值不只是保存证据，还在于帮助安全团队缩短判断时间。不同系统的记录如果互不连通，分析人员仍然需要手工拼接事件，难以适应机器速度攻击。因此，企业应优先建立关键身份、关键资源和关键操作之间的关联视图，先覆盖高风险链路，再逐步扩大范围，而不是一开始追求收集所有日志。

第三项检查是人工复核。对删除数据、修改生产配置、发布代码、改变访问控制、创建高权限身份和调用敏感AI服务等操作，不应完全交给自动化智能体决定。更合理的方式是建立分级授权：低风险、可回滚的动作可以自动执行；涉及权限扩大、数据外传或生产变更的动作必须暂停并请求人工确认；高风险动作则应由两名或以上具备相应职责的人员复核。

人工复核不等于让所有操作重新回到低效审批。关键在于提前定义哪些动作可以自动化，哪些动作必须留痕、限时和可撤销。只有把边界写进权限策略和工作流，企业才能避免在真正的安全事件发生后临时讨论“谁有权切断系统”。

普通管理者也需要参与防线调整

AI智能体带来的安全问题，不只是安全部门或开发团队的技术问题。管理者需要确认，企业是否清楚掌握了正在使用的AI工具、智能体和自动化服务，以及这些工具能够接触哪些业务数据和系统权限。

很多组织在引入AI应用时，首先关注效率和功能，却没有同步建立退出机制。例如，员工使用AI编程工具时，是否可能把内部代码、密钥或业务数据传入外部服务？自动化客服、知识库和流程机器人是否拥有超出工作需要的读取权限？当供应商服务异常、账号被盗或模型行为偏离预期时，企业是否能够快速停用相关访问？

管理层还需要推动安全、研发、运维和采购团队共同维护一份AI资产清单。清单不必停留在产品名称层面，更应记录每个AI应用的使用场景、数据范围、连接系统、身份类型、审批责任和应急停用方式。没有资产边界，就很难判断一次异常调用究竟是正常自动化，还是攻击者正在借用企业自身的资源。

对于开发团队，最重要的改变是把凭证治理和AI工具治理纳入日常流程；对于安全团队，重点是识别自动化行为之间的关联；对于管理者，则是确保权限、日志和复核要求不会因为追求上线速度而被长期豁免。

【软盟观察】AI智能体正在改变网络攻击的时间尺度，但现阶段更准确的判断不是“人工黑客已经被完全替代”，而是攻击者可以把更多重复性、检索性和协调性的工作交给机器完成。企业面对的核心挑战，也不是简单增加告警数量，而是缩短从异常出现到有效限制之间的距离。权限隔离、短期授权、完整日志和人工复核，听起来并不新，却会在机器速度攻击环境下变得更加基础和关键。值得警惕的是，企业可能在AI应用扩张过程中形成新的非人身份、自动化连接和供应链依赖，却没有同步建立清晰的责任边界。如果这些连接拥有过大权限，即使攻击者没有使用罕见漏洞，也可能通过普通凭证和正常接口逐步扩大影响。企业不应仅根据“是否已经出现完全自主攻击”来决定是否行动，更应围绕可见资产、可控权限、可追溯操作和可撤销流程进行压力测试。对于自动化能力，最稳妥的方向不是一律禁止，也不是完全放任，而是在明确风险等级的前提下，让机器处理低风险重复任务，把涉及权限扩大、生产变更和敏感数据的决定留给经过授权的人。