深度分析 | AIGC场景下的数据泄露溯源与防护

一、 AIGC为什么要溯源与防护

（一）AIGC 是什么

“AIGC” 即“ Artificial Intelligence Generated Content ”的缩写，中文对应“人工智能生成合成内容”，是指用人工智能技术生成合成的文本、图片、音频、视频、虚拟场景等信息。与 PGC、UGC 的差别在产出主体，内容由模型依据训练中习得的概率分布采样生成。本文所说的 AIGC 场景，指生成式模型接入企业业务流程与内部数据后形成的应用环境。AIGC 是这一环境产出的内容，两者不在同一层次。

近两年，生成式模型从演示与试点走进真实业务流程，写代码、检索知识、起草文档、应答客户，能力铺开快于配套安全能力建设，两类问题随之浮现：

一类出在责任归属上，获取数据的主体不再只有人。一句指令之后，动作由 AI 智能体、大模型与技能（Skill）接力完成，日志里只留下一次工具调用，看不出这一步出自谁的意图。责任归属并未消失，难的是过程不透明、复核跟不上自动调用的频率。

另一类出在管控对象上，数据流动不再以文件为单位，传统管控失去着力点。前者引出溯源命题，后者引出防护命题（图 1）。

图 1　从 AIGC 的两个技术事实到溯源与防护两条命题链

（二）为什么必须溯源：责任从哪里确认

企业需要溯源的时刻通常不是内容生成的那一刻，而是泄露被发现的那一刻，要回溯的是数据本身、获取数据的主体与流转路径。内容标识是并行的正向需求，但它写在内容里、不写在系统里。

（三）为什么必须防护：模型成为数据外发的新通道

溯源在事后，防护在事中。但模型一旦接入内部数据，两条线就共用同一组观测点：溯源靠请求、检索、生成、外发四侧的记录重建路径，防护也在同样的位置拦截。

数据流动的方式发生了三处改变，即载体从文件变成片段与语义，在提示词、向量库与生成结果之间往返；路径从事先能列全的固定名单，变成一张不断派生、无法穷尽的网；主体从 IP 与人类用户扩展到 AI 智能体、大模型与技能这类非人身份。更棘手的是，模型无法从架构上区分“指令”与“数据”，藏着指令的文档被读取即被执行，即间接提示词注入，连续两版位居 OWASP《Top 10 for Large Language Model Applications》（LLM 应用十大安全风险）首位。

今年 3 月初公开的一起事件从另一侧印证了这条通道：某国际咨询公司的内部 AI 助手被攻破，攻击方发现其对外开放的数百个 API 端点中有一批无需认证即可访问，利用 SQL 注入叠加越权访问，两小时内取得生产数据库读写权限，可触达数千万条内部消息。而执行这次攻击的，本身也是一个自主运行的 AI 智能体。攻击者没有突破任何边界，是系统自己交出了数据。

（四）两类命题不可互相替代

溯源与防护是两个性质不同的缺口，前者是“证明”，后者是“阻断”。互相替代会同时失效，溯源再扎实也阻止不了模型把数据读走，边界再严也说不清数据是谁带出去的。

表 1　溯源命题与防护命题对照

二、泄露之后，谁泄密、怎么泄密

泄露发生之后，企业要回答“谁泄密、怎么泄密”这两个问题，前者指向责任主体认定，后者指向流转过程重建。

（一）溯源的起点与目标：从一份泄露物往回追

企业获知泄露的渠道不外乎客户或监管部门的告知、外发通道告警与公开发现，而拿到消息时，数据已经在外面了。

目标因此收敛为两个必答问题，即由哪个身份带出去的（谁泄密）、经过哪条路径（怎么泄密）。二者缺一不可，只知外流而不知主体，追责无从落地。只知主体而不知路径，堵漏无从下手。而这两个答案都不在泄露物里，只能靠系统侧留存的记录（见图 2）。

图 2　从一份泄露物出发的两个必答问题与各自的证据来源

（二）谁泄密：三类责任主体

“谁”这个问题比多数企业的预案设想更复杂，传统泄露事件的责任主体是人，AIGC 场景把另外两类主体带了进来。第一类仍是人，决定采用哪个智能体、调用哪个模型、挂上哪些技能的，都是具体的人。而使用 AIGC 辅助办公之后，这一类的可观测性反而下降，员工把内部资料交给模型处理，身份与终端行为记录未必能把“谁把哪份数据交给了哪个模型”串起来，人工复核更难覆盖每一次自动调用。

第二类是非人身份。执行动作的是 AI 智能体、大模型与技能，它们以程序身份运行，分别由自己的凭据或调用方账号获得授权，日志里留下的只是一次工具调用记录，能证明“某身份调用过某工具”，回答不了“是谁让它调的”。更隐蔽的错位是，界面上的开关往往只控制一项功能，真正的数据出口在别处。

第三类是外部主体，包括第三方服务商、外包开发方与被利用的通道。数据经过的每一跳都在别人手里，企业只能依赖对方的自述。三类的取证路径不同，对人看身份与终端行为记录，对非人身份看凭据签发与调用日志能否关联，对外部主体靠合同义务与可核验记录。

（三）怎么泄密：路径重建与四类手法

“怎么”这个问题的难度，来自 AIGC 场景把泄露路径从一条直线变成了一张网。过去路径是“文件从 A 到 B”，事先列得清楚；现在是“提示词拼接、向量召回、生成、外发”，每一步都可能产生新载体。路径重建要把这条链拆成四个观测点，请求侧记谁提交了什么，检索侧记触达了哪些文档，生成侧记返回了什么，外发侧记结果送去了哪里。缺一环，重建就退化为推测。

从已经发生的事件来看，泄露手法集中在四类（图 3）：

静默打包外传：客户端在后台把工作目录整体打包上传，不依赖模型推理，模型调用日志里不留痕迹，只能靠网络出口异常连接与本地大规模读取发现。

借道注入：把指令藏进文档让模型读取即执行，再反用系统的检索与导出能力把数据带出，没有越界动作，被借用的正是系统自身的读取能力。

越权执行：非人身份以超出任务所需的权限运行，越权读取被当成一次正常调用。

拍摄与截图：人对着屏幕拍照或截图后经即时通信工具外发，不经过任何数据接口，通道侧控制无效。

图 3　四类典型泄露手法与各自可观测的痕迹

（四）一个样本：静默打包外传的逆向分析

近期公开披露的一起事件，为“谁泄密、怎么泄密”提供了结构完整的样本：国内某 AI 编程辅助工具被发现，其本地目录占用远超正常体量，内含一个数百 MB 量级的加密打包文件。

逆向还原出的机制是，用户在登录状态下打开项目，客户端即从服务端获取云存储上传凭据与一个 RSA 公钥，随后在后台无差别打包整个工作目录，被打包的内容中，版本控制目录及其大文件缓存占绝大部分，源码与文档只占很小一部分。打包在本地流式加密后用服务端公钥封装对称密钥，随后绕过厂商自有服务器直传第三方公有云对象存储。整个过程没有任何环节调用模型。

谁在上传数据，技术上查得清楚：上传使用的是服务端下发的凭据，可以对应到具体账号。真正说不清的是泄露范围，因为私钥始终由服务端持有，企业只能确认数据已经出去，无法确认出去的只是当前代码，还是连同数年的提交历史、已删除的密钥与未推送的分支名。这带来三方面问题，一是企业无法自证“泄露的只是 A、不含 B”。二是举证责任实质上反转，只能依赖厂商自述。三是“数据用后即销毁”的承诺在架构上也无法验证。更值得注意的是控制失效的方式，打包前虽设有过滤规则与体积上限，但版本控制元数据未被过滤规则覆盖，恰恰是风险最高的那部分数据被完整带走。

（五）证据面：从结果往回追的三条线索

可用的证据分布在三个面上（见表 2），即身份与凭据解决“是谁”，日志解决“通过哪条路径”，水印解决“从哪个账号、什么时间出去的”。三者是一条链而不是并列选项，缺身份层无法定责，缺日志层无法还原路径。

表 2　泄露溯源的三个证据面与可指认层级

图 4　三个证据面的分工与可还原的结论

（六）制度依据：为什么必须做到可举证

企业要建设这套能力，答案不只在业务需要里。《网络安全法》要求日志留存不少于六个月，《数据安全法》要求事件立即处置并报告，《个人信息保护法》要求通知载明泄露的种类、原因与危害，《网络数据安全管理条例》要求向其他网络数据处理者提供、委托处理个人信息和重要数据的记录至少保存三年，GDPR 则给出 72 小时时限。这些要求指向同一件事：记录必须事前就位。

三、零信任架构下 AIGC 数据防护体系

防护要在数据流动的过程中生效，而这正是传统边界模型失效的地方。

（一）边界模型为何失效

传统防护依赖一个前提：数据会经过哪些路径是事先清楚的，因此可以在这些路径上布置检查点，用一次授权管住后续访问。结论就是，必须把“以边界为中心加一次授权”换成“以数据为中心加持续验证”。前面提到的咨询公司事件的复盘落在同一结论上，即接口认证、注入校验、权限管控、异常监测多处同时失守，分属通道层、数据层与身份层，没有一处能靠加固边界设备解决。

智能体侧的风险结构相同，触发方式更隐蔽。今年 3 月，某头部科技公司一名工程师采纳了 AI 智能体给出的修复建议并合入代码，而该智能体持有远超任务所需的授权，变更随之生效，导致受限记录对未授权同事可见约两小时，被定为内部事件分级中次高级别的严重安全事件。问题不在建议本身，而在于他没有意识到给出建议的是一个拥有变更权限的身份。

图 5　数据外泄的“致命三角”与三条边的治理手段

（二）四层控制架构

落到架构，可按数据零信任的策略信息点、策略决策点、策略执行点三个角色把控制能力组织成四层（见表 3）。身份层的核心是把非人身份纳入统一治理，并把人工介入收敛到高风险动作上，逐动作人工确认很快会流于形式。通道层是重心，靠请求与生成的双向语义检测拦截注入与敏感数据外泄，并提防把恶意指令拆成无害子任务、分散在多轮对话中交付的渐进诱导。数据层难在分类分级必须动态化；溯源层则把上一章的取证能力接进防护体系，水印覆盖拍照与截图这“最后一跳”。

表 3　数据零信任架构下的 AIGC 场景数据防护四层控制

图 6　四层控制架构与数据零信任角色的对应关系

（三）关键控制点落地清单

架构给出的是边界，落地还要把每条控制拆成可核验的四要素，即控制项、对应风险、技术实现与产生的证据。最后一项最容易被省略，说不出留下什么证据的控制，在审计时就不存在。下表给出三组示例：

表 4　关键控制点与证据产出示例

（四）能力承接与验证设计

上述四层并非全部需要新建能力，其中相当一部分可由成熟的数据安全能力承接，即身份层由身份与角色鉴别、环境感知承接。数据层由数据资产发现与分类分级（依托数据格式识别库与分类模型库）、向量与知识库密级分区承接。通道与末端由数据安全沙箱、存储隔离与数据泄露防护承接。溯源层由文件流转日志、屏幕与点阵水印的取证链路承接。这套能力分别对应前文三类泄露场景，即打包外传靠通道识别与大规模读取发现，注入与越权靠双向语义检测与检索侧权限跟随，拍照截图靠水印把责任落回账号与时间点。

上述内容仍属能力对应关系，效果需要实测数据支持。为此，本文设计三项验证方案（见下表），验证的价值不只在证明能力有效，也在暴露边界，水印在何种变换下失效、拦截在哪些通道上有盲区，同样需要如实呈现。

表 5　三项待验证设计与观测指标

四、结论与建议

（一）技术结论

第一，单一证据面均不满足举证强度。身份、日志、水印三个面各自只能回答一个问题，即谁有权访问数据、经过哪条路径、从哪个账号外流，必须组合成链。而组合成链的前提是这些记录在事发之前就已就位。

第二，数据零信任架构在 AIGC 场景落地的关键动作只有两个：把 AI 智能体等非人身份纳入统一身份治理，并在通道层做双向语义检测，前者约束能力，后者约束输入输出。

（二）落地路径

建议分四步推进，先做资产与通道盘点（含各部门自行接入的影子 AI），再上通道管控与敏感数据脱敏，然后完成数据层分区与检索权限跟随，最后补齐身份、日志与水印三面取证能力并接入事件响应流程。

（三）监管建议

建议有两条，一是明确 AI 工具类产品的数据外传可审计要求，客户端在本地打包、加密并上传用户目录时，应提供企业侧可观测、可留痕的能力。二是把《个人信息保护法》第五十七条的通知要求与《网络数据安全管理条例》的三年保存期转化为可操作的记录与留存规范。

（本文作者：北京数安行科技有限公司郭灵）

CCIA数据安全工作委员会单位介绍

北京数安行科技有限公司（简称“数安行”）以DataSecOps为理念，以AI人工智能技术为核心驱动，聚焦数据运营安全，助力数字化转型，致力于让用户的数据安全地创造价值。公司以承载和保护每一个用户的数据运营安全为愿景，持续创新，合作共赢，成就用户。公司核心团队拥有二十余年网络安全与数据安全经验，服务于政府、军工、金融、运营商、互联网、教育、高端制造等各行业客户。