Zodra een bron is aangesloten en de toegangskaart toont wat elke agent kan lezen en schrijven, is de volgende taak het besturen: beslissen wie en wat mag handelen, en elke beslissing een vastgelegd feit maken. Deze pagina behandelt de goedkeuringsworkflow — risicotiers, dual-control, break-glass en het logboek waar ze allemaal op verankerd zijn.
Bestuur is deny-closed als standaard. Een principal zonder rol in een tenant wordt geweigerd; er is geen impliciete toekenning. Het product observeert breed maar actueert niet breed — waar het een actie bestuurt, doet het dat deny-closed, nooit als een generieke executor.
Het autorisatiemodel
Elke bestuursaanroep gaat door dezelfde autorisatiekern als de rest van de API: RBAC eerst, afgebakend op een enkele tenant, met een optionele externe beleidslaag erboven.
Rollen vormen een ladder — viewer (lezen), editor (schrijven), admin (tenant-IAM), owner
(alles in de tenant). Het lezen van de toegangskaart is bewust niet het laagste tier:
een kaart van wat elke agent kan bereiken is een verkenningsroutekaart, dus het wordt verleend van editor en hoger,
tenant-afgebakend, en elk leesverzoek wordt naar het logboek geschreven.
Een optioneel beleidsbeslissingspunt (Cedar ingebouwd, of OPA via HTTP) kan op attributen gebaseerde regels erboven leggen. Het componeert als een doorsnede — RBAC ∩ native ABAC ∩ extern PDP — en heeft één invariant:
De beleidslaag kan alleen toegang wegnemen, nooit toevoegen. Een beleid kan iets weigeren dat RBAC zou hebben toegestaan; het kan nooit iets toekennen dat RBAC weigert. Een verkeerd geconfigureerd of onbereikbaar PDP faalt closed, en het uitschakelen van het externe PDP laat verzoeken nooit onbestuurd — native RBAC en ABAC blijven besturen.
Risicotiers
Een bestuurde actie wordt geclassificeerd in een van vier tiers — low, medium, high,
critical — afgeleid van de OWASP AI-agent-risicotaxonomie. Het tier bepaalt hoeveel menselijke
controle de actie vereist voordat het kan doorgaan.
Het tier wordt niet opgeslagen op de goedkeuringsrij. Het wordt opnieuw afgeleid uit de huidige beleidsset plus een ingebouwde standaard bij elke beslissing, dus een beleidswijziging wordt onmiddellijk van kracht en een verouderde momentopname kan de lat nooit onder de live classificatie houden (deny-closed).
| Tier | Standaard controle |
|---|---|
low / medium | alleen toegewezen door expliciet beleid |
high | de standaard voor alles wat de goedkeuringswachtrij bereikt — één menselijke goedkeuring |
critical | een verplichte twee-personen-ondergrens (zie hieronder) |
De ingebouwde critical-set dekt het werkelijk onomkeerbare: productie-deploy en -retire,
gegevensverwijdering en -wissing, beveiligingshandhaving en noodstopwijzigingen, sleutelbewaring en
-rotatie, en NHI-offboarding. Een goedkeuringsbeleid met een expliciet risk_tier kan de
standaard per actie verhogen of verlagen — dat is het geauditeerde woord van de operator — maar het kan nooit een
critical actie onder de dual-control-ondergrens verlagen.
Goedkeuringsverzoeken en dual-control
Een goedkeuringsverzoek opent deny-closed en tijdsgebonden: het begint als pending, draagt een verlooptijd, en autoriseert niets totdat voldoende mensen beslissen. Een matchend goedkeuringsbeleid is gezaghebbend voor de drempel en time-outs, dus een aanvrager kan nooit zijn eigen lat verlagen.
Drie invarianten worden server-side afgedwongen, niet als conventie:
- Functiescheiding. De aanvrager kan niet over zijn eigen verzoek beslissen. Dit is gekoppeld aan de stabiele gebruikersidentiteit, niet de credentialstring die een persoon zou kunnen variëren.
- Eén beslissing per mens. Een unieke index backstopt een dubbele-beslisser-race; dezelfde persoon kan niet twee keer meetellen voor de drempel.
- Verloop bindt. Een verlopen verzoek kan nooit een bindende beslissing ontvangen — de effectieve status wordt opnieuw afgeleid bij elke beslissing, sweep of geen sweep.
Voor critical acties is de drempel gefloord op twee verschillende menselijke goedkeurders (NIST
SP 800-53 AC-3(2) dual authorization). De ondergrens wordt zowel afgedwongen wanneer het verzoek wordt
aangemaakt (de opgeslagen drempel kan nooit onder twee beginnen) als opnieuw toegepast bij het beslissingspunt
(een verzoek dat is aangemaakt voordat de actie kritiek werd kan nog steeds niet passeren met één
mens). Een enkele goedkeurder kan nooit een kritieke actie vervullen.
Een critical beslissing vereist bovendien een hardware-geverifieerde sessie: de beslissende
mens moet een verse WebAuthn- of PIV-step-up hebben (AAL3). Een systeemtoken draagt geen menselijke
zekerheid en wordt geweigerd — een systeemtoken kan niet goedkeuren.
Elke beslissing voegt een onveranderlijke rij toe aan de beslissingstrail van het verzoek en een logboekgebeurtenis die de beslissing, de resulterende status en het risicotier waaronder het is genomen vastlegt.
Break-glass
Twee-personen-controle heeft een noodklep voor het incident om 03:00 waar de tweede goedkeurder onbereikbaar is. Een admin — altijd een echte mens, nooit een systeemtoken — activeert een tijdsgebonden noodtoekenning die een gegated actie laat doorgaan zonder zijn quorum. Het pad is nooit stil:
- Activering vereist een verantwoording, zelf-auditeert naar het logboek in dezelfde transactie, en zendt een kritieke bevinding uit naar de notificatierail.
- Elk gebruik voegt een onveranderlijke rij en een logboekgebeurtenis toe met vermelding van de toekenning, de actie en het onderwerp. Een actie die onder break-glass is doorgegaan is permanent onderscheidbaar van een correct goedgekeurde.
- De toekenning is tijdsgebonden — standaard één uur, hard begrensd op 24. Een “noodgeval” dat langer nodig heeft is een operationele modus, geen noodgeval, en moet via de normale dual-control-procedure.
- Verplichte nacontrole. Een nieuwe toekenning kan niet worden geactiveerd zolang een eerdere toekenning niet is beoordeeld, en de beoordeling moet komen van een andere mens dan de activeerder. Je kunt noodgevallen niet stapelen om controle te ontlopen.
Break-glass versoepelt een ontbrekend quorum; het overschrijft nooit een expliciete menselijke afwijzing. Een verzoek dat iemand bewust heeft geweigerd, blijft geweigerd.
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 toegangskaart, het logboek zelf) zelf-auditeren in een gecommitteerde schrijfactie. Je kunt geen onbestuurde wijziging maken die het logboek stilzwijgend vergeet.
Het logboek is append-only, hash-chained en Ed25519-ondertekend. Elk record bevat seq,
prev_hash, hash en sig, dus herschrijven van de geschiedenis is cryptografisch detecteerbaar, en het
logboek bevat nooit PII. Voor de externe, onveranderlijke kopie die een auditor vraagt, wordt het logboek
blootgesteld als een geauthenticeerde pull-export op /v1/audit/export, met format-waarden
cef, leef, syslog, otlp en ocsf. Elk geëxporteerd record bevat de keten-integriteitsvelden,
zodat een SIEM- of WORM-opslag de keten offline kan herverifiëren — de losstaande handtekening
beschermt tegen een database-only compromis, en de off-box kopie tegen een volledig gecompromitteerde
host.
Eerlijk bereik
De autorisatiekern, de goedkeuringsengine en het logboek draaien vandaag. Wat nog in ontwikkeling is, is het rijkere operatorreviewoppervlak — een volledige goedkeuringswachtrij-console; de endpoints en de server-side invarianten worden geleverd, de gepolijste UI is het pad vooruit. Zoals bij de rest van het platform, is dit pre-1.0 open core: lees Eerlijkheid & beperkingen voor wat live is versus design-toward. Olivares AI is ontworpen richting SOC 2, ISO 27001 en EU AI Act-controles, niet gecertificeerd ertegen.
Gerelateerd
- Bestuur — het autorisatiemodel en zelf-audithouding in detail.
- Toegestaan versus waargenomen — de drift waarop deze beslissingen handelen.
- Een bron aansluiten — sluit de signalen aan waaruit drift wordt opgebouwd.
- Noodstop — de gefaseerde noodstop voor het domein.