De HITL-gate zorgt ervoor dat geen hoog-risico agentactie doorgaat zonder menselijk oordeel. Dit kookboek doorloopt de volledige goedkeuringslevenscyclus — van het moment dat een bestuurde actie een verzoek afvuurt via risicotierbepaling, menselijke beslissingen, en de break-glass-noodklep — zodat je elk onderdeel kunt traceren voordat je het in productie tegenkomt.
Als je het autorisatiemodel nog niet hebt gelezen, begin dan met Bestuur. De handleiding Besturen & goedkeuren behandelt dezelfde mechanismen vanuit een operatorperspectief; deze pagina is de stap-voor-stap referentie.
De verzoeklevenscyclus
Een goedkeuringsverzoek opent deny-closed en tijdsgebonden. Het begint als pending, draagt een
verlooptijd, en autoriseert niets totdat voldoende mensen hebben beslist. Het verzoek kan
zijn eigen lat niet verlagen — een matchend goedkeuringsbeleid is gezaghebbend voor de drempel en
time-outs.
Het verzoek is gebonden aan een plan-hash van de exacte tool-call-payload. Dit is de anti-TOCTOU-verdediging: als de onderliggende actie verandert tussen verzoek en beslissing, komt de hash niet overeen en kan de goedkeuring niet binden. Een verouderde goedkeuring autoriseert nooit een andere actie.
Risicotierbepaling
Vier tiers bepalen hoeveel menselijke controle een bestuurde actie vereist:
| Tier | Wat het betekent |
|---|---|
low / medium | Alleen toegewezen door expliciet goedkeuringsbeleid — niets staat hier standaard |
high | De standaard voor alles wat de goedkeuringswachtrij bereikt. Eén menselijke goedkeuring vereist |
critical | Verplichte twee-personen-ondergrens (NIST SP 800-53 AC-3(2) dual authorization) |
Het tier wordt opnieuw afgeleid uit de live beleidsset bij elke beslissing, nooit gelezen uit een opgeslagen momentopname. Een beleidswijziging wordt onmiddellijk van kracht. Een verouderde rij kan de lat nooit lager houden dan de huidige classificatie — dit is deny-closed by construction.
De ingebouwde critical-set dekt het werkelijk onomkeerbare: productie-deploy en
-retire, gegevensverwijdering en -wissing, beveiligingshandhaving en noodstopwijzigingen, sleutel-
bewaring en -rotatie, en NHI-offboarding.
Een goedkeuringsbeleid met een expliciet risk_tier kan de standaard per actie verhogen of verlagen.
Maar het kan nooit een critical actie onder de dual-control-ondergrens verlagen.
Stap voor stap
1. Een bestuurde actie triggert een verzoek
Een bestuurde actie — deploy apply, agent fire, budgetoverschrijving, of elke actie die matcht met een
goedkeuringsbeleid — bereikt de goedkeuringsengine. De engine opent een nieuw verzoek in pending
status.
2. Het verzoek bindt aan een plan-hash
Het verzoek registreert een hash van de exacte tool-call-payload. Deze plan-hash-binding is de TOCTOU-verdediging: de beslissing autoriseert alleen de actie waarvoor het verzoek is aangemaakt.
3. Risicotier wordt bepaald vanuit huidig beleid
De engine evalueert de live beleidsset (RBAC, native ABAC en eventueel extern PDP) om het risicotier af te leiden. Het tier wordt nooit gecacht uit een eerdere evaluatie.
4. Een menselijke reviewer beslist
Een mens met voldoende rol geeft een approve of deny. De server dwingt drie
invarianten af op dit punt, gekoppeld aan stabiele gebruikersidentiteit:
- 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.
- Dubbele-beslisser-bewaking. Een unieke index backstopt een dubbele-beslisser-race — één mens telt één keer mee voor de drempel.
- Verloop bindt. Een verlopen verzoek kan nooit een bindende beslissing ontvangen, zelfs niet voordat een sweep het verloop materialiseert. De effectieve status wordt opnieuw afgeleid bij elke beslissing.
5. Kritieke acties: dual-control met AAL3
Voor critical tier: de drempel is gefloord op twee verschillende menselijke goedkeurders. De
ondergrens wordt zowel bij aanmaken (de opgeslagen drempel kan nooit onder twee beginnen) als
opnieuw toegepast bij beslissing (een verzoek dat is aangemaakt voordat de actie kritiek werd kan nog steeds niet
passeren met één mens).
Elke beslissende mens moet een verse hardware-geverifieerde sessie hebben — WebAuthn of PIV step-up (AAL3). Een systeemtoken draagt geen menselijke zekerheid en wordt geweigerd.
6. Beslissing wordt vastgelegd in het logboek
Elke beslissing voegt een onveranderlijke rij toe aan de beslissingstrail van het verzoek en een logboek- gebeurtenis die de beslissing, de resulterende status en het risicotier waaronder het is genomen vastlegt. Het logboek is append-only, hash-chained en Ed25519-ondertekend — herschrijven van de geschiedenis is cryptografisch detecteerbaar.
Verloop
Verloop wordt afgeleid bij lezing, niet eenmalig geschreven. Een verlopen verzoek kan nooit een bindende beslissing ontvangen, zelfs als er nog geen achtergrond-sweep het verloop heeft gematerialiseerd. De effectieve status wordt altijd opnieuw afgeleid, dus een trage sweep is een cosmetische vertraging, geen beveiligingsgat.
Beleidsconfiguratie
Goedkeuringsbeleiden laten je het standaard risicotier per actieklasse overschrijven. Een beleid met een
expliciet risk_tier kan een actie van high naar low verplaatsen, of een medium naar
critical verhogen. De ene beperking: je kunt nooit critical onder de dual-control-
ondergrens verlagen. De twee-personen-eis voor onomkeerbare acties is structureel, niet
configureerbaar.
Break-glass
Wanneer een quorum onbereikbaar is — het incident om 03:00 waar de tweede goedkeurder slaapt — biedt break-glass een geauditeerde noodklep. Het is luid by construction.
Activering vereist alle van:
- De activeerder is een admin, altijd een echte mens — een systeemtoken wordt geweigerd.
- Een verse AAL3 step-up (WebAuthn of PIV).
- Een schriftelijke verantwoording vastgelegd in dezelfde transactie.
- Een actief opgenomen sessie als voorwaarde.
Tijdsbegrenzing: de toekenning staat standaard op éé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.
Elk gebruik wordt vastgelegd. Elke actie onder break-glass voegt een onveranderlijke rij toe en een logboekgebeurtenis 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.
Verplichte nacontrole. Een nieuwe toekenning kan niet worden geactiveerd zolang een eerdere toekenning niet is beoordeeld. 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 afwijzing. Een verzoek dat iemand bewust heeft geweigerd, blijft geweigerd.
Wat wordt vastgelegd
Elke beslissing — goedkeuren, weigeren, verlopen of break-glass-gebruik — wordt op twee plaatsen vastgelegd:
- De beslissingstrail van het verzoek: een onveranderlijke reeks beslissingsrijen op het verzoek zelf, elk met de beslisser, het oordeel en het tijdstempel.
- Het auditlogboek: een hash-chained, Ed25519-ondertekende gebeurtenis die de beslissing, de resulterende verzoekstatus en het risicotier waaronder het is genomen vastlegt.
Beide schrijfacties vinden plaats in dezelfde transactie als de statuswijziging. Je kunt geen bestuurde beslissing nemen die het logboek stilzwijgend vergeet.
Gerelateerd
- Besturen & goedkeuren — de operatorhandleiding over dezelfde mechanismen.
- Bestuur — het autorisatiemodel, zelf-audithouding en noodstop-mechanismen.
- Kookboek: noodstop-oefening — de domeinbrede deny- gate-oefening.
- Noodstop — de productpagina voor de noodstop.