AI 正在把攻击和防御同时推向更快的节奏：攻击者可以批量生成更贴合目标的钓鱼话术、动态混淆恶意代码，防守方则可以用模型发现漏洞、关联遥测并辅助修复。但速度并不会替代安全基本功。恰恰相反，身份控制、补丁治理、可观测性和分层防御，决定了组织能否承受 AI 放大的攻击强度。
Google Cloud CISO Chris Betz 的核心观点很直接：面对 AI 驱动的威胁，安全团队不应只追逐新工具，而要把已经验证有效的基础控制做深、做一致，并用这些控制为防御型 AI 提供可靠上下文。
AI 放大的不是单一漏洞，而是攻击链
传统自动化擅长重复执行固定任务；AI 更擅长在大量目标中生成具体、定制化且快速变化的动作。这会让一些原本依赖人工判断、响应较慢的攻击环节变得更危险。
例如，攻击者可能将以下能力组合成一条连续攻击链：
- 使用语音钓鱼和深度伪造绕过员工对身份的直觉判断。
- 在恶意软件运行期间即时生成脚本，并动态混淆代码以规避检测。
- 利用公开漏洞出现后极短的利用窗口，快速扫描并攻击暴露资产。
- 借由未授权的 AI 工具和代理形成“影子代理”，让数据访问、自动化操作脱离既有治理边界。
因此，单点产品无法解决问题。MFA、零信任、及时补丁、检测与响应并非“旧时代遗留物”，而是限制攻击链横向推进的不同关卡。控制越完整，AI 分析日志、身份、资产和网络路径时可依赖的上下文也越可信。
漏洞管理的瓶颈从发现转向决策与闭环
AI 可以将漏洞发现、代码审查和修复建议的吞吐量显著提高，但发现更多问题不等于降低更多风险。真正困难的部分是：哪些漏洞会影响互联网暴露服务、关键身份路径、生产数据或高价值业务流程？哪些修复可以在不引入业务事故的前提下最快上线？
可以把漏洞治理拆为四个连续动作：
- 统一资产与漏洞事实：明确组件运行在哪里、是否对外暴露、由谁负责。
- 以可利用性和业务影响排序：CVSS 分数只是输入，不应是唯一队列规则。
- 自动生成候选修复，人工审核高风险变更：AI 可辅助补丁、测试和变更说明，但不能取消代码审查与发布门禁。
- 验证修复已生效：重新扫描、检查运行时版本、确认告警与攻击路径变化。
这里的关键是闭环。一个“已创建工单”的高危漏洞，和一个在生产环境中被验证消除的攻击路径，安全价值完全不同。
威胁建模需要从静态文档走向持续更新
高质量威胁建模需要同时理解代码、云架构、系统设计、身份关系和网络通信路径。这类上下文往往分散在代码仓库、IaC、CI/CD 配置、日志平台和工单系统中，人工维护一份静态文档很容易过期。
来源提到，Google Cloud 的工程团队已将产品发布接入基于代理的安全审查流水线：高风险信号自动标记给人工复核，静态威胁模型则由能够实时更新的产品档案替代。这说明 AI 最适合承担“收集、关联、枚举和提示”的工作，而高影响风险的接受、缓解与发布决策仍必须保留明确的人类责任人。
对团队而言，威胁模型不必从一份几十页的文档开始。一个能持续回答以下问题的版本更有价值：
- 这个服务处理什么数据，数据会流向哪里？
- 哪些身份可以部署、读取机密或调用高权限 API？
- 服务是否公开暴露，是否存在跨网络边界的信任关系？
- 新增依赖、模型、代理或自动化步骤后，攻击面增加在哪里？
可以这样实践：给 AI 工作负载建立最小安全基线
下面的示例是一个可改造的 Kubernetes 部署基线，假设你正部署一个会调用模型 API 的内部服务。它并不替代完整的身份、密钥和网络方案，但能将几个基础控制明确写进工作负载配置：非 root 运行、禁止权限提升、只读根文件系统、限制 Linux capabilities、设置资源边界，并通过网络策略收紧入口流量。
将镜像地址、命名空间、端口和标签替换为自己的值后，可先在测试集群执行：
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-review-service
namespace: ai-apps
spec:
replicas: 2
selector:
matchLabels:
app: ai-review-service
template:
metadata:
labels:
app: ai-review-service
spec:
automountServiceAccountToken: false
containers:
- name: app
image: registry.example.com/ai-review-service:1.0.0
ports:
- containerPort: 8080
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ai-review-service-ingress
namespace: ai-apps
spec:
podSelector:
matchLabels:
app: ai-review-service
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: api-gateway
ports:
- protocol: TCP
port: 8080
kubectl apply -f ai-review-service.yaml
kubectl -n ai-apps rollout status deployment/ai-review-service
kubectl -n ai-apps get pods -l app=ai-review-service
上线前还应检查两个容易遗漏的边界：一是模型 API 凭据不能硬编码在镜像、环境变量快照或提示词日志中；二是网络策略只有在集群 CNI 支持并启用策略执行时才真正生效。对于生产环境，更适合使用工作负载身份或短期凭据，而不是长生命周期静态密钥。
给 CISO 和工程负责人一份优先级清单
AI 安全建设不应从“采购一个 AI 安全平台”开始，而应先确认基础控制是否稳定运行：
- 关键人员、管理员和高风险应用是否强制使用抗钓鱼 MFA？
- 是否按资产关键性和外部暴露面来管理补丁，而非只看漏洞数量？
- 是否能在合理时间内发现、隔离和复盘可疑身份与工作负载行为？
- 每个 AI 应用是否具备明确的数据边界、模型调用身份、审计记录和人工升级路径？
- 架构、代码和发布变更是否会触发可追踪的威胁建模或安全审查？
安全负责人还需要把这些控制翻译成业务语言：停机风险、数据泄露范围、合规义务、客户信任和收入影响。AI 让网络安全更接近董事会和管理层的核心议题，也让 CISO 的角色从技术把关者进一步走向业务风险决策者。
在 AI 时代，先进的检测模型和代理式审查值得投入，但它们必须建立在可靠的身份、资产、补丁和遥测基础之上。基础薄弱时，AI 只会让组织更快地产生更多告警；基础扎实时，AI 才能成为可控的防御放大器。