AI Security Operations：MITRE ATLAS、OWASP 与 NIST CSF
AI SecOps 是把 AI 系统中的 prompt、retrieval、tool call、model call、policy decision、data access、output 和 human override 变成可监控、可检测、可响应的安全运营面。它补足传统 SOC 对 AI 行为链路的盲区。
AI Security Operations / MITRE ATLAS / OWASP LLM Top 10 解读
核心问题: AI 安全不能停留在上线前红队或 prompt 过滤。如何把 LLM、RAG、Agent、工具网关、模型服务和数据链路纳入持续监控、检测、响应、恢复和控制有效性管理？
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| MITRE ATLAS | https://atlas.mitre.org/ | 理解 adversarial threats to AI systems 的战术技术知识库 |
| OWASP LLM Top 10 | https://owasp.org/www-project-top-10-for-large-language-model-applications/ | 理解 LLM 应用关键风险，如 prompt injection、data leakage、excessive agency |
| NIST Cybersecurity Framework | https://www.nist.gov/cyberframework | 用 Govern、Identify、Protect、Detect、Respond、Recover 组织 AI SecOps |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把安全风险和 AI 风险治理连接 |
| Cloud Security Alliance AI Safety Initiative | https://cloudsecurityalliance.org/ai-safety-initiative | 参考 AI 安全控制、治理和云环境实践 |
核心导读
AI SecOps 是把 AI 系统中的 prompt、retrieval、tool call、model call、policy decision、data access、output 和 human override 变成可监控、可检测、可响应的安全运营面。它补足传统 SOC 对 AI 行为链路的盲区。
MITRE ATLAS 提供 AI 对抗行为知识库，OWASP LLM Top 10 提供应用层风险分类，NIST CSF 提供安全运营函数。把三者合起来，才能把“AI 安全风险清单”落成资产清单、telemetry、检测规则、runbook、kill switch 和控制有效性仪表盘。
问题定义
传统 SOC 主要看 endpoint、network、identity、cloud、application logs 和 SIEM alerts。AI 应用新增了一类复合型攻击面:
user input
+ retrieved content
+ model behavior
+ tool authorization
+ policy configuration
+ output handling
= AI security outcome
典型风险包括:
- Prompt injection 诱导模型忽略系统策略或泄露上下文。
- RAG 召回无权限、过期或被污染的文档。
- Agent 调用超出业务授权的工具。
- Excessive agency 让系统连续执行副作用动作而缺少审批。
- Sensitive information disclosure 出现在回答、日志、PR 或导出文件中。
- Model denial of service 通过超长上下文、递归工具或高频调用耗尽资源。
- Data poisoning 和 eval poisoning 污染训练、检索或评估链路。
- Model theft、prompt extraction 或边界探测造成知识资产泄漏。
AI SecOps 要解决的问题是:
当 AI 行为跨越输入、检索、模型、工具、数据和人工流程时，
如何及时发现异常、限制影响、保留证据、恢复系统并证明控制有效？
核心原理
AI 安全运营的底层机制是 telemetry + detection engineering + response orchestration。
最低可用 AI telemetry schema:
| 类别 | 字段 |
|---|---|
| Identity | user_id、role、tenant、agent_id、session_id、service_account |
| Request | prompt hash、risk tier、channel、business object、input classifier |
| Retrieval | query hash、document IDs、ACL decision、source version、citation IDs |
| Model | provider、model、version、temperature、token count、safety setting |
| Tool | tool name、action、resource、arguments hash、result、side effect flag |
| Policy | PDP decision、policy version、deny reason、approval state |
| Safety | injection score、PII detector、toxicity/safety classifier、DLP result |
| Outcome | response category、user action、human override、incident flag |
| Cost/SLO | latency、cost、cache hit、rate limit、retry count |
检测工程不能只靠关键词。成熟检测会组合规则、分类器、policy diff、sequence pattern、anomaly detection、threat intel、purple-team cases 和人工复核。
| 检测对象 | 典型信号 |
|---|---|
| Prompt injection | 输入或检索文档包含越权指令、exfiltration pattern、policy bypass |
| RAG permission leakage | retrieved document ACL 与 user entitlement 不一致 |
| Tool misuse | 低权限 session 调用高风险工具或副作用动作 |
| Excessive agency | agent 连续执行多个高风险动作且无人工审批 |
| Data exfiltration | 输出含敏感字段、批量导出、异常 token volume |
| Model DoS | 超长上下文、递归工具、异常 retry、成本突增 |
| Jailbreak success | policy violation 后仍生成禁止内容 |
| Code agent secret exposure | 代码、PR、日志或回答中出现 secret pattern |
系统/架构模型
AI SecOps 架构可以按安全运营函数组织:
AI asset inventory and threat model
-> AI gateway / app instrumentation
-> policy and tool gateway logs
-> RAG lineage and ACL logs
-> detection rule catalog
-> SIEM/SOAR integration
-> incident runbooks and kill switches
-> forensic trace store
-> purple-team harness
-> control effectiveness dashboard
NIST CSF 映射:
| CSF function | AI SecOps 映射 |
|---|---|
| Govern | AI security policy、risk tier、ownership、third-party controls |
| Identify | AI asset inventory、model/tool/data map、threat model、data flow |
| Protect | access control、tool gateway、guardrails、DLP、segmentation、approval |
| Detect | AI telemetry、prompt/tool/RAG detection、SIEM rules、anomaly monitoring |
| Respond | triage、containment、kill switch、connector quarantine、customer impact review |
| Recover | model/prompt revert、corpus cleanup、credential rotation、postmortem |
关键架构原则是把安全控制放在共享通道中: AI gateway 管模型调用和 trace，tool gateway 管工具授权和副作用，RAG gateway 管 ACL 和文档来源，policy engine 管风险等级与审批。
关键机制与取舍
| 取舍 | 判断方式 |
|---|---|
| 原始 prompt 记录 vs 隐私最小化 | 调查需要证据，但敏感 payload 应 hash、mask、分级保留和审计访问 |
| 阻断 vs 观察 | 高风险工具和数据泄露应阻断，低风险异常可先告警和采样 |
| 规则 vs 分类器 | 明确违规用规则，语义攻击和变体用分类器，两者都要 purple-team 校验 |
| 中央 gateway vs 应用内埋点 | Gateway 保证一致控制，应用埋点补足业务上下文 |
| 安全强度 vs 延迟成本 | 客户实时链路要分层控制，后台批处理可做更重的检测 |
| Kill switch vs granular containment | SEV0 需要快速切断，局部异常应能禁用模型、tool、corpus 或 tenant |
AI 安全的成熟度不在“有多少 guardrail”，而在 guardrail 是否能被观测、被绕过测试、被度量有效性，并在事故中快速切换到可控状态。
证据与控制
Incident severity 应与业务损害绑定:
| Severity | 示例 | 默认响应 |
|---|---|---|
| SEV0 | 客户数据泄露、资金动作越权、大规模高风险错误 | kill switch、exec/risk/legal/privacy、customer impact review |
| SEV1 | 权限绕过、工具误用、关键 guardrail 失效 | containment、rollback、forensic trace、policy fix |
| SEV2 | 局部 policy violation、低风险错误输出 | patch、monitor、targeted notification |
| SEV3 | 检测误报、低影响异常 | rule tuning、document、watchlist |
控制有效性指标:
| 控制 | 有效性证据 |
|---|---|
| Prompt injection detector | true positive、false positive、purple-team bypass rate |
| Tool gateway | high-risk action blocked、approval bypass = 0、override audit |
| RAG ACL filter | unauthorized retrieval = 0、ACL test coverage |
| DLP | sensitive output blocked、investigation precision |
| Rate limit | DoS prevented、legitimate user impact、cost containment |
| Kill switch | mean time to disable model/tool/corpus、rollback drill |
| Runbook | tabletop completion、MTTD、MTTR、evidence preservation |
隐私与证据之间要建立明确规则: 调查 trace 不是无限保留原始内容，而是按风险等级记录 hash、mask、citation、policy decision 和必要 payload，并通过 break-glass 审计访问。
AI产品/金融零售场景
客服 AI 数据泄露
事件路径:
customer question
-> RAG retrieves unauthorized internal document
-> model includes sensitive field in answer
-> customer sees restricted content
检测信号包括 ACL mismatch、sensitive output detector、unusual citation source 和 policy decision anomaly。响应应关闭相关 corpus、回滚检索配置、查询受影响会话、通知 privacy/compliance，并补齐 permission regression tests。
Agent 越权调用工具
Prompt injection 诱导 agent 调用 CRM write tool 或资金相关工具。控制面应在 action risk tier、tool gateway、approval state 和 policy deny event 上形成多道防线。响应包括 kill session、freeze connector、preserve trace、复现攻击和更新 tool policy。
Code Agent Secret Exposure
Code agent 在 PR、日志或回答中暴露 secret。检测依赖 secret scanning、repo permission trace、agent action audit 和 DLP。响应要 revoke secret、rotate credential、quarantine PR、审查上下文注入规则和最小权限。
AI 平台成本与 DoS 异常
异常 token、递归 tool call、缓存失效或恶意高频调用会造成成本和 SLO 事故。SecOps 需要把 cost anomaly 与安全事件联动，而不是只交给 FinOps。
反模式
- 只做上线前红队，缺少持续 telemetry、检测和响应。
- 把 prompt 内容全部原样入日志，制造新的隐私和泄露风险。
- 只在模型层加 guardrail，工具、RAG、policy 和输出链路没有控制。
- 检测规则只靠关键词，无法覆盖语义变体和链式攻击。
- 没有 kill switch，只能通过发版或人工改配置止损。
- 事故后无法还原当时的 prompt、retrieval、tool call、policy version 和 human override。
- 告警越堆越多，但没有 true positive、false positive 和控制有效性度量。
最终心智模型
AI SecOps 是 AI 平台的安全运营平面。MITRE ATLAS 告诉你可能面对哪些对抗路径，OWASP LLM Top 10 告诉你应用层常见失败模式，NIST CSF 告诉你如何把治理、识别、防护、检测、响应和恢复连成闭环。
判断一个 AI 系统能否进入受监管生产，不是看它是否“接了一个安全模型”，而是看一次真实事故发生时能否做到: 快速发现、精确定位、限制副作用、保留证据、恢复服务、修复控制，并证明同类问题再次发生的概率下降。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。