Skip to content

Core concepts

Governance: read-first & deny-closed

How Olivares AI observes before it enforces, governs actuation deny-closed by default, applies risk tiers with a dual-control floor, and ties to a kill switch

Governance in Olivares AI is built on two principles you can hold in your head at once: observe before you enforce, and when you do enforce, default to no. The product maps and audits what every agent can reach long before it gates a single action, and the gates it does run are deny-closed.

Read-first: observation before enforcement

The platform’s default posture is detective, not preventive. It builds the read/write access map by ingesting logs, OpenTelemetry and native audit out of band — it is never in the agent’s data path, so a collector that fails cannot take production down with it. From that map it diffs permitted against observed and surfaces drift for a human to judge.

This matters for how you read the rest of this page. The product observes and governs broadly; it does not broadly actuate. Where it can take an action on your infrastructure, that capability is one of three things, and the modules catalog marks which:

  • live — wired and acting today (a narrow set);
  • on-demand — the backend is built and wired to an injection point but stays deny-closed or degraded until you provision it (an executor, a dispatcher, an inference credential);
  • seam — a declared, deny-closed interface with no backend in the default binary.

So an absence of enforcement is usually by design, not an oversight. Read-first means the honest default is to watch and record, and to gate only the surfaces you have explicitly turned on.

The authorization model you govern within

Every governed decision runs through the same authorization core that protects the rest of the API. Three properties are worth internalizing before you change anything.

RBAC is deny-by-default. A principal with no membership in a tenant is denied — there is no implicit grant. Permissions are tenant-scoped, and a handler acts only on the single tenant the request resolved to, which closes confused-deputy and IDOR classes by construction. Roles form a ladder: viewer reads, editor writes, admin manages tenant IAM, owner holds everything. Reading the access graph is deliberately an editor-and-up privilege — a full map of what every agent can touch is a recon roadmap — and every such read is written to the audit ledger.

The policy seam only restricts. On top of RBAC you can wire an attribute-based policy decision point. The composition is an intersection — RBAC ∩ native ABAC ∩ external PDP — so a policy can only further-restrict what RBAC already allowed; it can never widen a grant. This is enforced, not a convention. You choose at most one external engine:

# Embedded Cedar (pure-Go, no sidecar) or OPA over HTTP. Default: none.
OLIVARES_PDP_ENGINE=cedar   # or: opa | none

With Cedar you author forbid rules; an empty rule set leaves the RBAC decision standing. With OPA your Rego must be permit-by-default, where a missing result or any transport error fails closed. An invalid PDP configuration disables only the external PDP and logs the fact — native ABAC and RBAC keep governing, and a misconfigured engine never leaves a request ungoverned. Every restriction the PDP applies is audited.

Risk tiers and the dual-control floor

Actions that reach the approval queue are classified into four risk tiers — low, medium, high, critical — following the OWASP AI-agent taxonomy. (This is a separate axis from the EU AI Act compliance tiers; do not conflate the two.) The tier is re-derived from the live policy at every security decision, never read from a stored snapshot, so a policy change takes effect immediately and a stale row can never hold the bar lower than the current classification.

A critical action carries a mandatory two-person floor: at least two distinct human approvers, drawn from NIST SP 800-53 AC-3(2) dual authorization. The floor is enforced twice — at create (the stored threshold can never start below it) and re-derived at decide (a downgraded or legacy row still cannot cross with one approver) — so even an operator policy that explicitly lowers the tier cannot make a critical action single-handed. The built-in critical set is the irreversible, estate-shaping family: production deploy and retire, data deletion, security-enforcement changes, key custody and rotation, and re-enabling the estate after a kill switch.

Lower tiers do not change the engine’s mechanics — an approval that exists already demands at least one human — they are the vocabulary other controls key on (for example, stepping up authentication on a critical action).

The human-in-the-loop approval gate

Where the product gates an action, the loop is: a surface presents (drift from the access map, a finding from the security module) → an authorized operator decides → the decision is recorded in the audit ledger. The approval engine that backs this is real today: a request opens deny-closed, bound to a plan hash, and time-boxed. The invariants are enforced server-side, keyed on the stable user identity (a system token has no identity and cannot decide):

  • Separation of duty — the requester can never decide their own request.
  • Duplicate-decider guard — one human counts once toward a threshold.
  • Expiry — derived at read, so an expired request can never bind even before a sweep materializes its expiry.

What is still maturing is the richer operator review console; the endpoints and the engine ship today. The guide Govern and approve walks the live flow.

The dependency that makes any of this credible is per-agent identity. Audit attributes activity to a credential, not inherently to an agent; a shared service account collapses attribution to the identity level — surfaced honestly as a finding, never silently recovered. See permitted vs observed and fidelity for what that does to the signal you govern on.

Break-glass: the audited escape valve

Two-person control needs an escape valve for the 03:00 incident where one approver is unreachable. Break-glass is that valve, and it is loud by construction. Activation is admin-tier and demands a real human (a system token is refused), a hardware-verified (AAL3) step-up, a written justification, and an actively recorded session as a precondition. The grant is time-boxed — default one hour, hard cap one day — and an expired grant can authorize nothing.

While a grant is active, an in-scope action may proceed without its approval quorum, but every use is appended to an immutable trail and the audit ledger, naming the grant, the action and the subject — an action that proceeded under break-glass is permanently distinguishable from an approved one. A forced post-review closes the loop: a new grant cannot be activated while a prior one is unreviewed, and the review must come from a different human than the activator.

The kill switch: the estate-wide deny gate

The kill switch is the one-click emergency stop, and it inverts the usual ergonomics on purpose. Engaging is deliberately cheap — admin-tier, a mandatory reason, no approval quorum, no step-up, no break-glass — because a stop that waits for consensus is not a stop. The engaging session’s assurance level is recorded for forensics; abuse of engage costs availability only, which is the safe direction.

The stop row is the single source of truth. Every governed actuation gate consults it live on each action and fails closed on a read error — the exact inverse of the budget gates’ fail-open contract, because an unreadable stop state must never mean “go.” Engaging also revokes the queued work the gates cannot reach: every pending in-scope actuation approval is canceled in the same transaction, so a pre-stop intent cannot ripen into a grant that dispatches the moment the estate comes back. Governance actions themselves are exempt — the stop halts the agentic estate, never the controls that govern it.

Re-enabling is never unilateral. It is gated on a fresh dual-control approval (the critical two-distinct-humans floor, structurally re-verified at the flip so a downgraded policy cannot make it single-handed), and there is deliberately no break-glass path for re-enable: “the estate stays stopped” is the safe state. A forced post-review by an uninvolved human closes the incident.

The recorded-decisions guarantee

Whatever the depth of the workflow above it, a governance decision is a recorded fact. Mutating actions are appended to the audit ledger with the real actor in the same transaction as the change, and sensitive reads (the access graph, the ledger itself) self-audit in a committed write. The ledger is append-only and hash-chained, each record carrying the chain-integrity fields, so rewriting history is detectable and it never contains PII. You cannot make an ungoverned change that the ledger silently forgets.