Bestuur: lezen-eerst & deny-closed

Bestuur in Olivares AI is gebouwd op twee principes die je tegelijk kunt onthouden: observeer voordat je handhaaft, en wanneer je handhaaft, standaard op nee. Het product brengt in kaart en auditeert wat elke agent kan bereiken lang voordat het één enkele actie blokkeert, en de gates die het wel draait zijn deny-closed.

Lezen-eerst: observatie vóór handhaving

De standaardhouding van het platform is detectief, niet preventief. Het bouwt de lees/schrijf-toegangskaart door logs, OpenTelemetry en native audit out-of-band op te nemen — het zit nooit in het datapad van de agent, dus een collector die faalt kan productie niet meenemen. Vanuit die kaart vergelijkt het toegestaan met waargenomen en toont drift voor een mens om te beoordelen.

Dit is belangrijk voor hoe je de rest van deze pagina leest. Het product observeert en bestuurt breed; het actueert niet breed. Waar het een actie kan uitvoeren op je infrastructuur, is die mogelijkheid een van drie dingen, en de modulecatalogus markeert welke:

• live — aangesloten en actief vandaag (een beperkte set);
• on-demand — de backend is gebouwd en aangesloten op een injectiepunt maar blijft deny-closed of gedegradeerd totdat je het inricht (een executor, een dispatcher, een inferentie-credential);
• seam — een gedeclareerde, deny-closed interface zonder backend in de standaard binary.

Dus een afwezigheid van handhaving is meestal by design, geen omissie. Lezen-eerst betekent dat de eerlijke standaard is om te kijken en vast te leggen, en alleen de oppervlakken te gaten die je expliciet hebt ingeschakeld.

Het autorisatiemodel waarbinnen je bestuurt

Elke bestuurde beslissing gaat door dezelfde autorisatiekern die de rest van de API beschermt. Drie eigenschappen zijn het verinnerlijken waard voordat je iets wijzigt.

RBAC is deny-by-default. Een principal zonder lidmaatschap in een tenant wordt geweigerd — er is geen impliciete toekenning. Rechten zijn tenant-afgebakend, en een handler handelt alleen op de enkele tenant waarnaar het verzoek is opgelost, wat confused-deputy- en IDOR-klassen door constructie sluit. Rollen vormen een ladder: viewer leest, editor schrijft, admin beheert tenant-IAM, owner heeft alles. Het lezen van de toegangsgrafiek is bewust een editor-en-hoger privilege — een volledige kaart van wat elke agent kan bereiken is een verkenningsroutekaart — en elk dergelijk leesverzoek wordt naar het auditlogboek geschreven.

De beleidsnaad beperkt alleen. Bovenop RBAC kun je een op attributen gebaseerd beleidsbeslissingspunt aansluiten. De samenstelling is een doorsnede — RBAC ∩ native ABAC ∩ extern PDP — dus een beleid kan alleen verder beperken wat RBAC al heeft toegestaan; het kan nooit een toekenning verbreden. Dit wordt afgedwongen, niet als conventie. Je kiest maximaal één externe engine:

# Embedded Cedar (pure-Go, geen sidecar) of OPA via HTTP. Standaard: geen.
OLIVARES_PDP_ENGINE=cedar   # of: opa | none

Met Cedar schrijf je forbid-regels; een lege regelset laat de RBAC-beslissing staan. Met OPA moet je Rego permit-by-default zijn, waarbij een ontbrekend resultaat of elke transportfout fail-closed is. Een ongeldige PDP-configuratie schakelt alleen het externe PDP uit en logt het feit — native ABAC en RBAC blijven besturen, en een verkeerd geconfigureerde engine laat nooit een verzoek onbestuurd. Elke beperking die het PDP toepast wordt geauditeerd.

Risicotiers en de dual-control-ondergrens

Acties die de goedkeuringswachtrij bereiken worden geclassificeerd in vier risicotiers — low, medium, high, critical — volgens de OWASP AI-agent-taxonomie. (Dit is een afzonderlijke as van de EU AI Act-compliancetiers; verwar de twee niet.) Het tier wordt opnieuw afgeleid van het live beleid bij elke beveiligingsbeslissing, nooit gelezen van een opgeslagen momentopname, dus een beleidswijziging wordt onmiddellijk van kracht en een verouderde rij kan de lat nooit lager houden dan de huidige classificatie.

Een critical actie heeft een verplichte twee-personen-ondergrens: ten minste twee afzonderlijke menselijke goedkeurders, ontleend aan NIST SP 800-53 AC-3(2) dual authorization. De ondergrens wordt twee keer afgedwongen — bij aanmaken (de opgeslagen drempel kan nooit onder die waarde beginnen) en opnieuw afgeleid bij beslissing (een verlaagde of verouderde rij kan nog steeds niet met één goedkeurder passeren) — dus zelfs een operatorbeleid dat het tier expliciet verlaagt kan een kritieke actie niet eenhands maken. De ingebouwde critical-set is de onomkeerbare, domeinvormende familie: productie-deploy en -retire, gegevensverwijdering, wijzigingen in beveiligingshandhaving, sleutelbewaring en -rotatie, en het opnieuw inschakelen van het domein na een noodstop.

Lagere tiers veranderen de mechanica van de engine niet — een goedkeuring die al bestaat vereist minimaal één mens — ze zijn het vocabulaire waar andere controles op inhaken (bijvoorbeeld authenticatie opschalen bij een kritieke actie).

De human-in-the-loop-goedkeuringsgate

Waar het product een actie gatet, is de loop: een oppervlak presenteert (drift vanuit de toegangskaart, een bevinding van de beveiligingsmodule) → een geautoriseerde operator beslist → de beslissing wordt vastgelegd in het auditlogboek. De goedkeuringsengine die dit ondersteunt is vandaag operationeel: een verzoek opent deny-closed, gebonden aan een plan-hash, en tijdsgebonden. De invarianten worden server-side afgedwongen, gekoppeld aan de stabiele gebruikersidentiteit (een systeemtoken heeft geen identiteit en kan niet beslissen):

• Functiescheiding — de aanvrager kan nooit zijn eigen verzoek beoordelen.
• Dubbele-beslisser-bewaking — één mens telt één keer mee voor een drempel.
• Verloop — afgeleid bij lezing, zodat een verlopen verzoek nooit kan binden, zelfs niet voordat een sweep het verloop materialiseert.

Wat nog in ontwikkeling is, is de rijkere operatorreviewconsole; de endpoints en de engine worden vandaag geleverd. De handleiding Besturen en goedkeuren doorloopt de live stroom.

De afhankelijkheid die dit alles geloofwaardig maakt is per-agent-identiteit. Audit schrijft activiteit toe aan een credential, niet inherent aan een agent; een gedeeld serviceaccount comprimeert attributie tot identiteitsniveau — eerlijk getoond als bevinding, nooit stilzwijgend hersteld. Zie toegestaan versus waargenomen en betrouwbaarheid voor wat dat doet met het signaal waarop je bestuurt.

Break-glass: de geauditeerde noodklep

Twee-personen-controle heeft een noodklep nodig voor het incident om 03:00 waar één goedkeurder onbereikbaar is. Break-glass is die klep, en het is luid by construction. Activering is admin-tier en vereist een echte mens (een systeemtoken wordt geweigerd), een hardware-geverifieerde (AAL3) step-up, een schriftelijke verantwoording, en een actief opgenomen sessie als voorwaarde. De toekenning is tijdsgebonden — standaard één uur, harde limiet één dag — en een verlopen toekenning kan niets autoriseren.

Terwijl een toekenning actief is, mag een actie binnen bereik doorgaan zonder zijn goedkeuringsquorum, maar elk gebruik wordt toegevoegd aan een onveranderlijke trail en het auditlogboek, met vermelding van de toekenning, de actie en het onderwerp — een actie die onder break-glass is doorgegaan is permanent onderscheidbaar van een goedgekeurde actie. Een verplichte nacontrole sluit de loop: een nieuwe toekenning kan niet worden geactiveerd zolang een eerdere onbeoordeeld is, en de beoordeling moet komen van een andere mens dan de activeerder.

De noodstop: de domeinbrede deny-gate

De noodstop is de one-click noodstop, en het keert de gebruikelijke ergonomie bewust om. Inschakelen is bewust goedkoop — admin-tier, een verplichte reden, geen goedkeuringsquorum, geen step-up, geen break-glass — want een stop die wacht op consensus is geen stop. Het assurance-level van de inschakelende sessie wordt vastgelegd voor forensisch onderzoek; misbruik van inschakelen kost alleen beschikbaarheid, wat de veilige richting is.

De stoprij is de single source of truth. Elke bestuurde actuatiegate raadpleegt deze live bij elke actie en faalt closed bij een leesfout — het exacte omgekeerde van het fail-open-contract van de budgetgates, want een onleesbare stopstatus mag nooit “doorgaan” betekenen. Inschakelen herroept ook het werk in de wachtrij dat de gates niet kunnen bereiken: elke lopende in-scope actuatiegoedkeuring wordt geannuleerd in dezelfde transactie, zodat een pre-stop-intentie niet kan rijpen tot een toekenning die dispatcht op het moment dat het domein terugkomt. Bestuursacties zelf zijn vrijgesteld — de stop stopt het agentdomein, nooit de controles die het besturen.

Opnieuw inschakelen is nooit eenzijdig. Het is gegated op een nieuwe dual-control-goedkeuring (de critical twee-verschillende-mensen-ondergrens, structureel opnieuw geverifieerd bij de omschakeling zodat een verlaagd beleid het niet eenhands kan maken), en er is bewust geen break-glass-pad voor opnieuw inschakelen: “het domein blijft gestopt” is de veilige toestand. Een verplichte nacontrole door een niet-betrokken mens sluit het incident.

De vastgelegde-beslissingen-garantie

Ongeacht de diepte van de workflow erboven, is een bestuursbeslissing een vastgelegd feit. Muterende acties worden toegevoegd aan het auditlogboek met de echte actor in dezelfde transactie als de wijziging, en gevoelige lezingen (de toegangsgrafiek, het logboek zelf) zelf-auditeren in een gecommitteerde schrijfactie. Het logboek is append-only en hash-chained, elk record bevat de keten-integriteitsvelden, dus herschrijven van de geschiedenis is detecteerbaar en het bevat nooit PII. Je kunt geen onbestuurde wijziging maken die het logboek stilzwijgend vergeet.

Gerelateerd

• Toegestaan versus waargenomen — de drift waarop deze beslissingen handelen.
• Betrouwbaarheid — hoe zeker het signaal onder een beslissing is.
• Besturen en goedkeuren — de live goedkeuringsstroom, stap voor stap.
• Noodstop — de domeinbrede deny-gate in productermen.
• Eerlijkheid & beperkingen — de deny-closed, detective-by-default houding in detail.