Google 红队如何应对智能体攻击：从人工演练到自主攻击验证的变化

早些年做红队演练，常规流程是人工找漏洞入口、手动串联权限链路，最后再由安全工程师整理复现方案跟进修复。Google 最近公开聊到智能体安全相关的实践时，点出了一个很实际的变化：AI 不单单能帮防守侧提升效率，也可能被攻击者用来自动执行一连串连贯的攻击动作。对安全团队来说，没必要去追什么性能拉满的“最强攻击智能体”，核心是把原本单次的人工演练，改成一套可重复跑、支持回归校验的标准化验证流程。

Google 这次讨论的变化，究竟落在哪一层

Google 的安全团队把红队的核心任务概括为提前应对真实攻击者可能采用的新手段。变化在于，攻击者拿到新的AI工具后，攻击动作可能不再是单次命令、单次请求，而是交给智能体在多个步骤之间自主判断、持续执行。与此同时，防守方也能用 AI 做更快的日志检索、异常分析和测试验证。

这也不是说“人工红队就没用了”。人工判断仍然要负责确认攻击的实际影响、作用边界和业务层面的语义逻辑；真正需要升级的是验证的对象：从单个漏洞能不能利用，扩展到一条带身份、带工具调用、带数据访问权限的完整路径能不能被全程走通。

先把人工演练改成一条可复现路径

在测试环境里，先不要让智能体直接触碰生产账号。提前准备好一组脱敏的模拟资产：一个普通用户账号、一个低权限服务账号、一个模拟内部API服务，以及一份完全不含真实个人信息的测试数据集。智能体的每个动作都要记录请求时间、调用工具、当前持有的权限和返回结果。

下面这张表可以用来排查一次演练是不是还停留在“只看到了告警提示”的浅层次。

智能体验证最容易漏掉的三个边界

连续动作不等于连续授权

智能体可以连续发起动作请求，不代表它可以连续自动拿到更高权限。每次操作要跨账户、跨工具或者跨数据域的时候，都要重新做授权校验。把一整条长链路拆成多个短会话，反而更容易定位到底是哪一步出了越权问题。

能复现不等于能证明影响

单条异常输出只能说明系统当前行为值得进一步排查。要确认实际影响，还要同步记录被访问的对象、实际拿到的权限和对应的业务后果。测试产生的数据要支持一键撤销，留存的证据要脱离智能体的自然语言解释也能单独复核。

自动化不等于可以取消停止条件

智能体一旦进入循环执行状态，最先要处理的不是给它开放更大的工具权限，而是先明确资源配额、时间上限和人工确认节点。出现异常数据访问、意外权限升级或者动作明显偏离预期时，先暂停整条链路，再慢慢排查原因。

用四段闭环验收一次防守改动

修复完成后，按“发现—复现—修复—回归”的顺序重新完整走一遍流程。这里不要只跑之前测过的原始案例：至少要补测一条相邻路径，比如用同一个身份换另一个工具尝试，或者用同一个工具换另一个数据对象尝试。这样才能判断你修复的是根因，还是只挡住了演示里刚好触发的那一个请求。

1. 发现：确认入口、身份和可用工具，提前写下预期的最小权限范围。
2. 复现：在隔离环境复现原始路径，保留最短动作序列和全部证据。
3. 修复：调整权限配置、输入校验规则、工具调用边界或者监控规则，同步标出对应责任人。
4. 回归：重跑原路径和相邻路径，确认告警、阻断逻辑和正常业务流程都符合预期。

团队现在可以观察哪些信号

如果要把这类行业变化落地成日常可执行的工程动作，可以每周跟进四组指标：一条攻击路径平均包含多少个动作、会跨越多少个权限边界、从发现漏洞到复现完整链路花了多久、修复之后相邻路径还有多少没覆盖到。这些指标的价值不是为了凑出好看的数字，而是用来暴露当前验证是不是只覆盖了零散的单点漏洞。

安全团队还要保留一份“不可自动化清单”：真实凭据使用、生产环境数据写入、外部通知发送、资金或系统权限变更这类操作，全部要求人工确认之后才能执行。红队可以靠自动化工具自动生成测试方案，但最终的操作放行权不能随便交给模型生成的自动动作链。

相关问题

智能体攻击会取代传统红队吗？

不会。它更像是用来扩大测试覆盖面的工具，人工仍然要负责判断业务影响、授权边界和修复优先级。

小团队没有智能体平台怎么办？

先把之前的人工演练记录整理成可重复执行的最短动作序列，再补全身份、工具、数据和结果这些字段。流程理清楚之后，要不要接入自动化工具才有明确的对比依据。

如何避免把演练变成真实攻击？

全程使用脱敏数据和隔离账号，设置动作配额、时间上限、人工批准点和一键停止入口，并把生产写入与外部通知这类操作设为默认禁止。

总结

Google 讨论智能体时代的红队变化，值得关注的点不是一句“攻击速度变快”，而是验证对象更长了、动作链路更连贯了。把演练拆成可复现的路径，再用发现、复现、修复、回归四段流程做闭环验收，团队才能分清已验证的事实、合理推断和风险边界，也不会因为引入自动化就放弃必要的人工控制。