82 篇博文 含有标签「security」

某零售采购智能体在"初始测试期间"继承了供应商 API 凭证，却没有人在系统投产前对其加以限制。当一个差一错误触发后，该智能体拥有完全的下单权限——永久生效，毫无限制。等财务部门察觉时，已有价值 47,000 美元的未授权供应商订单发出。代码没有问题，模型也按设计运行。造成如此大破坏的，是权限问题。

这就是最小足迹原则：智能体应仅请求当前任务所需的权限，避免在任务范围之外持久化敏感数据，清理临时资源，并将工具访问权限限定于当前意图。这是 Unix 最小权限原则在新时代的延伸——在这个时代，代码会在运行时自主决定下一步需要做什么。

团队之所以在这里屡屡犯错，并非出于疏忽，而是概念错误：他们把智能体权限当作设计时的工作，而智能体 AI 使其成为了运行时问题。

大多数团队都是在用户发现问题之后，才意识到自己的提示注入防御已经失效。你把"忽略所有先前指令"加入屏蔽词列表，然后上线。三个月后，攻击者将载荷进行 Base64 编码，或将指令藏在 RAG 检索到的 HTML 注释里，或使用错字混淆手法（"忽略所有之前的指示"），你的防御瞬间土崩瓦解。屏蔽词列表无济于事，因为提示注入的攻击面是无界的——不存在封闭的恶意输入词汇表。

在流量较低时，你可以承担为每个请求调用第二个 LLM 进行验证的成本。但在每天十万次请求的规模下，这笔账算不过来，延迟也会让用户明显感知。本文探讨的是当暴力解法失效后，架构应该如何设计。

大多数构建多租户 RAG 系统的团队在身份验证（authentication）上做得很好，但在授权（authorization）上却做得不对。他们验证用户确实是其所声称的身份，然后从共享向量索引中检索文档，并在将结果发送给 LLM 之前对其进行过滤。这种过滤——即检索后过滤——只是“安全防御的假象”（security theater）。当你从列表中移除未授权文档时，它们已经处于模型的上下文窗口中了。

真正的问题比放错位置的过滤器更深。大多数 RAG 系统将文档授权视为摄取时（ingest-time）的关注点（“该用户可以上传此文档吗？”），但完全未能在查询时（query-time）强制执行（“该用户可以查看与此查询匹配的文档吗？”）。这两个检查点之间的差距就是静默数据泄露发生的地方——也是大多数生产事故的根源。

大多数 AI Agent 架构都存在一个悄无声息的安全问题，直到出了事才会被发现。你构建了 Agent，用应用现有的服务账户凭证将其接入内部 API，上线生产，然后继续下一个任务。Agent 正常运行，用户很满意。而与此同时，在你的审计日志里，一个服务账户身份正在悄悄触碰 Agent 曾经需要访问的每一条客户记录、每一张账单表和每一份内部文档——却没有任何痕迹说明是哪个用户发起了什么请求，又是为什么。

这不是一个理论风险。当安全事件发生，或者当监管机构询问"3 月 14 日谁访问了这份数据"时，答案每次都一样：[email protected]。每一个操作、每一次请求、每一次读写——全部归结为同一个身份。审计记录在技术上是正确的，但在取证层面毫无用处。

我尊重的一位资深分析师这样描述她的团队在使用大语言模型 (LLM) 驱动的分拣代理的前六个月：“它让简单的告警消失了，却让复杂的告警变得更难信任。”这句话一直让我记忆犹新，因为它捕捉到了这项权衡的本质。安全运营中心 (SOC) 中的 AI 并不是一个关于效率提升的故事。它是一个关于信心校准的故事，而大多数团队都在朝着同一个错误的方向进行校准。

诱人的版本是：在告警队列前放置一个模型，让它聚类重复项、总结原始事件并自动关闭明显的噪音。MTTR（平均响应时间）图表下降了。寻呼机安静了。一级告警积压蒸发了。而真正导致你被入侵的版本是：模型自信地将一次真实的入侵误判为无害的备份作业，而一名疲惫的分析师——被告知“AI 已经分拣过了，没问题”——甚至从未打开过这个案例。第一个版本是真实的，第二个版本也是。它们是同一个系统在不同信心水平下的表现。

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 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 访问权限和生产系统的凭证。