隐蔽式安全与正在阅读你 Wiki 的智能体

公司内部有一个安全运行了十年的端点。它位于一个除了原始团队之外没人能猜到的路径上。它不在公开文档中。它不在 OpenAPI 规范中。它不在网关的“已记录路由”白名单中。它的身份验证层是一个任何内部服务都可以签发的令牌，因为威胁模型认为，触达它的唯一前提是已经知道它的存在。这个端点接受一个 JSON 数据块，在某个平淡的周二，它会重新发放退款、轮换 API 密钥或在两个计费账本之间移动数据行。自 2016 年以来，它一直正常且平稳地工作着。

上个月，一位同事将一个编程智能体接入了工程维基，以协助处理入职提问。该智能体索引了每一个 Confluence 空间、每一份存档的设计文档、每一页标有“请勿删除——历史记录”的页面。昨天，一名初级工程师询问智能体退款是如何运作的。智能体将一份被遗忘的 2018 年架构图、有人粘贴到操作手册里的 Slack 导出记录以及一份写了一半的故障复盘拼接在一起。它用对话式的文字完整描述了该端点、所需的令牌类型以及示例 Payload。端点本身没有改变，但它的威胁模型改变了。

这种转变是微妙的，值得大声点破。该端点的安全态势之所以退化，并不是因为有人写了烂代码、部署了错误的配置或泄露了凭据。它的退化是因为“能够将文档语料库合成为一个可用请求的读者”群体，从“愿意花费数周进行侦察的坚定攻击者”，变成了“任何拥有聊天框和维基读取权限的调用者”。隐蔽性曾是一个预算项目——即攻击者枚举隐藏表面的时间成本。现在，这笔预算已被耗尽。

隐蔽性向来是时间税，而这项税收刚刚变得更廉价了

只要有安全存在，防御者就在争论“隐蔽安全性”（Security-by-obscurity）。这种争论的真实版本从来不是“隐蔽是一种控制措施”，而是“隐蔽提高了攻击成本，我们将它与真正的控制措施分层结合，因为预算是有限的，我们无法加固所有东西”。共享 URL 中的随机 UUID 从来不是保护私有文档与世界隔离的唯一屏障。它是一个“减速带”，为真正的防御措施（身份验证、审计、异常检测）争取发挥作用的时间。

减速带之所以有效，是因为枚举成本对攻击者来说扩展性极差。要找到一个无法猜测的路径，你必须知道它的存在，猜测它的大致形状，编写扫描器，规避速率限制，并在数小时或数天内关联各种信号。这一切都不是免费的。防御者拥有预算上的不对称优势：攻击者每次尝试都要消耗算力和时间；而对于未发生的尝试，防御者无需支付任何代价。

一个拥有你内部文档访问权限的智能体，将这种不对称性向一个方向瓦解了。智能体不通过猜测来枚举——它阅读描述表面的文档，所使用的算力预算与总结会议纪要相当。一个自 2019 年以来从未有人打开过的页面、一个有人导出到 Markdown 文件的 Slack 会话、一个粘贴到维基并被索引流程 OCR 识别的截图——所有这些都只需一次检索调用即可获得。隐蔽性所收取的“时间税”已降至大致相当于提示词补全的延迟。

《OWASP LLM 应用安全前十》已经连续两个版本在向这一点靠拢。在 2025 年版中，“过度代理”（Excessive Agency）被扩展，专门指出了智能体的工具表面和读取语料库超出其任务所需范围的失败模式。“敏感信息泄露”（Sensitive Information Disclosure）也被重写，涵盖了模型通过拼接其获权访问的文档，从而泄露系统架构细节的情况。其框架与本文一致：智能体的阅读语料库也是其攻击面的一部分，而大多数团队尚未将其作为攻击面进行审计。

内部文档语料库现在成了发现索引

上述智能体案例的爆炸半径并不仅仅是一个端点。该端点只是智能体在读取时免费构建的发现索引中的一个条目，无需任何人专门编写。每一份标明主机名的内部文档，每一张画着指向服务的箭头的架构图，每一份写着“我们使用这个内部工具进行 X”的入职指南，每一份解释端点行为原因的故障复盘——它们共同构成了一张攻击面地图，由一个能够响应关于“什么东西在哪里”的自然语言问题的检索系统建立索引。

随之而来的是一些令人不安的后果。

第一，文档的价值不再由谁阅读来决定。一个三年没被人类打开过的页面，在关键词匹配到问题的一瞬间，仍会被送入智能体的上下文中。那种认为旧文档因为没人能找到而无害的含混假设，在检索系统面前无法存续，因为检索系统的工作就是找到它。

第二，截图、导出文件、复制粘贴的片段和被遗忘的附件都是语料库的一部分。大多数公司都有文档政策，表面上禁止在维基中存放凭据。但很少有政策禁止记录架构细节、内部主机名或示例 Payload——而这些恰恰是入职文档应该包含的内容。旧政策是为那些必须先找到页面的读者编写的。现在读者变了。

第三，语料库的权限模型无法清晰地映射到端点的权限模型。端点可能需要 3 级服务令牌。而解释该端点的文档可能位于一个任何拥有公司 SSO 账号的人都能阅读的维基空间。在智能体出现之前，这两层是安全组合的：能读维基的人无法签发令牌，而能签发令牌的人没有动力恶意调用端点。有了代表调用者行事的智能体，这种组合就不再成立了——智能体以拥有维基访问权限的用户身份阅读文档，然后使用智能体持有的任何令牌调用端点，而这通常是为智能体平台配置的服务身份，而非针对具体用户的身份。

当威胁源是一个助手型 Agent 时，“加固”意味着什么

弥合这一差距并非一劳永逸。这是一场跨多个团队的姿态转变，而以下模式是我在 2026 年看到的真正奏效的方法。

审计发现面，而不只是端点。 大多数团队都有服务清单。但很少有团队掌握哪些文档、图表和导出会提及这些服务。真正关键的审计是关联：每一个内部端点以及指向它的文档页面图谱。将文档图谱视为攻击面清单的一部分。对于那些认证模型依赖 URL 保密性的端点，若有页面提及了它们，则应将其标记为需要屏蔽或需要对端点本身进行认证升级。大多数团队在第一轮审计中就会发现，有几个“仅限内部”的端点在五个不同的地方被描述过，其中三个就在 Agent 索引的语料库中。

让认证层名副其实。 这是一个乏味、正确但昂贵的答案。如果你端点的安全性在任何实质意义上取决于调用者不知道它的存在，那么认证层发挥的作用就比你想象的要小。将端点移至一套不会因路径公开而失效的认证模型之后——采用强服务身份、限定作用域的 Token、审计，以及针对每个身份（而非每个 IP）的频率限制。深度防御仍然需要将“隐蔽性”作为一个层级，因为低成本的防护层依然有其价值，但隐蔽性绝不能成为核心的承重层。它从来都不该是；Agent 只是让这一数学逻辑变得显而易见。

将 Agent 的阅读语料库与人类的阅读语料库分开。 这是大多数团队在实施时感到最惊讶的模式。默认的假设是 Agent 应该看到其用户所能看到的内容——同样的 Wiki 访问权限、同样的 Slack 频道、同样的共享驱动器。这种假设继承了数十年来的“广泛可读”默认设置，而那是一个阅读成本取决于人类注意力的世界。有了 Agent 之后，每一个可读的东西在功能层面上都已经被阅读了。正确的结构应该是两个语料库：一个是经过策划、刻意编写的 Agent 语料库，另一个是更广泛的人类语料库，Agent 默认不从中检索。是的，这意味着内容重复。是的，这意味着策划成本。这个成本本质上是你本来就该进行的审计工作的代价。

相比“带着良好的判断力阅读一切”，更倾向于白名单。 RAG 访问控制供应商两年来一直在兜售这种观点，而大多数团队一直礼貌地忽略它，因为白名单很繁琐。这里的选择不是在繁琐与优雅之间博弈，而是在繁琐与一个随着每次 Wiki 编辑而单调增长的发现面之间博弈。在向量层（而非提示词层）强制执行的文档级访问控制，是唯一不会随时间推移而默默扩张的配置。基于 Zanzibar 风格的细粒度检索授权目前已是成熟的基础设施，而非前沿研究；差距仅在于你是否愿意使用它们。

将 Agent 的服务身份视为独立的主体。 一个常见的错误模式是授予 Agent 其所有用户权限的并集。这样一来，Agent 拥有的权限集就是组织中任何一个人类都不曾拥有的，而这个权限集决定了 Agent 在响应提示词并采取行动时能做些什么。修复方法是：对于每一个超出读取边界的操作，将 Agent 的工具调用限制在请求用户的身份范围内，并使 Agent 自身的服务身份足够窄，使其独立无法触达敏感端点。Agent 应该必须“借用”用户的权限才能执行阅读以外的任何操作，且这种借用行为必须是可审计的。

无人预料的威胁模型更新

处理得好的团队并不一定拥有更好的工具。他们有一份将 Agent 视为参与者的威胁模型文档，并据此更新了受众估算。风险登记册中“发现 URL 的攻击者”这一项过去通常写着“可能性低，影响大，通过隐蔽性加认证层 X 缓解”。现在，同一行写着“可能性高，影响大，通过认证层 X 缓解”。可能性发生了变化，因为读者的群体发生了变化。缓解措施这一列缩减了，因为其中一项消失了。

更新威胁模型文档是成本最低的部分。昂贵的部分是它所暗示的审计：对端点清单和文档图谱进行全面清扫，对每一行询问同样的问题——如果这个端点的 URL 明天出现在公共文档的首页，它还安全吗？如果答案是否定的，那么隐蔽性层就是核心承重层，而这个载荷需要转移。大多数团队会发现，只有少数端点是把隐蔽性当做核心承重墙的，而更多的端点一直以来都分层正确；价值在于搞清楚哪些是哪些。

我见过这种审计被界定为安全项目，也见过它被界定为 AI 就绪项目，而后者的界定往往能更快获得预算。这没关系，工作内容是一样的。威胁并不是新鲜事——只要有人编写威胁模型，隐蔽性一直是一个脆弱的控制措施——但读者的群体发生了变化，使得这种弱点第一次在业务操作层面变得显而易见。Agent 并没有创造漏洞，它只是公开了漏洞。

前瞻性展望

未来 18 个月将发生两件事，这两件事都值得提前布局。

第一件事是 Agent 的阅读语料库将不断扩大。新的连接器（connectors）会陆续接入——包括你的工单系统、事件回顾工具、共享驱动器以及客户支持归档。每个连接器都带有自己的访问模型，并默认读者是人类。除非明确限定范围，否则每一个连接器的接入都会扩大发现面（discovery surface）。保持语料库精简的工作并非一次性审计；它是一项常态化审查，其频率应与添加新数据源的频率保持一致。

第二件事是 Agent 的行为将成为攻击面（surface）本身的一部分。随着 Agent 开始根据阅读的文档采取行动——如发起 Pull Request、提交工单、调用工具、起草邮件——“以隐晦作为安全层”的框架将从端点延伸到动作中。某个动作以前是安全的，仅仅是因为没有人类想到去执行它；而现在它将变得不再安全，因为 Agent 会从文档中推断出它应该执行该动作。同样的原则依然适用：不要让鉴权模型依赖于调用者不知道该动作的存在。

最后，架构层面的认识正如主题本身所言。“通过隐晦实现安全”（Security by obscurity）向来只是一项预算开支。它买到了时间，而这些时间是以攻击者的工时为代价支付的。这项开支并未被删除，只是费率变了。数小时缩短到了数秒，而这些秒数属于你的团队上个季度安装的一个调用者（caller），且自那以后从未有人审计过它的阅读权限。端点没有改变，但其周围的模型变了。像审计代码一样审计文档，并将鉴权边界移动到它本该存在的地方。