2 篇博文 含有标签「dlp」

你的 AI 团队将系统提示词（System Prompt）视为专有知识产权（IP）。部署流水线会将其从每一个客户可见的界面中剥离。针对生产环境调试的操作手册（Runbook）要求工程师在任何故障产物（Incident artifact）离开作战室（War room）之前，通过 grep 将其过滤掉。你的上一次安全审查捕获并封堵了三条不同的提示词泄露路径：过于冗余的 API 响应、发布到错误层级的调试请求头（Debug header），以及将提示词嵌入到消息中的堆栈跟踪（Stack-trace）端点。

但在某个早晨，这一切都变得毫无意义：一名工程师加入了一个关于无关账单争议的供应商支持电话，通过屏幕共享展示他们的终端以演示堆栈跟踪信息。而该回溯信息中包含了一行详细的日志，完整打印了完全解析后的提示词——每一个注入的变量都已被替换，包括针对特定客户的业务规则和内部模型路由提示。供应商的支持工程师按照标准支持工作流录制了通话。录音随后进入了供应商的工单管理系统。现在，提示词被清晰地存储在了一个第三方 SaaS 中，而你的安全审查与其没有签订合同，没有签署数据处理协议（DPA），也没有审计权。

第一个内部 LLM 网关的构建通常是出于那些枯燥的原因：成本归因，以便财务可以回答“哪个团队花了推理预算”；速率限制，防止某个失控的脚本烧掉月度配额；以及供应商故障转移，确保 OpenAI 的小故障不会导致助手挂掉。数据泄露防护 (DLP) 虽然出现在幻灯片上，但交付时却变成了“每个应用团队在调用模型前应自行脱敏敏感字段”。六个月后，生产环境中有九个应用，三个维护得半吊子的脱敏库（带有微妙差异的正则表达式集），两个完全绕过网关“仅用于测试”的原型，以及一起 Prompt 中包含客户数据的事故——而这本该是由每个人的中间件来防止的，因为并没有人的中间件是规范的出站口。

这不是工具问题，而是架构错误。DLP 是一种出站控制，而出站控制只有在路径强制执行时才有效。当你让应用团队负责脱敏时，你就放弃了让 DLP 发挥作用的特性——即敏感数据只能从一个地方流出，且你可以证明流出了什么。2025 年的 LayerX 安全报告用大多数团队尚未意识到的数据说明了问题的规模：2025 年初，与生成式 AI (GenAI) 相关的 DLP 事故增加了一倍多，目前占 SaaS 流量中所有数据安全事故的 14%，员工平均每天向 GenAI 工具粘贴 6.8 次内容，其中超过一半包含公司信息。影子路径默认在胜出。