诚实与边界

面向 AI 的控制平面（control plane）是一款安全产品。如果它夸大其所覆盖的范围， 就会带来虚假的安全感 —— 这比完全没有工具更糟糕。因此本页是关于 今天有哪些功能在运行、哪些在计划中、以及哪些是有意排除在范围之外的明确约定。 文档的其余部分都遵守这一约定：教程和操作指南中的命令都应按所写内容原样运行； 凡是产品尚未覆盖之处，页面会直接说明，而不是暗示它已经覆盖。

今天有哪些功能在运行

• 单一二进制文件可以构建、启动并到达一个已填充数据的访问图谱。 olivares 二进制文件编译为一个嵌入了 Web UI 的静态工件。 使用演示资产域（estate）启动它（serve --seed-demo），并依次走过 discover → R/RW 图谱 → Permitted-vs-Observed 漂移 → 清单 这一路径， 已由测试套件端到端验证。教程 正是复现这条路径。
• 首次运行的初始化无需凭据。 全新安装没有默认凭据； 引擎在首次启动时打印一个一次性、单次使用的初始化令牌。
• REST API 和审计账本（audit ledger）是真实存在的。 API 参考 从产品自身的 OpenAPI 3.1 契约渲染而来。审计账本是 append-only（仅追加）且哈希链式（hash-chained）的，并带有 Ed25519 签名的检查点， 可导出为多种 SIEM 格式。
• 发布版本经过签名且可离线验证。 签名、SLSA 来源、SBOM 和 OpenVEX 都可在无网络访问的情况下验证， 且产品提供气隙（air-gap）包。目前还没有任何带标签的发布版本，因此这描述的是一个发布版本将会包含什么，而不是你今天可以下载并验证的产物 —— 与 SECURITY.md 所述的同一条保留说明。

开放内核 —— 哪些开放、哪些属于企业版

本产品采用开放内核（open core）：默认的（AGPL）二进制就是整个治理 平台，而一条小而**增量式（additive）**的商业线（enterprise/，仅以 -tags enterprise 构建，永不进入公开二进制）持有那些保留功能。对日常使用 而言有两条边界值得关注，开放版对它们如实回应，而非伪装它们：

• 单 IdP 的 SSO 是开放的。 单 IdP 登录 —— OIDC（授权码 + PKCE） 和 SAML 2.0（已签名的响应、防重放）—— 在默认二进制中运行，无需 -tags enterprise。运行多于一个活动 IdP（按租户 / 按域名）、 SSO 强制（要求 SSO / 阻止密码登录）以及受管 SCIM是保留的企业线； 激活第二个活动 IdP 会返回 multi_idp_requires_enterprise —— 这是一条明确的 产品边界，绝非伪造的 501。
• 不存在用户数量上限 —— 所有版本的账户都不受限制。 社区版、Business、附加组件 以及自托管企业版都允许无限数量的用户账户，无论授权处于何种状态：有效、过期或 完全没有。2026-07-27 之前存在的三个活动账户上限已被彻底移除（席位接缝仍作为 兼容性 no-op 保留在代码中，不会拒绝任何操作），授权过期也绝不会限制、停用或删除 账户。商业模式是对附加组件的按期授权，而非按席位收费。
• 平台的其余部分都是开放的。 完整的治理闭环 —— 清单、R/RW 访问图谱、 RBAC/ABAC/Cedar 策略、已封存的审计账本、FinOps、合规、SIEM 出口、MCP、 HA/分布式 —— 都在开放二进制中运行，没有任何授权检查。那条增量式的 enterprise/ 增量功能（多 IdP 联邦、内容防火墙/DLP、hook 加固、编译的威胁情报 目录、服务器工具出口、CyberArk Conjur 连接器以及事件闭环）是 从未存在于开放产品中的新代码，而非从中移除的功能。开放二进制中的授权验证 仅作为存证 —— 它从不启用、禁用或阻止任何东西（参见 开放内核与授权许可）。

哪些处于设计阶段或 1.0 之前

Olivares AI 处于 1.0 之前阶段。产品设计文档明确指出， 即便在引擎已经运行的部分，平台的许多内容仍处于设计阶段。 除非某个页面另有说明，否则应将模块级别的深度视为进行中的工作。

• R/RW 映射的覆盖是分层的，且这是设计使然。 保真度取决于源能证明什么。 对于具备原生审计的存储，它是清晰的（通过 pgAudit 的 SQL、 通过 CloudTrail 的对象存储、数据仓库/数据湖）；对于某些存储是有损的 （文档型/向量型）；对于另一些存储则无法被动重建（例如 Redis、SQLite、D1）—— 当无法判定读还是写时，该边被标记为 unknown。当源携带按代理（per-agent）的身份时，归因是明确的（firm）； 当共享服务账户掩盖了身份时，则降级为 approximate（近似）。产品如实展示 这些情况；它不会虚构确定性。
• 规范的 R/RW 源在标准 serve 中已接好线。 组合根 注册了主机级别的观察者 —— pgaudit、s3cloudtrail、ebpf、 runtime 和 mcp 内省源 —— 同时还有数据仓库/数据湖 观察者（snowflake/databricks/bigquery/mssql/oracle/mongo/redshift/gcs/ azure-blob/iceberg/openlineage/delta-sharing），全部可通过 OLIVARES_SOURCES_CONFIG 配置（快速上手 针对标准二进制接好了一个真实的 pgaudit 源，冒烟测试会断言这一点）。 知识文档源 （gdrive/confluence/notion/sharepoint/s3content）有意不作为运行时 源 —— 它们由知识摄取请求按需加载。 连接器参考标注了每种类型。
• 默认是单一二进制文件；分布式事件总线确实存在，并对其语义保持诚实。 默认作为单个二进制文件运行，带有进程内事件 总线。远程采集器→核心的数据路径已构建并发布：边缘采集器 在本地运行源连接器，并通过经验证的客户端证书双向 TLS 将观察结果推送到 中央核心，且没有入站监听器（collector 模式）。 分布式事件总线随横向扩展工作一同发布：这是一种混合方案， 既为本地投递保留进程内的扇出（阻塞式背压、无本地丢失）， 又通过 NATS 在节点间桥接事件，由 OLIVARES_BUS_CONFIG 启用（错误配置的总线配置会使启动失败， 而不是悄无声息地分裂总线）。跨节点投递被如实记录为 at-most-once（至多一次） —— 桥接断连和丢弃会被计入专门的指标， 绝不悄无声息（监控）。
• 受治理的执行（actuation）有三种诚实的状态：实时（live）、按需（on-demand）和接缝（seam）。 产品今天进行广泛的观察与治理。一小部分执行能力在默认二进制中即为实时**， 无需预置：FinOps 预算强制（达到上限的强制预算会拒绝该支出）、 通知派发传输（一旦配置好目的地即开始路由）、安全侦测发现/护栏（guardrails）， 以及进程内的合成沙箱运行器（由构造方式天然隔离）。还有若干能力是 按需接好线的 —— 后端已构建并接好线，但在运维方通过 env 配置预置它之前， 保持 deny-closed 或降级状态：模块 VII（deploy） apply/retire（在预置执行器之前返回 503）、模块 IV 编排 fire 和模块 XVI 语音派发（两者在配置好派发器之前均为 deny-closed）、 OS 隔离的沙箱/红队运行时（在预置前为合成 / DEGRADED）、 基于模型的语义检索（默认仅为词法和公开内容）， 以及模块 X 中的模型执行（在预置推理凭据之前返回 503）。 仍然作为已声明的 deny-closed 接缝且完全没有后端的是 休眠的语音遥测探针（分布式事件总线在 NATS 桥接发布后已离开此列表 —— 见上文）。 模块目录标注了每个模块的 Govern/Observe 和 Actuate 状态；没有任何内容声称在它实际不执行之处执行。（这纠正了 早先将语音、沙箱/红队运行时和语义检索列为”实时”的解读 —— 它们是按需的： 针对标准 serve --seed-demo 启动验证，2026-06-08。）
• 气隙适用于控制平面，而非 Claude 推理。 控制平面 完全自托管（self-hosted）运行，且可气隙化（SQLite 单节点、已签名的离线 发布、气隙包）。Claude 本身不可自托管 —— Anthropic 不 发布权重 —— 因此任何 Claude 推理都会触达 Anthropic 的 API，无论是直接还是经由 Bedrock/Vertex/Foundry。此处的”气隙”指的是治理与观察平面 及其数据留在你的边界内；它不意味着 Claude 离线运行。 你确实自托管的模型（例如在模块 XXIII 下通过 vLLM/Ollama）可以 气隙化运行；经中介的前沿模型则不能。
• 模块路由并非全部都在公开的 API 契约中。 某些模块端点 （例如访问图谱和漂移）是可达的，但有意 不属于所提供的 OpenAPI 文档；它们的字段级契约位于产品的 类型化接口中。API 参考记录了 核心 REST 表面；它并非整个产品表面。

产品有意不做的事

• 没有进攻性功能。 Olivares AI 不是命令与控制框架， 也不扫描他人的凭据。访问映射是一个强大的侦察工具， 供防御者治理他们自己的资产域—— 查看它是一项 特权的、租户范围的、完全审计的操作。这条防御性界线是 有意为之并保持明确的（参见 威胁模型）。
• 没有原生的 Splunk S2S 转发器。 转发到 Splunk 是一种有文档记录的姿态 —— 将 Universal Forwarder 指向控制平面追加写入的某个文件，或通过 Splunk HEC 推送 —— 而非原生的 Splunk-to-Splunk 发射器。 Splunk 操作指南明确说明了哪个流 对应哪个。
• REST 契约中没有出站 webhook。 OpenAPI 文档未定义任何 webhooks。出站签名投递作为内部通知目的地连接器存在， 而 SCIM Security-Event-Token 端点是一个 入站接收器 —— 两者都不是 OpenAPI webhook。参见 API 参考。
• 模型微调（模块 XXIII）属于 v1 之后。 它的缺席是一项决策，而非 缺口。

文档在何处指出上游的缺口

本文档暴露的少数几件事是产品中的缺口，已上报给 拥有相关契约的团队，而不是在此粉饰：

• 站点渲染所用的已提交 OpenAPI 文件现在从引擎自身的生成器重新生成 —— 并由 CI 逐字节对照核验，因此它不再 落后（早先的端点缺口已得到调和）。早先对 /v1/audit/export 格式列表的记录不足也已在上游修复：摘要和 错误请求消息现在都由引擎的格式注册表（audit.FormatList()）生成，因此不会再次漂移 —— 本节 保留记录，因为这些文档的早期版本曾报告该缺口，也因为同样的腐化在 2026-07-25 之前 还把 leef 与 ocsf 从 CLI 的帮助与自动补全中隐藏了起来。
• 审计账本的推送路径随 SIEM/ITSM 互操作工作一同发布：一个 audit.recorded 事件订阅会开启一个按租户的账本泵， 以 at-least-once（至少一次） 的方式将已封存记录转发到所配置的接收端（Splunk HEC、 Sentinel、Datadog、New Relic，或一个 HMAC 签名的 webhook）。拉取导出 仍然是 WORM 归档和离线重新验证的正确形态。参见 推送到你的 SIEM和 Splunk 操作指南。仍然不存在的 是原生的 Splunk S2S 协议发射器（见下）。

如果你发现某个命令的行为与文档不符，那就是文档或产品中的一个 缺陷 —— 请报告它。