Olivares AI 的治理建立在两个你可以同时记住的原则上：先观测后执行，以及执行时默认为拒绝。产品在对单个操作进行把关之前很久就已经映射和审计了每个代理能访问的内容，而它运行的把关机制是默认拒绝的。
读优先：先观测后执行
平台的默认姿态是检测性的，而非预防性的。它通过在带外摄取日志、OpenTelemetry 和原生审计来构建读/写访问映射——它永远不在代理的数据路径中，因此收集器故障不会导致生产环境宕机。从该映射中，它对允许状态与观测状态进行差异比较，并将漂移呈现给人类判断。
这对你理解本页其余内容很重要。产品广泛地观测和治理；它不会广泛地执行操作。在能对你的基础设施采取行动的地方，该能力属于以下三种情况之一，模块目录标明了具体属于哪种：
- 在线 ——已连接并在今天运行（一个较小的集合）；
- 按需 ——后端已构建并连接到注入点，但保持默认拒绝或降级状态，直到你进行配置（一个执行器、一个调度器、一个推理凭证）；
- 接口 ——一个已声明的默认拒绝接口，在默认二进制文件中没有后端。
因此，没有执行机制通常是设计使然，而非疏忽。读优先意味着诚实的默认行为是观察和记录，并仅在你明确开启的界面上进行把关。
你在其中治理的授权模型
每个受治理的决策都通过与保护其余 API 相同的授权核心。在更改任何内容之前，有三个属性值得内化。
RBAC 默认拒绝。 在租户中没有成员资格的主体会被拒绝——没有隐式授权。权限限定于租户范围，处理程序仅在请求解析到的单个租户上操作，这从结构上关闭了混淆代理和 IDOR 类漏洞。角色形成阶梯：viewer 读取，editor 写入，admin 管理租户 IAM，owner 拥有一切。读取访问图被有意设定为 editor 及以上权限——因为完整的代理可访问资源映射就是侦察路线图——每次读取都写入审计账本。
策略接口仅做限制。 在 RBAC 之上，你可以接入基于属性的策略决策点。组合方式是交集——RBAC ∩ 原生 ABAC ∩ 外部 PDP——因此策略只能进一步限制 RBAC 已经允许的内容；它永远不能扩大授权。这是强制执行的，不是约定。你最多选择一个外部引擎：
# 嵌入式 Cedar（纯 Go，无 sidecar）或通过 HTTP 的 OPA。默认：无。
OLIVARES_PDP_ENGINE=cedar # 或：opa | none使用 Cedar 时，你编写 forbid 规则；空规则集让 RBAC 决策保持不变。使用 OPA 时，你的 Rego 必须默认允许，其中缺失的结果或任何传输错误均视为拒绝。无效的 PDP 配置仅禁用外部 PDP 并记录该事实——原生 ABAC 和 RBAC 继续治理，配置错误的引擎永远不会让请求处于无治理状态。PDP 应用的每项限制都会被审计。
风险分层与双人控制底线
到达审批队列的操作被分为四个风险等级——low、medium、high、critical——遵循 OWASP AI 代理分类法。（这与 EU AI Act 合规等级是独立的轴；不要混淆。）等级在每次安全决策时从实时策略重新推导，绝不从存储的快照读取，因此策略变更立即生效，过时的记录永远不会将标准降低到当前分类以下。
critical 操作带有强制双人底线：至少两个不同的人类审批者，源自 NIST SP 800-53 AC-3(2) 双重授权。底线在两个时点执行——创建时（存储的阈值永远不能低于它）和决策时重新推导（一条降级或遗留的记录仍然无法通过单人审批）——因此即使操作员策略明确降低等级，也不能使 critical 操作变成单人操作。内置的 critical 集合是不可逆的、影响整个资产的操作族：生产部署和退役、数据删除、安全执行变更、密钥保管和轮换，以及紧急停止后的重新启用。
较低等级不改变引擎的机制——已存在的审批至少需要一个人类——它们是其他控制依据的词汇（例如，在 critical 操作上升级认证）。
人在环审批把关
在产品把关操作的地方，循环是：一个界面呈现（来自访问映射的漂移、来自安全模块的发现）→ 一个授权操作员决策 → 决策记录在审计账本中。支持此功能的审批引擎今天已经投入使用：请求以默认拒绝方式打开，绑定到计划哈希，并有时间限制。不变量在服务端执行，基于稳定用户身份（系统令牌没有身份，无法做出决策）：
- 职责分离 ——请求者永远不能决策自己的请求。
- 重复决策者防护 ——一个人类只计入阈值一次。
- 过期 ——在读取时推导，因此过期的请求即使在清理任务实际标记过期之前也无法绑定。
正在成熟的是更丰富的操作员审查控制台；端点和引擎今天已经发布。指南治理与审批详细介绍了实时流程。
审批可信的依赖是按代理身份。审计将活动归因于凭证，而非天然地归因于代理；共享服务账户将归因折叠到身份级别——这被诚实地作为发现呈现，永远不会被静默恢复。参见允许与观测和保真度了解这对你治理所依据的信号有何影响。
紧急越权：受审计的应急阀
双人控制需要一个应急阀来应对凌晨 3 点只有一个审批者不可联系的事件。紧急越权就是这个阀门，它在结构上就是高调的。激活需要管理员级别，要求真实人类（系统令牌被拒绝）、硬件验证（AAL3）的升级认证、书面说明，以及正在录制的会话作为前提条件。授权有时间限制——默认一小时，硬性上限一天——过期的授权无法授权任何操作。
当授权处于活动状态时，范围内的操作可以无需审批法定人数即可进行，但每次使用都追加到不可变的跟踪记录和审计账本，命名授权、操作和主体——在紧急越权下进行的操作与经过批准的操作是永久可区分的。强制事后审查关闭循环：在先前的授权未被审查之前，无法激活新的授权，审查必须来自与激活者不同的人类。
紧急停止开关：全资产拒绝关口
紧急停止开关是一键紧急停止，它故意反转通常的操作便利性。启动被有意设计为低成本——管理员级别、强制说明理由、无需审批法定人数、无需升级认证、无需紧急越权——因为等待共识的停止不是停止。启动会话的保证级别被记录以用于取证；滥用启动仅影响可用性，这是安全的方向。
停止记录是唯一的真实来源。每个受治理的执行关口在每次操作时实时查询它，并在读取错误时视为已停止——这与预算关口的允许通过合约恰好相反，因为不可读的停止状态绝不能意味着”通过”。启动还撤销了关口无法触及的排队工作：每个待处理的范围内执行审批在同一事务中被取消，因此停止前的意图不能在资产恢复时变成已授予并被调度执行。治理操作本身是豁免的——停止暂停代理资产，永远不暂停治理它的控制。
重新启用绝不单方面。它受新的双人控制审批把关（critical 双人不同底线，在切换时结构性地重新验证，因此降级的策略不能使其变成单人操作），并且故意没有紧急越权路径用于重新启用：“资产保持停止”就是安全状态。由一个未参与的人类进行的强制事后审查关闭事件。
记录决策的保证
无论上层工作流的深度如何，治理决策都是一个已记录的事实。变更操作在与变更同一事务中与真实操作者一起追加到审计账本，敏感读取（访问图、账本本身）在提交的写入中自我审计。账本是仅追加且哈希链化的，每条记录都携带链完整性字段，因此重写历史是可检测的，且它从不包含 PII。你无法进行账本静默遗忘的未治理变更。