Coding-Agent-Security-Audit（Coding Agent 安全审计标准）
定义
Coding Agent 安全审计标准 是将审计范式从传统"行为审计"（审计已知攻击面）升级为数据流审计（Data Flow Audit）的新框架。核心机制 = DFD（Data Flow Declaration，机器可读数据流声明）+ VDF（Verified Data Flow，独立验证实际数据流）。目标：让 coding agent 的数据收集行为从"不可审计的黑箱"变为"声明可读、实际可测的灰箱"。
关键数据点
- 攻击面乘性：
攻击面(agent) = 工具调用 × 文件访问 × 代码执行 × 网络访问，维度间交互创造不可枚举的攻击路径 - Iternal 2026：65% 组织有 agent 安全事件，86% 对 AI 数据流无可见性，仅 14.4% 有完整安全审批
- Lushbinary 2026：已实现 agent session 的 SBOM 生成 + pre-session/runtime/post-session/CI-CD gate 四阶段安全模型
- 核心金句（Schneier）："Security is not a product, it's a process"——对 coding agent 升级为"审计持续演化的行为空间"
前提与局限性
Coding agent 的攻击面与传统 SaaS 工具有本质不同：
攻击面(agent) = 工具调用 × 文件访问 × 代码执行 × 网络访问
四个维度不是加性的——是乘性的。工具调用可以读取 .env 文件（文件访问），代码执行可以运行任意 shell 命令，网络访问可以把读取到的密钥发出去。维度间的交互创造不可枚举的攻击路径。
传统安全审计（SOC 2/ISO 27001）的前提是被审计系统是一个可静态描述的实体——它审计的是访问控制、加密、日志完整性。但 coding agent 是一个持续演化的行为空间——审计对象从"产品"变成了"行为空间"，这是类别差异。
Schneier（圆桌，2026-07-17）："Security is a process, not a product." 对 coding agent 需升级为：安全不是审计一个产品，是审计一个持续演化的行为空间。
DFD+VDF 审计范式
DFD（Data Flow Declaration）
机器可读的数据流声明，类似 SBOM（Software Bill of Materials）之于软件供应链安全。DFD 列出：
- 数据类别：agent 收集什么类型的数据（源代码/配置文件/环境变量/依赖信息/提交历史等）
- 数据目的地：数据被发送到哪里（本地/厂商服务器/第三方服务）
- 保留期限：数据在服务端保存多久
- 可关闭性：用户能否禁用特定数据类别的收集
格式标准化（Hightower 提案）：需要类似 SPDX/CycloneDX 的轻量级标准组织维护 DFD 规范，开源工具链自动生成 DFD。
VDF（Verified Data Flow）
独立第三方验证实际数据流是否匹配声明。Grok Build CLI 的 opt-out 声明是假的——声明≠实际。验证机制：
- 客户端可验证：文件系统审计日志（读了哪些文件）、网络代理日志（向哪些域名发送了数据）
- 需第三方验证：服务端处理（厂商基础设施内数据如何处理）→ 可信第三方审计或机密计算
- 标注盲区：不可客户端验证的部分必须明确标注——透明度≠幻觉，幻觉=不标注盲区（Schneier）
完整审计 = DFD(声明) + VDF(验证) + 盲区标注
联网实证（2026-07-17）
- Lushbinary（2026）：已实现 agent session 的 SBOM 生成 + pre-session/runtime/post-session/CI-CD gate 四阶段安全模型
- Iternal（2026）：65% 组织有 agent 安全事件，86% 对 AI 数据流无可见性，14.4% 有完整安全审批
- IEEE-USA NIST RFI（2026-03）：zero-trust agent access + tool/data sandboxing + monitoring with kill switches
- Northflank：企业 coding agent 部署审计日志 → SIEM 已成实践
- Augment Code：Cursor 缺乏审计 API/SIEM 集成——行业差距确认
制度化行动者：企业 CISO
个体开发者对 coding agent 的退出成本太高（muscle memory + 工作流依赖 + 团队协作锁定）→ "透明度→用户退出→厂商受损"的杠杆链断裂（Zuboff 指出 Facebook/Zoom/Equifax 透明度暴露后市场份额未变）。
真正的杠杆承载者 = 企业 CISO 群体（Wu，圆桌）。CISO 的优势：
- 决策集中：一个决策影响数百至数千开发者
- 独立安全问责：CISO 个人对安全事件负法律责任
- 标准化采购流程：安全审计可嵌入 RFP 要求
关键阈值：当 ≥ N 家 Fortune 500 企业的 CISO 要求 DFD+VDF 审计标准时，市场激励方向翻转。
分层标注：破解合法化效应
合法化效应（Zuboff）
审计标准的危险：从"最低安全要求"演变为"安全的社会定义"。SOC 2 认证后，"有 SOC 2 = 安全"——即使不是真的。如果 coding agent 审计先于代码库数据产权定义——审计合法化的数据收集行为成为新基线，后来的产权立法更难推进。
分层标注方案（Mickos）
- Tier 1："数据仅用于提供服务，不用于模型训练"（最高保护）
- Tier 2："数据用于模型训练但经过去标识化"（中等保护）
- Tier 3："数据用途未限制"（最低保护，当前市场常态）
"通过认证"≠"安全"而="安全程度被明确标注"。Tier 3 不是"足够安全"，是"知道自己面临什么风险"。
市场均衡陷阱（追本第 4 层）
分层标注在逻辑上破解合法化效应——但在市场均衡中可能重建：
- 如果行为剩余的经济价值 > 标注 Tier 1 的差异化竞争优势 → 理性厂商选 Tier 3
- 如果所有主流 agent 都是 Tier 3 → CISO 失去议价能力 → Tier 3 成为事实基线
- 这就是柠檬市场在安全标注中的投射：高质量 Tier 1 被挤出
破解条件：足够多的 Tier 1/Tier 2 替代品（需要市场竞争或开源替代）。
定义权不可拆分定理（追本七层到底）
"并行推进"（审计基础设施 + 产权定义）策略的失败不是因为两个过程不能同时开始——是因为定义权不可拆分。
定义权 = 命名权 ∪ 分类权 ∪ 度量权。度量权 ⊂ 规范权（不可拆分）。
当 Google 提议"按数据目的地分类 Tier 1/2/3"——这是在行使产权定义权，不是在做中立的标准化。选择"按目的地分类"vs"按用途分类"会导向完全不同的产权安排：
- 目的地分类 → 对厂商有利（"数据只去了我们的服务器"= Tier 2）
- 用途分类 → 对用户有利（"用来训练模型就是 Tier 3 不管去哪"）
测量框架 = 概念地形 = 权力的棋盘。
修正：多利益相关方共定标准
真正的出路不是"先后"而是谁在定义。技术层的标准制定必须从一开始就包含非厂商利益相关方（用户代表、开源社区、独立安全研究者、公民社会组织）并有实质投票权——非"厂商先定义 v0.1 然后开源社区跟进工具"。
Wu 三阶段修正路线图
| 阶段 | 时间 | 内容 | 修正 |
|---|---|---|---|
| 技术层 | 1-2年 | DFD+VDF 标准 + 开源工具链 | 修正：多利益相关方共定 v0.1（非厂商单边） |
| 法律层 | 2-4年 | 代码库数据产权在 AI 训练数据立法框架中定义 | 与 GDPR/数字市场法演进同步 |
| 制度层 | 4-7年 | 可执行认证体系 + 独立审计市场 + 违规制裁 | 需政治意志（通常由灾难性事件催化） |
关联概念
- Agent-Trust-Boundary（V×C×A框架）：DFD+VDF = 可见性(V)工程化；分层标注 = 可控性(C)工程化；第三方审计 = 可验证性(A)工程化
- Agent OWASP Top 10：安全审计标准 = 意识文档(形态1)的下一步（检测框架/安全厂商形态2）
- Flattening-as-Governance-Consequence：CISO 集中采购决策 = 去科层化治理在安全维度上的反向集中（安全判断从分散开发者→集中 CISO）
- Token-Supply-Chain：代码库数据作为"行为剩余"的供应链分析
Agent Identity 分层标准化（07-18 扩展）
Agent 安全的身份层（roundtable 4人×2轮）：
分层标准化（非竞争）：
- L1 认证层：SPIFFE SVID 扩展 agent 类型/厂商/委派链（CNCF 治理，1-2年）
- L2 运行时治理：Agent Gateway/Firewall 协议——行为基线声明、异常检测、降级（需新社区，2-4年）
- L3 行为担保：去中心化行为审计链+独立担保方+法律担责框架（法律创新，4-7年）
紧迫性倒置（Marlinspike）：身份标准化不急迫（厂商"支持标准"="我们安全了"=橡皮图章）。急迫的是行为审计格式标准——每个 agent 必须输出的审计日志格式。
K8s 赢家公式（Beda）：开放治理(CNCF)+API可扩展(CRD)+哲学简单(薄而硬)。SPIFFE 三者全有→先发优势。Agent Gateway 缺治理。厂商自建全缺。
开放问题
- DFD 格式标准化——谁来牵头？厂商(Anthropic/GitHub/Google) vs 中立机构(OWASP/W3C/Linux Foundation)？
- 产权立法的政治可行性——代码库数据在 AI 训练数据产权的更大框架中处于什么位置？
- VDF 验证性能开销——机密计算在 coding agent 场景的实际性能影响？
- 中国 vs 西方路径——中国直接关闭 Agent 功能 vs 西方认证路径，3-5 年后哪边更安全？
- 柠檬市场风险——Tier 3 免费且好用 → 市场退化为"人人知道不安全但人人用"？