AI 正在同时改变软件开发、攻击面的边界和攻击者的行动速度。Google Threat Intelligence 的最新观察显示，安全团队面对的已经不只是更会生成钓鱼邮件的模型，而是能够接管工具、编排工作流并自动执行攻击的智能化系统。
对 CISO 和工程团队而言，关键问题不是要不要使用 AI，而是如何把安全控制嵌入 AI 辅助开发、云运行环境和安全运营流程中，让防御速度至少匹配攻击速度。
三个正在发生的结构性变化
1. AI 正在重塑软件供应链
代码助手、自动化代理和 AI 工作流显著提高了交付速度，但也让开发团队更加依赖模型推荐的代码、依赖包和工具配置。攻击者可以污染上游开源包、诱导模型推荐恶意组件，或者通过提示注入影响代理的行为。
因此，传统的发布前人工审查很难覆盖每一次自动生成和自动提交。更可行的方向，是把安全检查放进开发者已经使用的编辑器和代理工作流中，像拼写检查一样即时指出风险，例如：
- 依赖包是否来自可信来源，是否出现异常维护者或版本变化；
- AI 生成的代码是否引入危险的命令执行、反序列化或权限逻辑；
- 提示词和代理指令是否可能被外部内容覆盖；
- 工具调用是否拥有超出任务所需的云权限。
但编辑器里的检查并不够。代码安全、CI/CD 配置、云资源暴露面和生产身份权限必须关联起来，否则团队可能修复了代码漏洞，却仍然把一个公开暴露的服务和高权限身份一起部署到生产环境。
2. AI 扩大了攻击面
AI 工作负载本身已经成为高价值目标。需要关注的对象包括：
- GPU 和高性能计算资源：攻击者可能窃取令牌并部署未经授权的模型或代理，制造算力账单；
- 自定义提示词、代理技能和系统指令：其中可能包含企业流程和敏感业务知识；
- 微调模型、训练数据、源代码及研究资料：它们可能成为数据窃取和勒索的目标；
- AI 账号和 API 凭证：泄露后可被用于调用模型、访问数据或横向移动。
这些问题不应该被拆成互不相干的项目。AI 物料清单、影子 AI、代理访问策略、数据血缘和运行时身份之间存在直接关系。一个模型是否危险，往往取决于它能读取哪些数据、调用哪些工具，以及这些工具背后的云权限。
3. 攻击正在从单次提示走向自动化编排
攻击者不再满足于让模型生成一段恶意文本，而是尝试使用多个代理完成侦察、代码编写、凭证收集和执行。相关案例表明，攻击者可以把云入侵、AI 编程助手、提示词和代理指令组合起来，在很短时间内构建自动化攻击流程。
这并不意味着防守方必然处于劣势。攻击者通常缺少企业内部完整上下文，只能从外部试探；防守方则掌握代码、云配置、身份、部署关系和数据流。只要这些上下文能够被统一关联，AI 就可以帮助防守方更快地判断哪条攻击路径最危险，而不是仅仅处理大量孤立告警。
从单模型扫描转向多模型交叉验证
把一个前沿模型直接指向代码仓库，并不能自动得到可靠的安全结论。单模型方案可能漏掉复杂逻辑缺陷，也可能受到特定输入、恶意提示或安全过滤器盲点的影响。
可以这样实践多模型防护：
- 使用不同模型分别进行漏洞发现、数据流分析和代码修复建议；
- 对多个模型的结果进行交叉验证，降低单一模型误报或漏报的影响；
- 让一个模型检查另一个模型生成的修复，避免修复引入新的权限或业务逻辑问题；
- 将模型结论与真实云配置、运行时身份和资产暴露情况关联；
- 对高风险自动修复设置人工审批和回滚机制。
这里的重点不是堆叠更多模型，而是避免安全能力形成单一模型的“单一文化”。代码、模型、数据血缘和运行时身份应该汇聚到一张持续更新的关系图中，安全系统再根据上下文进行风险排序。
一个可改造的代理安全基线
下面的 YAML 是一个最小化的实践示例。它不是某个具体云厂商的原生配置，而是一份可以映射到 OPA、云 IAM、Kubernetes admission controller 或内部代理网关的策略草案。运行前请把身份、资源和命令替换成企业实际值。
apiVersion: security.example/v1
kind: AIAgentPolicy
metadata:
name: code-review-agent
spec:
identity:
serviceAccount: ai-code-reviewer
maxTokenTTL: 15m
requireWorkloadIdentity: true
tools:
allow:
- name: repository.read
- name: dependency.lookup
- name: static_analysis.run
deny:
- name: shell.execute
- name: production.deploy
- name: secret.read
data:
allowLabels:
- public-source
- approved-repository
denyLabels:
- customer-data
- production-secret
network:
egressAllowlist:
- registry.example.internal
- security-scanner.example.internal
approval:
requiredFor:
- dependency.change
- code.write
- infrastructure.change
audit:
logPrompts: true
logToolCalls: true
retainDays: 90
这份策略表达了几个重要原则：代理使用短时身份，不直接读取密钥；读代码和运行分析可以自动化，但写代码、变更依赖和修改基础设施需要审批；网络出口使用白名单；提示词和工具调用必须留下审计记录。
可以用以下命令在 CI 中做一个简单的策略检查。示例假设策略文件名为 agent-policy.yaml，并使用常见的 yq 工具读取 YAML：
set -euo pipefail
policy="agent-policy.yaml"
test "$(yq -r '.spec.identity.requireWorkloadIdentity' "$policy")" = "true"
test "$(yq -r '.spec.tools.deny[] | select(.name == "secret.read") | .name' "$policy")" = "secret.read"
test "$(yq -r '.spec.approval.requiredFor[] | select(. == "production.deploy")' "$policy" 2>/dev/null || true)" = ""
echo "Policy checks passed: workload identity and secret isolation are enabled."
生产环境中还应补充：策略版本控制、审批人校验、失败即阻断、策略单元测试，以及对代理工具调用的运行时监控。这个示例的价值不在于复制某个产品配置，而在于把“代理能做什么”从自然语言要求变成可审计、可测试的控制面。
安全运营也要进入机器速度
面对自动化攻击，单纯增加人工告警分析人员并不能无限扩展。更合理的闭环是让系统持续完成：
- 监控代码、模型、云资源和身份之间的变化；
- 识别暴露资产与高权限身份形成的攻击路径；
- 结合威胁情报和业务上下文进行风险排序；
- 对低风险事件自动隔离或修复；
- 对高风险操作保留人工审批、回滚和取证能力。
自动化不等于无监督。模型可以负责发现关联、解释路径和提出修复，但删除资源、撤销生产权限、轮换关键凭证等不可逆动作仍应具备明确的授权边界。
给安全团队的落地清单
可以从以下几个动作开始，而不必等待完整的 AI 安全平台：
- 建立 AI 物料清单，记录模型、代理、提示词、技能、数据集、API 凭证和部署位置；
- 为每个代理分配独立、短时、最小权限的运行时身份；
- 禁止代理默认访问生产密钥、客户数据和任意网络出口；
- 将依赖扫描、提示注入检测和 IaC 配置检查接入开发流水线；
- 把代码风险与真实云暴露面、身份权限和运行时告警关联；
- 对高风险自动修复设置审批、回滚和完整审计；
- 使用多模型或多种分析器交叉验证关键安全结论；
- 定期演练令牌泄露、GPU 资源滥用、模型数据窃取和代理失控场景。
结语：把 AI 的速度转化为防守优势
AI 正在加速攻击者，也给防守方提供了处理复杂上下文的机会。真正有效的方案不是在旧流程外面再加一个聊天机器人，而是把安全控制嵌入代码编辑、依赖管理、云部署、运行时监控和事件响应之中。
对于企业来说，最重要的转变是从孤立的模型清单和静态告警，走向连接代码、模型、数据、身份与云资源的动态安全视图。先从最小权限、短时凭证、代理审计和代码到云关联做起，再逐步扩大自动检测和自动修复范围，才能在提升开发速度的同时控制 AI 带来的新风险。