Once a source is connected and the access map shows what each agent can read and write, the next job is to govern it: decide who and what may act, and make every decision a recorded fact. This page covers the approval workflow — risk tiers, dual-control, break-glass, and the ledger they all anchor to.
Governance is deny-closed by default. A principal with no role in a tenant is denied; there is no implicit grant. The product observes broadly but does not broadly actuate — where it governs an action, it does so deny-closed, never as a blanket executor.
The authorization model
Every governance call runs through the same authorization core as the rest of the API: RBAC first, scoped to a single tenant, with an optional external policy layer on top.
Roles form a ladder — viewer (read), editor (write), admin (tenant IAM), owner
(everything in the tenant). Reading the access map is deliberately not the lowest tier:
a map of what every agent can touch is a recon roadmap, so it is granted from editor up,
tenant-scoped, and every read is written to the ledger.
An optional policy decision point (Cedar embedded, or OPA over HTTP) can layer attribute-based rules on top. It composes as an intersection — RBAC ∩ native ABAC ∩ external PDP — and has one invariant:
The policy layer can only take access away, never add it. A policy can deny something RBAC would have allowed; it can never grant something RBAC denies. A misconfigured or unreachable PDP fails closed, and disabling the external PDP never leaves requests ungoverned — native RBAC and ABAC keep governing.
Risk tiers
A governed action is classified into one of four tiers — low, medium, high,
critical — derived from the OWASP AI-agent risk taxonomy. The tier drives how much human
control the action requires before it can proceed.
The tier is not stored on the approval row. It is re-derived from the current policy set plus a built-in default at every decision, so a policy change takes effect immediately and a stale snapshot can never hold the bar below the live classification (deny-closed).
| Tier | Default control |
|---|---|
low / medium | assigned only by explicit policy |
high | the default for anything that reaches the approval queue — one human approval |
critical | a mandatory two-person floor (see below) |
The built-in critical set covers the genuinely irreversible: production deploy and retire,
data deletion and erasure, security-enforcement and kill-switch changes, key custody and
rotation, and NHI offboarding. An approval policy with an explicit risk_tier can raise or
lower the default per action — that is the operator’s audited word — but it can never lower
a critical action below the dual-control floor.
Approval requests and dual-control
An approval request opens deny-closed and time-boxed: it starts pending, carries an expiry, and authorizes nothing until enough humans decide it. A matching approval policy is authoritative for the threshold and timeouts, so a requester can never lower their own bar.
Three invariants are enforced server-side, not by convention:
- Separation of duty. The requester cannot decide their own request. This keys on the stable user identity, not the credential string a single person could vary.
- One decision per human. A unique index backstops a duplicate-decider race; the same person cannot count twice toward the threshold.
- Expiry binds. An expired request can never receive a binding decision — the effective status is re-derived at every decision, sweep or no sweep.
For critical actions the threshold is floored at two distinct human approvers (NIST
SP 800-53 AC-3(2) dual authorization). The floor is enforced both when the request is
created (the stored threshold can never start below two) and re-applied at the decision
point (a request created before the action became critical still cannot cross with one
human). A single approver can never satisfy a critical action.
A critical decision additionally requires a hardware-verified session: the deciding
human must have a fresh WebAuthn or PIV step-up (AAL3). A system token carries no human
assurance and is refused — a system token cannot approve.
Every decision appends an immutable row to the request’s decision trail and a ledger event recording the decision, the resulting status, and the risk tier under which it was made.
Break-glass
Two-person control has an escape valve for the 03:00 incident where the second approver is unreachable. An admin — always a real human, never a system token — activates a time-boxed emergency grant that lets a gated action proceed without its quorum. The path is never silent:
- Activation requires a justification, self-audits to the ledger in the same transaction, and emits a critical finding to the notification rail.
- Every use appends an immutable row and a ledger event naming the grant, the action and the subject. An action that proceeded under break-glass is permanently distinguishable from a properly approved one.
- The grant is time-boxed — a default of one hour, hard-capped at 24. An “emergency” that needs longer is an operating mode, not an emergency, and must go through normal dual-control.
- Forced post-review. A new grant cannot be activated while any prior grant is unreviewed, and the review must come from a different human than the activator. You cannot stack emergencies to dodge scrutiny.
Break-glass relaxes a missing quorum; it never overrides an explicit human rejection. A request someone deliberately denied stays denied.
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 map, the ledger itself) self-audit in a committed write. You cannot make an ungoverned change the ledger silently forgets.
The ledger is append-only, hash-chained, and Ed25519-signed. Each record carries seq,
prev_hash, hash and sig, so rewriting history is cryptographically detectable, and the
ledger never contains PII. For the external, immutable copy an auditor asks for, the ledger
is exposed as an authenticated pull export at /v1/audit/export, with format values
cef, leef, syslog, otlp and ocsf. Each exported record carries the chain-integrity
fields, so a SIEM or WORM store can re-verify the chain offline — the detached signature
defends against a database-only compromise, and the off-box copy against a fully compromised
host.
Honest scope
The authorization core, the approval engine and the ledger run today. What is still maturing is the richer operator review surface — a full approval-queue console; the endpoints and the server-side invariants are shipped, the polished UI is the path forward. As with the rest of the platform, this is pre-1.0 open core: read Honesty & limits for what is live versus design-toward. Olivares AI is designed toward SOC 2, ISO 27001 and EU AI Act controls, not certified against them.
Related
- Governance — the authorization model and self-audit posture in full.
- Permitted vs observed — the drift these decisions act on.
- Connect a source — wire the signals that drift is built from.
- Kill switch — the graduated emergency stop for the estate.