AI 正在同时提高攻击和防御的自动化水平。攻击者可以用多模型生成钓鱼内容、构造深度伪造、寻找零日漏洞，并让多个代理在数十秒内完成攻击阶段交接。防守方真正可持续的优势，却不是拥有更多模型，而是掌握攻击者进入企业环境后仍然缺少的深度上下文：资产在哪里、服务如何通信、身份属于谁、代码由哪个团队维护，以及某个漏洞是否真的能够抵达关键数据。
这意味着安全团队不能只把大模型接到告警列表上。更有效的做法，是把资产、身份、代码、运行时遥测和威胁情报组织成一条闭环，让 AI 在上下文约束下准备、扫描、修复和监控。
模型相同，上下文决定结果
从互联网外部观察企业时，攻击者通常只能扫描域名、端口、API 和泄露凭据，再逐步推测内部结构。防守方则天然拥有 inside-out 视角，可以回答更具体的问题：
- 这个公开 API 后面连接了哪些服务和数据存储？
- 漏洞所在容器是否真的部署在生产环境？
- 工作负载身份能否访问客户数据或密钥？
- 代码仓库由哪个团队负责，修复能否在当天发布？
- 当前异常是否与已知攻击者的基础设施或技战术一致？
缺少这些信息时，AI 只能更快地产生告警摘要；拥有这些信息后，AI 才能区分“存在漏洞”和“存在可利用攻击路径”。这也是深度上下文的直接价值：它把排序依据从 CVSS 分数扩展为暴露面、可达性、身份权限、数据敏感度、运行状态和威胁活跃度。
来源介绍的 Google AI Threat Defense 蓝图，将这种闭环分成四个阶段：用 Wiz 映射应用、API、身份和运行环境并模拟攻击路径；使用不同规模的模型扫描和验证风险；通过 CodeMender 在开发工具中生成并验证代码修复；再结合 Wiz、Google Security Operations 和 Mandiant 情报持续监控未知威胁。重点不是把产品简单堆叠起来，而是让同一份上下文贯穿发现、决策和处置。
从告警队列转向四阶段闭环
Prepare：先建立可查询的资产关系
资产清单只记录“有什么”还不够。防御系统还需要记录关系，例如公网负载均衡器指向哪个工作负载、工作负载使用哪个身份、身份能访问哪些数据，以及仓库和责任团队之间如何对应。
如果这些关系散落在 CMDB、云平台、代码托管系统和工单系统中，AI 代理很容易给出无法执行的建议。准备阶段应先统一资产标识，并为每项资产补齐 owner、environment、data_classification、internet_exposed 和 repository 等字段。
Scan & Prioritize：把昂贵推理留给高风险路径
所有资产都调用前沿模型，既昂贵也没有必要。可以先用规则、小模型或传统扫描器覆盖全量资产，再把满足以下条件的项目交给能力更强的模型分析：公网可达、存在高权限身份、连接敏感数据、已观察到真实利用，或者位于关键业务路径上。
这种分层方法同时控制计算成本和误报数量。模型输出还应包含证据、置信度和缺失信息，不能只给一个风险等级。
Remediate：修复必须回到代码和配置
一条“建议升级依赖”的告警不算闭环。自动化系统应定位仓库和责任团队，生成最小变更，运行测试与安全扫描，再通过拉取请求交给人审批。对高影响改动，例如身份策略、网络边界和内存安全迁移，仍要保留人工复核。
Monitor：无法立即修复时，用运行时控制争取时间
零日漏洞和遗留系统不一定能立即打补丁。监控阶段需要把网络、身份、应用和威胁情报关联起来，在发现异常调用、权限提升或新攻击基础设施时执行临时缓解，例如隔离工作负载、撤销令牌、限制入口流量，并创建后续修复任务。
来源给出的 Morgan Stanley 案例显示，这类统一方法可将检测和主动缓解窗口从 45 分钟缩短到 90 秒以内。这个结果依赖具体平台、流程和组织条件，不应直接当作所有企业都能复制的基准，但它说明了机器速度闭环的目标形态。
可以这样实践：构建一个上下文风险分流器
下面是一个不依赖特定厂商 API 的最小示例。假设扫描平台已经把漏洞与资产上下文导出为 JSON，脚本根据暴露面、生产环境、敏感数据、高权限身份和已知利用情况计算优先级。实际接入时，应把静态权重替换为组织自己的风险策略，并保留原始证据。
创建 findings.json：
[
{
"id": "CVE-DEMO-001",
"asset": "payments-api",
"severity": "high",
"internet_exposed": true,
"environment": "prod",
"privileged_identity": true,
"sensitive_data": true,
"known_exploitation": false,
"owner": "payments-platform",
"repository": "services/payments-api"
},
{
"id": "CVE-DEMO-002",
"asset": "internal-preview",
"severity": "critical",
"internet_exposed": false,
"environment": "dev",
"privileged_identity": false,
"sensitive_data": false,
"known_exploitation": false,
"owner": "developer-experience",
"repository": "tools/internal-preview"
}
]
创建并运行 prioritize.py：
#!/usr/bin/env python3
import json
from pathlib import Path
SEVERITY = {"low": 1, "medium": 3, "high": 6, "critical": 9}
def score(item):
value = SEVERITY[item["severity"]]
value += 6 if item["internet_exposed"] else 0
value += 4 if item["environment"] == "prod" else 0
value += 5 if item["privileged_identity"] else 0
value += 5 if item["sensitive_data"] else 0
value += 10 if item["known_exploitation"] else 0
return value
findings = json.loads(Path("findings.json").read_text())
for item in sorted(findings, key=score, reverse=True):
priority = "P0" if score(item) >= 25 else "P1" if score(item) >= 15 else "P2"
print(
f'{priority} score={score(item):02d} {item["id"]} '
f'asset={item["asset"]} owner={item["owner"]} repo={item["repository"]}'
)
python3 prioritize.py
预期输出中，payments-api 即使只有 high 严重度，也会因为公网暴露、生产部署、高权限身份和敏感数据而排在 critical 的内部开发资产之前。随后可以只把 P0/P1 项目及其证据发送给大模型，让它生成调查计划或修复草案。
用于模型的提示词可以明确限制自主权：
你是漏洞分流代理。只根据输入证据判断，不得推测缺失的网络路径。
任务：
1. 解释该漏洞是否存在从互联网到敏感数据的可达路径。
2. 列出结论依赖的证据和缺失信息。
3. 提出最小修复方案及临时缓解措施。
4. 涉及生产变更、身份权限、数据删除或隔离操作时，只生成审批建议，不得执行。
输出 JSON 字段：decision、evidence、missing_context、patch_plan、mitigation、approval_required。
在生产环境中，还应对模型返回值执行 JSON Schema 校验，把建议与证据一起写入审计日志，并让执行代理使用短期凭据和最小权限。模型不能因为生成了一段看似合理的解释，就自动获得修改生产环境的能力。
人类监督不是人工处理所有告警
机器速度防御并不等于取消人工决策。更合理的职责划分是：AI 负责持续收集上下文、关联事件、生成补丁、执行测试和准备处置方案；人类负责定义策略、批准高影响操作、处理不确定性，并审查代理是否越过权限边界。
来源提到 Red、Blue 和 Green 等不同代理角色，分别面向渗透测试、威胁调查和云修复。这种角色拆分也适用于内部平台：每个代理只拥有完成单一任务所需的工具，不让一个通用代理同时发现问题、批准变更并修改生产环境。
还要关注 shadow AI 和未经授权的代理。员工自行下载模型、连接企业数据或部署代理，会形成难以观测的逻辑漏洞、提示注入入口和数据投毒风险。Zero Trust for AI 可以落实为几条工程规则：每次模型调用都验证身份和用途；工具授权按任务动态签发；敏感数据进入提示词前执行分类和脱敏；模型、数据集、提示词及工具版本全部可追踪；高影响动作必须经过独立审批点。
落地时检查这六件事
- 是否能从一条漏洞追溯到公网入口、运行工作负载、身份、数据、代码仓库和责任团队？
- 风险优先级是否包含可达性与业务影响，而不只是扫描器严重度？
- AI 生成的修复能否自动运行单元测试、安全测试和策略检查？
- 对生产、身份、网络和数据操作是否设置了明确审批边界与回滚路径？
- 无法修复的系统是否有隔离、令牌撤销、流量限制等临时控制？
- 是否能发现未经批准的模型、数据连接、代理和工具调用？
AI 让攻击链从小时压缩到秒，也迫使防守方改变组织方式。真正的防守优势并非让模型独立做所有决定，而是给受控代理提供攻击者无法获得的企业上下文，再用可验证的代码变更、运行时控制和人类审批把分析变成闭环行动。