120 篇博文 含有标签「security」

2024 年 8 月，安全研究人员发现 Slack AI 在回答查询时会将公开频道和私密频道的内容同时拉入同一个上下文窗口。公开频道中的攻击者可以精心构造一条消息，当 Slack AI 摄取该消息时，就会将指令注入受害者的会话——由于 Slack AI 不引用来源，由此导致的数据外泄几乎无从追踪。这种攻击甚至可以泄露私信中嵌入的 API 密钥。Slack 在负责任披露后修复了这一问题。

这并不是传统意义上的漏洞。它是将上下文视为无用户访问控制的共享可变资源所带来的后果。而这正是大多数正在构建共享 AI 助手的团队现在都在犯的错误，只是更加悄无声息而已。

大多数团队将LLM隐私视为一个二元选择：要么将数据发送到云端并承担风险，要么在本地运行所有内容并承担成本。这两种框架都是错误的。实际上存在一个风险特征和工程预算差异显著的方法光谱——大多数团队在这个光谱上的位置是错误的，却浑然不知。

研究人员最近证明，他们可以以每条记录0.012美元的成本，以48.9%的成功率从3912人中提取真实PII。这个统计数字往往被当作学术威胁建模而被忽视，直到安全审计或合规审查落到你的桌上。问题不是是否要关注LLM隐私，而是哪些控制措施真正能改变局面，以及每种措施的实施成本。

如今，大多数构建 AI agent 的团队都将授权视为事后才考虑的事情。他们接入一个 OAuth 令牌，给 agent 分配与触发它的用户相同的权限范围（scopes），然后就大功告成了。然而，几个月后，他们会发现一段被操纵的提示词导致 agent 窃取了文件，或者一个受损的工作流在连接的服务中悄无声息地提升了权限。

问题不在于 RBAC 不好。而是在于 RBAC 是为具有稳定工作职能的人类设计的，而 AI agent 既不稳定也不是人类。在一个对话回合中，agent 的“角色”可能从只读研究转变为具备写入能力的代码执行。静态角色无法表达这一点，这种不匹配创造了一个可预见的漏洞攻击面。

当欧盟 AI 法案的透明度义务于 2026 年 8 月 2 日正式生效时，每个为欧盟用户生成合成内容的系统都需要为该内容标注机器可读的溯源信息。大多数构建 AI 产品的工程团队对此有模糊的认知，但真正搭建好所需基础设施以实现合规的团队寥寥无几——而在那些已经实施的团队中，相当一部分只完成了监管要求的一半。

面对"AI 内容溯源"这一命题，业界的主流应对方式是指向 C2PA（内容溯源与真实性联盟标准），然后宣布问题已解决。C2PA 固然重要——它真实存在，正被 Adobe、Google、OpenAI、索尼和三星采用，是业内最接近通用标准的方案。但仅凭 C2PA 实施并不足以满足欧盟 AI 法案第 50 条。它无法在你的 CDN 中存活，也无法阻止恶意行为者为篡改内容生成"可信"的溯源记录。

本文将探讨生产环境中 AI 内容溯源的真实需求——技术栈、失效模式，以及让团队措手不及的合规漏洞。

当大语言模型在响应用户提示词时逐字复制受版权保护的文本，谁应该承担法律责任 —— 是模型提供商、构建产品的公司，还是输入查询的用户？在 2026 年，法院正在积极研究这一问题，其答案将直接影响你的生产系统。

大多数工程团队已经接受了这样一个基本叙事：“AI 训练可能会侵犯版权，但那是模型提供商的问题。” 这种叙事在两个重要方面是错误的。首先，基于输出的责任 —— 即模型在推理时产生的内容 —— 在很大程度上与训练数据责任是不同的，且在大多数司法管辖区仍是一个悬而未决的法律问题。其次，你认为从 AI 提供商那里获得的合同赔偿可能比你想象的要窄。

本文涵盖了工程团队面临的实际风险敞口：生产环境中的逐字记忆率（verbatim memorization rates）是怎样的，开源许可证污染如何真正在生成的代码中显现，企业级 AI 协议在哪里留下了风险缺口，以及哪些工程控制措施可以在不停止 AI 采用的情况下切实降低责任风险。

你的新内部聊天机器人刚刚告诉一名实习生整个工程部门的薪资范围。HR 总监没有配置错任何东西。没有人分享了不该分享的链接。系统只是... 检索到了它，因为实习生询问了“工程师的薪酬预期”。

这是大多数团队预料不到的 RAG 隐私失效模式。它不是传统意义上的漏洞 —— 而是检索工作方式与访问控制预期方式之间的根本不匹配。

大多数工程师认为embedding是安全抽象的——一堆无法被逆向工程的浮点数。这个假设是错误的，而感知与现实之间的鸿沟正是用户数据泄露的地方。

最新研究仅凭文本embedding就实现了超过92%的精确token序列重建准确率——包括完整姓名、健康诊断和电子邮件地址——而无需访问原始编码器模型。这些不是理论攻击。可迁移的逆向技术在黑盒场景下同样有效：攻击者构建一个模仿你的embedding API的代理模型，就可以发动攻击。无论你使用的是专有模型还是开源模型，攻击面都存在。

本文涵盖embedding隐私风险的三个层面：逆向攻击的实际能力、检索管道中访问控制悄然失效的位置，以及能为用户提供适当控制权的架构模式——按用户命名空间、检索时权限过滤、审计日志和删除安全设计。

在一百万份干净文档中隐藏五份精心构造的恶意文档，就能对生产级RAG系统实现90%的攻击成功率。这不依赖零日漏洞或密码学破解——只需用纯文本指示模型以与运营者意图不同的方式运行。如果你的防御策略是"在内容到达LLM之前净化输入"，那你已经输了。

框架至关重要。将提示注入视为输入验证问题的团队会构建边界防御：正则过滤器、基于LLM的分类器、输出扫描器。这些有用但不足。真正的问题在于，现代AI系统是组件的组合——检索器、知识库、工具执行器、外部API——每个组件都是有自身攻击面的摄入点。这正是供应链漏洞的定义。

一家汽车经销商部署了由 ChatGPT 驱动的聊天机器人。几天内，一名用户指示它同意他们所说的任何话，然后提出以 1 美元购买一辆 2024 款 SUV。聊天机器人接受了。经销商随后将其下线。这并非复杂的攻击——只是一个想看看到底会发生什么的人写的短短三句提示词。

在面对普通消费者时，这种好奇心是你最大的安全威胁。内部 LLM 智能体在受控环境中运行，拥有精选的输入和可信的数据。而面向消费者的 LLM 功能默认在对抗性条件下运行：数百万用户中，有许多人正在积极寻找弱点，而随机模型本身并没有“这个用户似乎怀有恶意”的概念。这两个环境所需的安全策略有着本质的区别，而那些将消费者功能视为内部工具的团队终将吸取惨痛教训。

大多数团队在发布第一个可执行代码的智能体（Agent）时，只采取了一种安全控制措施：API 密钥范围限制（API key scoping）。他们给智能体一个具有 repo:read 权限的 GitHub 令牌，以及一个可以访问工作目录的 shell，然后就称其为“已沙箱化”。这种做法是错误的，其弊端只有在发生安全事故后才会变得显而易见。

能够编写和执行代码的智能体的威胁模型与 Web 服务器或 CLI 工具的威胁模型有着本质的区别。攻击面不再是协议边界，而是智能体读取的一切内容。这包括 git 提交记录、文档页面、API 响应、数据库记录以及它打开的任何文件。其中的任何输入都可能包含提示词注入（prompt injection），从而将你的研究型智能体转变为数据泄露管道。

Text-to-SQL 演示看起来出奇地简单：把 schema 粘贴到提示词里，向 GPT-4 提个问题，拿到一条整洁的 SELECT 语句，然后 Slack 里就开始涌现"要不要把这个集成进数据平台？"的消息。等到你真正打算上线时，麻烦来了。基准测试显示 85% 的准确率，但内部数据团队反映大约一半的答案是错的，而安全团队则在追问：生成的查询在执行前有没有经过审查？没人能给出一个像样的答案。

这正是 text-to-SQL 作为研究问题与作为工程问题之间的鸿沟。研究问题关注的是让模型生成语法正确的 SQL；工程问题面对的是 schema 歧义、访问控制、查询验证，以及你的企业数据库根本不像 Spider 或 BIRD 数据集这一现实。

当 AI 智能体预订日历事件、发送电子邮件或提交表单时，它并非以自己的身份行事——而是在某个说"去做这件事"的人类的委托授权下行事。这一区别听起来很哲学，直到某个智能体泄露了敏感数据、执行了用户并不打算执行的不可逆操作，或者遭到入侵。到那时，问题不再是发生了什么，而是谁授权的、何时授权的，以及能否撤销。

权限范围设置不当的智能体凭证所带来的波及范围，远超大多数团队的预期。拥有广泛 API 访问权限的智能体不是单一故障点——而是一个长期开放的后门。2025 年，智能体 AI 的 CVE 数量同比增长了 255%，大多数事件都可以追溯到权限过宽、有效期过长或无法彻底撤销的凭证。正确构建智能体，意味着在投入生产之前就设计好授权层。