Olivares AI 是一个开放的、可自托管的平台，回答大多数团队今天无法回答的问题：我的基础设施上运行着哪些 AI 代理，每个代理实际能访问什么？
它在你的代理运行的地方运行，被动发现它们，并构建一个读/写访问映射——对于每个代理，它能触及的资源以及它能读取它们还是读取和写入它们。在此基础上你可以治理该访问，并在事后证明确切发生了什么。
读/写访问映射
映射是产品的核心（模块 III）。每个 AI 代理成为一个节点；它能访问的每个资源——数据库、对象存储、MCP 服务器、API——也成为一个节点；每条边标记为 R（读）或 RW（读/写）。
读与写的区分就是关键点。一个只能读取生产存储的代理与一个可以写入它的代理有着完全不同的爆炸半径。映射使这种差异显式化，而非让它埋藏在分散的 IAM 策略中。
允许与观测
映射的独特之处在于两层之间的差异：
- 允许（Permitted） ——代理被允许触及什么，来自授权和策略。
- 观测（Observed） ——它实际被观察到触及什么，来自遥测数据。
比较它们浮现两个重要的发现：
- 意外访问 ——被观测到但从未被预期。你想要捕捉的事情。
- 未使用的授权 ——被允许但从未被行使。你的最小权限清理列表。
对能证明什么保持诚实
映射从不伪造确定性。保真度是分层的并如此展示：
- 读/写的覆盖范围在带有原生审计的数据源（通过 pgAudit 的 PostgreSQL、通过 CloudTrail 的对象存储、数据仓库和数据湖）上是
clean，在某些文档/向量存储上是lossy，在根本无法被动重建的地方是opaque（Redis、SQLite、D1）——那里的边标记为unknown而非猜测。 - 归因在数据源携带按代理身份时为
firm，当共享服务账户隐藏了谁做了什么时折叠为approximate。
你总是能看到产品实际知道多少：层级在 UI 中展示而非隐藏，因此 clean/firm 的边和 unknown/approximate 的边永远不会被呈现为相同的东西。
自托管和开放核心
Olivares AI 是开放核心的：完整产品在 AGPL-3.0 下免费且开源——不是一个精简的社区版。它部署为一个单个静态二进制文件，内嵌 Web 控制台。
控制平面在你自己的基础设施内运行，可以气隙运行——你的治理和观测数据永远不会离开你的边界。一个诚实的注意事项：像 Claude 这样的托管模型不可自托管，因此任何模型推理仍然访问提供商的 API（直接或通过 Bedrock/Vertex/Foundry）。“气隙”意味着你的资产数据留在家中，而非模型离线运行。只有真正可自托管的模型（例如通过 vLLM/Ollama）才能完全离线运行。
今天的状态
平台是 1.0 之前版本。它发布了一个包含 29 个功能模块的目录，在标准安装中今天已全部接入。产品是读优先且默认检测的——它观测和治理，在能采取行动的地方以默认拒绝方式执行。这里没有声称代码没有实现的功能。
准备好看看了吗？从快速入门开始。