问题所在：看不见，就无法治理
智能体早已存在。一个持有数据库凭证的编码助手、一个悄然获得了对象存储写权限的内部 RAG 服务、一个调用着无人登记的 MCP 服务的定时任务。它们由高速推进的团队完成配置，而安全团队在从未见过这张地图的情况下，就继承了它们的爆炸半径。分析机构为这种形态起了一个名字——智能体蔓延——而它之下的治理缺口是可以量化的。
在那些遭受了 AI 相关数据泄露的组织中，约有 97% 缺乏适当的 AI 访问控制（IBM《2025 年数据泄露成本报告》，Ponemon）。这并非一个工具成熟度的故事；这是控制面的彻底缺失。与此同时，Gartner 预计到 2027 年底，超过 40% 的智能体 AI 项目将被取消，并预测到 2030 年，「守护型智能体」将占智能体 AI 市场的 10–15%（Gartner，新闻稿）——市场正在将一个事实计入定价：未经治理的智能体无法挺过一次真正的安全审查。
这种现象的影响范围比安全团队更广。在一项尚未经过同行评审的初步研究中，约 95% 的 GenAI 试点未表现出可衡量的损益影响，而外购工具的成功率约为内部自建工具的两倍（MIT「GenAI Divide」，NANDA 项目，经 Fortune 报道，2025 年 8 月——初步结论）。无论原因为何，一个充斥着无人能说清的智能体的环境，恰恰是泄露风险与试点失败风险同时叠加的温床。
这与 AI TRiSM（面向 AI 的信任、风险与安全管理）框架完全吻合——在该框架中，治理与运行时检查是两个独立的层。Olivares AI 正是为充当发现、观测并治理智能体访问的那一层而构建的，并且对它的能力边界保持诚实。
Olivares AI 为安全负责人提供什么
一张带类型的读/写访问地图，作为控制面
访问地图将每一个智能体建模为一个节点，并将它能触及的每一项资源——数据库、对象存储、MCP 服务、API、消息队列——也建模为一个节点，每条边都标记类型 R（读）或 RW（读写）。这种 R 与 RW 的类型区分正是关键所在：最小权限漂移和事件爆炸半径都是写权限的函数，而非单纯的可连通性，而一份扁平的「拥有访问权」清单恰恰掩盖了这一点。这是为防御者准备的侦察图——与攻击者想要的那张地图相同，但为守护这片环境的人而构建。
读取完整图谱被特意设计为一项需要特权、按租户限定范围、并且全程审计的操作，因为一份关于每个智能体能触及什么的完整地图，本身就是一张侦察路线图。这张地图存储的是关系——来源、资源、R/RW、数据源、置信度、时间戳——而绝不存储流经这条边的载荷、SQL 语句体、密钥或 PII。没有存储的东西，就无从泄露。
授权 vs 实际行为：成为发现的那个差异
每条边都携带两个相互独立的事实：该访问是否被授权（某项授予或策略允许它），以及它是否被观测到（遥测与原生审计显示它确实发生过）。这两层之间的差异就是控制信号：
- 意外访问——观测到但未授权。某个智能体触及了没有任何授予覆盖的对象。这是安全方面最值得关注的头条。
- 未使用的授权——已授权但从未被观测到。这是您实实在在的最小权限清理清单，而非一句含糊的「去复查一下您的 IAM」提醒。
这种差异比对刻意保持保守。在平台尚无法把一个执行操作的凭证与其授权所针对的智能体牢固关联起来时，该边会被标记为 reconciliation_pending——这是诚实的不确定，绝非凭空捏造的违规。完整的对账契约请参见授权 vs 实际行为。
拒绝虚张声势的保真度
一个夸大自身所知的安全工具，比没有工具更糟。每条边都携带两个诚实的维度。R/RW 分类的覆盖度分为 clean | lossy | opaque 三档——在原生审计使其毫无歧义之处标记为 clean（通过 pgAudit 的 Postgres、通过 CloudTrail 的对象存储、各类数据仓库，外加一道内核级 eBPF 兜底），一直到 opaque 存储（Redis、SQLite、D1），在那里读写模式会被标记为 unknown，而非靠猜测。归属在每个智能体的身份信号能够将访问解析到唯一智能体时为 firm，而在共享服务账户掩盖了究竟是哪个智能体执行操作时为 approximate。一条 clean/firm 的边与一条几乎未被观测到的边，绝不会被渲染为同样确定——请阅读保真度模型。
默认拒绝的治理、双人控制与紧急停止开关
治理是读优先且默认拒绝的。授权内核采用默认拒绝并按租户限定范围，从结构上消除了混淆代理人（confused deputy）与 IDOR 这两类问题。您在其上接入的任何基于属性的策略都只能进一步收紧——这种组合是一次取交集运算，因此策略永远无法放宽某项授予。
在产品对某项操作设置关口的场景下，其闭环是：某个界面呈现内容（漂移、某项发现）→ 一位经授权的操作者做出决定 → 该决定被记录在案。审批引擎强制执行职责分离（请求者不能批准自己的请求）以及一道重复决策者防护，并以稳定的人类身份为键——系统令牌没有身份，因此无法做出决定。一项 critical 操作携带一条源自 NIST SP 800-53 AC-3(2) 的强制双人底线，在创建时和决策时都会重新推导并强制执行，因此即便某条操作者策略调低了等级，也无法让一项关键操作由单人完成。一个经审计的**紧急破玻璃（break-glass）**通道为凌晨 03:00 的事件而存在——从结构上就很「响亮」、需经硬件强化升级、有时间限制，并被强制纳入事后复查。
紧急停止开关是覆盖整个环境的拒绝关口。触发它被特意设计得代价低廉（管理员级、附一条理由、无需法定人数），因为一个要等待共识的「停止」根本算不上停止；每一道受治理的执行关口都会实时查询这一停止状态行，并在读取出错时默认拒绝（fail closed）。重新启用绝不能单方面进行——它以一次全新的双人控制审批为前提，且没有任何破玻璃通道，因为「环境保持停止」就是那个安全状态。
防篡改的证据
每一项产生变更的操作都会在与该变更相同的事务中，连同真实的执行者一并追加到一个仅追加、哈希链式的审计账本中；敏感的读取操作会以一次已提交的写入完成自审计。任何改写历史的行为都可被检测，而账本中永远不含 PII。合规模块会将这些运行时证据映射到各类控制框架上，使一次评估能够以观测到的真实情况为依据，而非一份问卷。
它是什么——以及它不是什么
- 自托管且自主可控。 控制面运行在您自己的基础设施上，并且可以物理隔离。Olivares AI 是一个开放、可自托管的平台（AGPL-3.0）。参见安全模型与架构。
- 默认检测；在采取行动之处默认拒绝。 它广泛地观测与治理；它不会广泛地执行操作。在它能够采取行动之处，该界面要么是实时的、按需触发的，要么是一个明示的接缝——而模块目录标明了具体属于哪一类。缺少强制执行，通常是出于设计考量。
- 处于 1.0 之前，已发布一份包含 23 个模块的目录（其中约 20 个已接入）。 并非所有功能都已上线；我们会说明各自的状态，而不是暗示已实现完整覆盖。
- 物理隔离适用于 Olivares 控制面，而非您的模型。 像 Claude 这样的托管模型永远无法物理隔离；只有自托管模型（vLLM、Ollama）才能离线运行。无论哪种情形，Olivares 都会治理访问。
- 未经认证。 Olivares AI 设计面向 SOC 2、ISO/IEC 42001 与 EU AI Act；它不持有任何认证，我们也不声称拥有认证。
高等教育与科研机构的环境也面临着这一问题的平行版本——AI 在教职员工中被广泛使用，而正式的 AI 治理与可接受使用政策的覆盖却滞后于此（EDUCAUSE 研究，2025 年）。如果这正是您所处的情境，请参见高等教育；负责运维基础设施的平台团队应从平台工程开始了解。