读/写访问映射是所有功能的基础数据结构。理解了它，就理解了整个产品。
节点和类型化边
映射是一个图。代理是节点。它们能访问的资源——数据库、对象存储、MCP 服务器、API、队列——也是节点。每条边是一个类型化的访问关系：R（代理可以读取资源）或 RW（代理可以读取和写入资源）。
将每条边标记为读或写是有意为之的。最小权限原则和事件爆炸半径都取决于写权限，而非单纯的连接性。一个只能读取数据仓库的报告代理和一个可以重写数据仓库的部署代理，风险完全不同，而一个扁平的”有访问权限”列表恰好掩盖了这一点。
允许与观测
映射承载两个层次，并持续对它们进行差异比较：
- 允许（Permitted） ——代理被允许做什么，来源于授权和策略。
- 观测（Observed） ——代理实际被观察到做了什么，来源于遥测数据和原生审计日志。
差异是价值所在：
- 意外访问 ——一条被观测到但未被预期的边。这正是安全团队真正希望浮现的发现。
- 未使用的授权 ——一条被允许但从未执行的边。这是你具体的最小权限清理列表，而非模糊的”审查你的 IAM”提醒。
实时产品演示展示了这种覆盖在真实捕获数据上的效果。
保真度分层——并予以展示
映射的质量取决于数据源能证明什么，它会如实说明而非伪装。每条边展示两个独立轴：
- 读/写的覆盖范围：
clean——原生审计使 R/RW 明确无误（通过 pgAudit 的 PostgreSQL、通过 CloudTrail 的对象存储、数据仓库和数据湖）。lossy——部分信号，例如某些文档和向量存储。opaque——无法被动重建（Redis、SQLite、D1）。边被标记为unknown而非猜测。
- 归因：
firm——数据源携带按代理粒度的身份信息。approximate——共享服务账户隐藏了哪个代理执行了操作。
因为两个轴都跟随边传递，一个确信已知的关系和一个勉强可见的关系永远不会被渲染得同等确定。
读优先设计
构建这个映射是一项观测活动，而非拦截活动。Olivares AI 不处于代理与其资源之间的请求路径中；它在带外摄取遥测数据和原生审计日志。查看映射本身是一项特权操作，限定于租户范围并完全受审计。产品优先观测和治理；在能够采取行动的地方，它以默认拒绝方式执行——绝不作为全面执行器。
相关内容
- 什么是 Olivares AI？ ——一页了解产品。
- 快速入门 ——在演示环境中查看映射。
- 架构 ——各组件如何组合，支持自托管和气隙部署。