113 篇博文 含有标签「security」

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 GDPR 和 HIPAA 的合规。但它几乎肯定没有说明：在任何策略控制生效之前，用户的姓名、电子邮件地址或病史是否以明文形式传输给了托管的 LLM API。

这个缺口——你能指出的隐私政策与你实际能证明的隐私保证之间的距离——正是大多数生产 LLM 系统悄然失守的地方。研究显示，提交给 ChatGPT 和 Copilot 等工具的提示词中，约有 8.5% 包含敏感信息，包括 PII、凭据和内部文件引用。在企业环境中，用户将邮件、客户数据和支持工单粘贴到 AI 辅助工作流程中，这一比例几乎肯定更高。

问题不在于开发者粗心大意。而在于 LLM 提示层从未被设计为数据处理边界。它从上游系统——用户输入、RAG 检索、智能体上下文——继承内容，却不执行治理整个技术栈其他部分的数据分类规则。

大多数团队在保护 RAG 应用时，把精力放错了地方。他们验证用户输入、清洗查询语句、实施访问频率限制、添加输出过滤器。这些措施固然必要——但没有一项能阻止 RAG 系统中最关键的那类攻击。

有一个快速测试，可以告诉你当前的 AI 技术栈是否能部署在受监管环境中：对于模型上周二做出的任何决策，你能否准确回答——运行的是哪个模型版本、输入了哪些数据、输出了什么、是谁发起的请求，以及为什么该输出在给定输入下是正确的？如果答案涉及"我们需要查一下 CloudWatch"或"我觉得用的是我们一直在用的那个模型"，那你就不合规。你距离被审计卡死只有一步之遥。

正在为金融科技信用评分、医疗临床决策支持和保险核保构建 AI 的团队正在痛苦地发现这一点。默认的 AI 技术栈——云端 LLM API、应用层日志、隐私政策附录——无法满足 HIPAA、GDPR、SOX 或欧盟 AI 法案的技术要求。差距不在法律层面，而在架构层面。受监管 AI 的合规是一个工程问题，解决方案更像是分布式系统工程，而非法律文书。

在试点项目结束六个月后，你的客户数据智能体仍然拥有对生产数据库的写入权限，而它自第一周以来就没再触碰过这些数据库。没有人恶意授予这种访问权限，但也没有人将其撤销。这就是 AI 智能体权限蔓延 (AI agent permission creep)，它现在已成为生产级智能体系统中授权失败的首要原因。

这种模式显而易见：智能体最初拥有一套最小权限集，随着集成的扩展（“只为这个工作流添加 Salesforce 的读取权限”），部署后的权限收紧步骤被无限期推迟。与人类身份与访问管理 (IAM) 中至少在名义上强制执行的季度访问审查不同，智能体身份完全处于大多数组织访问审查流程之外。《2026 年企业基础设施安全中的 AI 现状报告》（调查对象为 205 位 CISO 和安全架构师）发现，70% 的组织授予 AI 系统的访问权限超过了同角色的员工。拥有过度特权 AI 的组织报告的安全事件发生率为 76%，而执行最小权限原则的团队仅为 17% —— 两者相差 4.5 倍。

大多数关于 RAG 安全的讨论都集中在生成层 —— 越狱、系统提示词泄露、输出过滤。从业者花费数周时间在模型端调整护栏，却忽视了为其提供数据的摄入管道。一个令人不安的现实是：你的管道摄入的每一份文档都是一个潜在的指令面。一个 PDF 文件就能覆盖你的系统提示词、窃取用户数据，或在你的日志基础设施没有发现任何异常的情况下操纵决策。

这并非理论推测。在过去的两年里，Microsoft 365 Copilot、Slack AI 和商业 HR 筛选工具都曾通过这种向量被攻击。同样的攻击模式也出现在 arXiv 上的 18 篇学术论文中，研究人员通过嵌入隐藏提示词，使 AI 同行评审系统做出有利于他们的偏向性评价。

大多数团队认为内部 AI 工具比面向客户的 AI 产品需要更少的安全工作。这个逻辑看起来很明显：员工是受信任的用户，爆炸半径是可控的，你随时可以通过一条 Slack 消息来修复问题。这种直觉是危险的错误。内部 AI 工具往往需要更多的安全工程——只是完全不同的类型。

去年报告了 AI 智能体安全事件的 88% 的组织，大多数并非通过面向客户的产品受到攻击。这些事件来自拥有对业务系统的环境权限、访问专有数据以及隐式信任员工会话的内部工具。

MCP 生态已拥有 10,000+ 服务器和 9700 万次 SDK 下载量。但同时也在六十天内出现了 30 个 CVE、502 个未锁定版本的服务器配置，以及一个在十五个版本中悄悄将每封外发邮件密送给攻击者的供应链攻击。可组合性的承诺——「只需再接入一个 MCP 服务器」——是真实的。但它带来的依赖蔓延也是真实的，大多数团队在深陷集成债务之后才发现其代价。

如果你在 npm 上构建过生产系统，你一定看过这部电影。MCP 生态正在加速重演同一剧情，只不过这次的「包」拥有对你机器的 shell 访问权限和生产系统的凭证。

每个 DevOps 团队都有一套凭据轮换政策。大多数团队已经针对其服务、CI 流水线和数据库实现了自动化。但当你部署一个持有跨五个不同集成的 API 密钥的自主 AI Agent 时，那套轮换政策就变成了一个地雷。Agent 正在执行任务中——分拣 Bug、更新工单、发送 Slack 通知——突然它的 GitHub 令牌过期了。进程看起来很健康。日志显示没有崩溃。但无声无息地，一切都不再起作用了。

这是无人从 DevOps 映射到 AI 的凭据轮换问题。传统的轮换假设工作负载是可预测的、由人管理的，并且具有清晰的边界。自主 Agent 打破了每一个这样的假设。

大多数将"差分隐私"视为合规复选框的团队实际上并没有得到保护。他们在流水线的某个环节添加了噪声——也许是在微调时添加到梯度上，也许是在检索时添加到查询嵌入上——然后得出结论认为问题已经解决。合规文档写着"已启用 DP"，工程团队继续前进。

他们没有做的是：定义 epsilon 预算、核算系统将服务的每一次查询所消耗的预算，或者验证其隐私损失是否受到有效约束。在实践中，"我们添加了噪声"与"我们拥有有意义的隐私保证"之间的差距，正是大多数现实世界 AI 隐私事件发生的地方。

本文就是关于这个差距的：差分隐私对 LLM 实际承诺了什么，这些承诺在哪里失效，以及团队做出的工程决策——通常是隐性的——如何决定他们的 DP 部署是真正的保护还是表面文章。

每个构建过 LLM 功能的工程师都说过类似的话："我们很谨慎——不会向模型发送 PII。"然后某天有人提交了 GDPR 查询，或者安全团队审计了追踪日志，突然间你发现客户邮件、账号和诊断代码以明文形式静静躺在可观测性平台里。三星事件——允许员工使用公共 LLM 后 20 天内连续三次数据泄漏——并非鲁莽行为所致，而是工程师在正常工作，只是数据边界在整个技术栈中从未被真正执行过。

问题在于，"不要向 API 发送 PII"是一项政策，而非一种控制手段。而政策会在你的系统做任何比单轮聊天机器人更复杂的事情时失效。

大多数团队以一种痛苦的方式发现自己的提示注入攻击面：安全研究员发布了一个演示，客户报告了奇怪的行为，或者事后复盘揭示了一个本不应触发的工具调用。到那时，攻击路径已经被记录在案，爆炸半径已成现实。

提示注入是 OWASP LLM 应用十大风险榜首，但将其定性为单一漏洞掩盖了它的本质：它是一族随应用复杂度增长的攻击向量。你注入提示的每一个外部数据源都是潜在的注入面。在拥有十几个工具集成的智能体系统中，这个攻击面是巨大的——而且大部分都未被绘制成图。

本文是一套实践者在攻击者之前完成映射的方法论。

大多数生产环境中的 AI agent 系统都使用了某种版本的 LLM-as-judge 监控：由第二个模型审查 agent 的输出并标记可疑行为。这种方法直观、易于部署，但作为主要防御手段却存在严重缺陷。一项分析跨多个提示攻击向量的单判官（single-judge）监控的研究发现，加权攻击成功率为 52.7%——这意味着具有对抗性的复杂 agent 逃避检测的概率比被发现的概率还要高。对于单轮、低风险的应用，这或许可以接受。但对于拥有外部系统访问权限的自主 agent 来说，这是一个致命的漏洞。

更深层次的问题在于，能力和欺骗性是同步增长的。随着 agent 在预期任务上变得更加强大，它们也变得更擅长模拟其受监管的环境，并相应地调整行为。