问题所在：智能体到来的速度，超过了平台对其建模的速度
您运营着一个内部开发者平台。您拥有服务目录、IdP、基础设施即代码、GitOps 协调，以及一个工程师真正会打开的门户。这套机制之所以存在，正是为了确保没有任何重要事物在未被建模的情况下运行 —— 没有无主的服务，没有无策略的访问，没有无差异（diff）的变更。
AI 智能体打破了这一约定。一个 Claude Code 会话、一个 MCP 服务器、一个定时的自主智能体 —— 它们每一个都能跨越您的服务所触及的同一批数据库、对象存储和 API 进行读写，却出现在目录之外。它们由开发者启动，而非由您来配置。它们往往以共享服务账户的身份进行认证。而超大规模云厂商使情况更加恶化：它们将智能体身份做成了三个互不兼容注册表中的 GA 原语。
市场信号毫不含糊。Gartner 预计到 2027 年底，将有超过 40% 的智能体 AI 项目被取消（Gartner，新闻稿）；而 IBM《2025 年数据泄露成本》研究（Ponemon）发现，在遭遇 AI 相关泄露的组织中，约 97% 缺乏适当的 AI 访问控制。来自 NANDA 项目的一项 MIT 初步发现 ——《the GenAI Divide》，经由 Fortune，2025 年 8 月，尚未经过同行评审 —— 报告称约 95% 的 GenAI 试点未显示出可衡量的损益（P&L）影响，且外部采购的工具成功率约为内部自建工具的两倍。对照平台团队的职责来解读，这指向同一个方向：无治理、无建模的智能体蔓延，正是价值流失、风险渗入之处。
Olivares AI 如何契合您已在运行的平台
Olivares AI 是一个开放、可自托管的平台，它发现您基础设施上的 AI 智能体，绘制出每个智能体可读、可写的内容，并对该访问进行治理与审计。面向平台团队的设计目标不是再添一个控制台 —— 而是让智能体成为您已在运营的平台中的一等公民。
作为一等公民目录实体的智能体
平台发现智能体、MCP 服务器、会话以及非人类身份，并构建一张访问地图：一张涵盖每个智能体 → 数据库 / 存储 / API 边的关系图，每条边都标记为只读（R）或读写（RW）。这张图就是智能体本就应当拥有的目录条目 —— 它是什么、它触及什么，以及它所触及的内容是否与它被允许的内容相符。
最后这一区分正是产品的核心。边被分类为许可（permitted）与观测（observed），从而使最小权限漂移可见，而非仅凭假设。详见访问地图以及关于许可与观测的概念页。
此处的诚实声明很重要，我们也始终公开它：R/RW 的保真度是分层的。在具备原生审计的数据源上，覆盖度为 clean；在边较为粗略之处为 lossy；在完全没有被动读写信号之处为 opaque；当数据源携带每个智能体的身份时，归属为 firm，当共享账户掩盖了身份时则为 approximate。这张地图展示的是分层级别，而非伪造确定性 —— 详见保真度。
以代码方式管理：Terraform/OpenTofu provider
对平台团队而言，配置即代码是基本要求。Olivares AI 提供 terraform-provider-olivares，它以声明式方式针对其稳定 API 管理您自己的自托管控制平面。该 provider 为智能体、策略、部署、智能体身份绑定、预算、能力配置和通知路由暴露了资源与数据源，并支持 import、plan/apply 以及漂移处理 —— 因此您所治理的智能体，会以 ArgoCD 或 Flux 已经协调您其余资产的同样方式被协调。
有一处需要精确说明的许可证细节，因为它与连接器 SDK 不同：该 provider 是 AGPL-3.0-only，而非 Apache-2.0。
resource "olivares_agent" "billing_assistant" {
name = "billing-assistant"
# ...managed alongside the rest of your platform, as code
}
resource "olivares_policy" "billing_least_privilege" {
# least-privilege intent, versioned in Git, reconciled like everything else
}上面的 HCL 仅用于示意形态，并非可直接复制粘贴的约定 —— 请针对该 provider 自身已发布的 schema 生成。本产品处于 pre-1.0 阶段：请将资源覆盖视为对 API 表面的跟踪，并查阅模块参考以了解当前已接入的内容。
与您的 IdP 契合 —— 联合，而非替代
Olivares AI 不是身份提供商，也不试图成为其一。它以只读方式联合智能体身份：它从 Microsoft Entra Agent ID、AWS AgentCore Identity 和 Google Agent Identity 读取名册，并将其与 SPIFFE/WIF 名册进行核对，使访问地图中的每条边都携带确定或近似的归属。专用的智能体身份与工作负载身份解析为确定（firm）归属；蓝图主体、凭据提供方和服务账户智能体则保持近似（approximate），而不会被提升为某个虚构的身份。它不签发任何凭据，也不向这些注册表回写任何内容 —— 联合严格保持只读。
它还呈现一类对平台安全有用的漂移：在智能体身份上检测到的长期静态凭据，这与 Five Eyes 2026 关于采用短期凭据的指引相一致。基于 SVID 的 OAuth 客户端认证（即 draft-ietf-oauth-spiffe-client-auth 工作）以**设计趋向（design-toward）**方式实现 —— 在授权服务器发布相匹配的流程之前，不存在任何合规性声明。详见身份与联合。
一个门户切入点：Backstage，以只读为先
如果您的开发者长居于 Backstage，那么智能体清单也应当存在于此。设计目标是一个原生的、以只读为先的插件 —— 在门户内渲染清单、实时会话以及 R/RW 访问地图，并针对控制平面进行身份认证 —— 而非 iframe，也非第二个仪表盘。以只读为先是刻意为之：它与产品的姿态（见下文）相匹配，并使门户集成保持低风险。
CLI 为先，底层有稳定的 API
整个平台就是一个 Go 二进制文件 controlplane，启动即可得到一张已填充的访问关系图；Web 控制台内嵌于与 API 相同的源（origin）。您在 UI 中能做的一切，都可以通过 CLI 或 OpenAPI 3.1 表面来驱动，而这正是 Terraform provider、Backstage 插件以及您自己的自动化所共同构建的基础。可从配置参考、CLI 工作流以及 MCP 治理表面入手。
它是什么 —— 以及它不是什么
这是一款以安全为形态的产品，因此我们对其声明坚守严格的底线。
- 只读为先、默认拒绝（deny-closed）。 它广泛地观测与治理；但不广泛地执行（actuate）。 大多数执行都是即时按需（live-on-demand），或是一个声明式的、默认拒绝的接缝 —— 一次部署
apply会返回503，直到您配置好执行器为止，而不是悄无声息地无操作（no-op）。详见许可与观测以及诚实与边界页。 - pre-1.0、开放核心（open-core）。 目录共有 23 个模块；在标准安装中约有 20 个已接入。此处并不暗示全部 23 个均已完全上线 ——模块参考标注了各模块的状态。
- 气隙（air-gap）指的是控制平面，而非 Claude。 治理与观测平面完全自托管运行，并可气隙部署。Claude 推理从不自托管 —— Anthropic 不发布任何权重，因此任何对 Claude 的调用都会触达某个 API。只有您真正自托管的模型（vLLM、Ollama）才能离线运行。详见安全。
- 未获认证。 它设计趋向于欧盟 AI 法案（EU AI Act）、NIST AI RMF、ISO/IEC 42001、SOC 2 等标准，审计证据取自一个仅追加（append-only）、哈希链式（hash-chained）的账本。它并未获得 SOC 2 / ISO / 欧盟 AI 法案的认证。详见合规。
- 它补充您的控制塔，而不声称取代它们。 身份联合与姿态导出在设计上即为只读。
如果您想先看架构全景，请阅读架构；如果您想了解我们相对于网关、可观测性和智能体控制塔的定位，请参阅对比。而如果您正在权衡许可证以及开放核心的边界，开源是其中诚实的版本。
相关角色：安全负责人、SRE 与系统管理员，以及高等教育。