Er is een klassiek spanningsveld in elk bedrijf dat software maakt: je wilt mensen zelfstandig laten werken, maar zelfstandig werken vraagt normaal om toegang, en toegang is precies wat je liever niet uitdeelt. Hoe meer mensen een wachtwoord van je testomgeving hebben, hoe groter de kans dat er iets uitlekt of misgaat. Ik heb voor een collega zonder technische achtergrond een manier gebouwd waarop hij zijn eigen werk live kan zetten op een testomgeving, zonder dat hij ook maar één inloggegeven in handen heeft. En als het misgaat, staat er een Ai-vangnet klaar dat de fout uitlegt en waar mogelijk oplost.

Het uitgangspunt: geen credentials weggeven#

De verleiding is om iemand die zelfstandig wil deployen gewoon toegang te geven tot de server, of een setje inloggegevens. Dat is snel geregeld, maar het is ook precies de verkeerde afslag. Elke sleutel die je uitdeelt, is een sleutel die je kwijt kunt raken, die op een verkeerde plek belandt, of die per ongeluk te veel rechten geeft. En bij iemand die niet technisch is, kun je ook niet verwachten dat hij weet hoe je zorgvuldig met zulke geheimen omgaat. Dat is geen verwijt, het is gewoon niet zijn vak.

Dus draaide ik de vraag om: hoe kan iemand deployen zónder dat hij ook maar iets van waarde in handen heeft? Het antwoord werd een tussenlaag. De collega drukt in feite op een knop. Die knop stuurt een bericht naar een tussenstation, en dat tussenstation, dat wél op de veilige plek draait, doet het eigenlijke werk. De collega raakt de server nooit aan, heeft geen toegang tot de opslag van geheimen, zit niet in de groep met verhoogde rechten. Hij vraagt alleen: zet mijn werk live. De machinerie erachter voert het uit.

Identiteit uit een token, niet uit een wachtwoord#

Nu ontstaat er een nieuwe vraag: als de collega alleen een knop indrukt, hoe weet het systeem dan wie er drukt, en of die persoon dat überhaupt mag? Daarvoor gebruik ik een token: een uniek, geheim sleuteltje dat bij die knop hoort. Elk verzoek dat binnenkomt, draagt dat token bij zich. Het tussenstation controleert of het token klopt, en leidt daaruit af wie de aanvrager is en wat hij mag. De identiteit komt dus uit het token zelf, niet uit een wachtwoord dat iemand intypt en dat afgekeken of gedeeld kan worden.

Dit is een belangrijk verschil. De identiteit zit niet in iets wat de gebruiker beweert (“ik ben die en die”), maar in iets wat het systeem zelf kan verifiëren. De aanvrager kan niet zomaar roepen dat hij iemand anders is, of dat hij meer rechten heeft. Wat hij mag, is vastgelegd aan de token-kant, buiten zijn bereik.

En dat heb ik niet op mijn blauwe ogen aangenomen. Ik heb geprobeerd het te breken. Ik ging na of je die identiteit kon vervalsen: kon je je voordoen als iemand met meer rechten, kon je de tussenlaag laten geloven dat een verzoek van een ander kwam? Dat lukte niet. De identiteit komt deterministisch uit het token, en er was geen pad om er iets anders van te maken. Zo’n poging tot vervalsing bewust zelf uitvoeren, is wat mij betreft geen luxe maar een verplichting. Een beveiliging waarvan je alleen aannéémt dat hij werkt, is geen beveiliging. Je moet er zelf tegenaan duwen.

Belangrijk: dit geldt voor testomgevingen, niet voor betalende klanten#

Er hoort meteen een grens bij. Deze zelfstandigheid geldt voor testomgevingen, waar een fout hooguit wat ongemak oplevert en niks onomkeerbaars raakt. De omgevingen waar echte, betalende klanten op draaien, blijven bewust buiten deze zelfbediening. Die zet alleen de eigenaar live, met een expliciete, bewuste handeling.

Dat onderscheid is geen willekeur. Een testomgeving is een oefenterrein: gaat er iets stuk, dan bouw je het opnieuw op. Een productieomgeving met betalende klanten is een eenrichtingsdeur, waar een fout echte gevolgen heeft voor mensen die je vertrouwen. De mate van vrijheid die je iemand geeft, hoort mee te schalen met wat er kapot kan. Ik werk die redenering verder uit in mijn stuk over waarom je een LLM nooit op de productie-knop laat drukken.

Het Ai-vangnet: als een deploy faalt#

Zelfstandig werken betekent dat er ook zelfstandig dingen misgaan. Een deploy die onderuit gaat, is voor iemand zonder technische achtergrond een muur van onbegrijpelijke foutmeldingen. Vroeger betekende dat: stoppen, mij erbij halen, wachten. Dat is precies de afhankelijkheid die je wilde wegnemen.

Daarom staat er een Ai-agent klaar die inspringt zodra een deploy faalt. Die doet drie dingen. Eerst een grondige foutanalyse: wat ging er precies mis, en waarom? Vervolgens, en dat is het waardevolle voor een niet-technische collega, legt hij dat in begrijpelijke taal uit. Geen brij aan technische logregels, maar een heldere uitleg zodat de collega ervan leert in plaats van er alleen door gefrustreerd te raken. En als de oorzaak mechanisch en veilig op te lossen is, iets kleins en ondubbelzinnigs, dan lost de agent het zelf op.

Cruciaal daarbij is dat woordje “mechanisch en veilig”. De agent fikst alleen het soort fout waar geen oordeel of risico bij komt kijken: een ontbrekend bestand, een verkeerd verwezen onderdeel, een triviale vergissing in de opzet. Alles wat inhoudelijk gevoelig ligt, of waar een keuze bij hoort, of waar risico aan kleeft, lost hij nadrukkelijk níét zelf op. Dan blijft het bij een heldere diagnose en gaat het naar een mens. Zo krijg je het beste van twee werelden: de kleine, saaie fouten worden automatisch weggepoetst, en de collega leert onderweg, terwijl de echt lastige dingen bij iemand terechtkomen die de gevolgen kan overzien.

Wat betekent dit voor jouw bedrijf?#

De onderliggende gedachte is breder toepasbaar dan alleen software deployen. Overal waar je iemand zelfstandigheid wilt geven zonder gevaarlijke toegang uit te delen, gelden dezelfde principes.

  1. Geef mensen een knop, geen sleutels. Laat een tussenlaag het gevoelige werk doen op de veilige plek. De gebruiker vraagt, het systeem voert uit. Zo hoeft niemand toegang te hebben tot wat kwetsbaar is.
  2. Laat identiteit voortkomen uit iets dat het systeem controleert. Niet uit wat iemand beweert te zijn, maar uit een token of een verificatie die niet te vervalsen is. En test die vervalsing zelf actief, neem nooit aan dat het veilig is.
  3. Schaal vrijheid met risico. Wat op een oefenterrein misgaat, mag iemand zelf doen. Wat echte klanten en echt geld raakt, hoort achter een bewuste, menselijke handeling.
  4. Zet een vangnet neer dat uitlegt, niet alleen repareert. Een Ai die een fout in begrijpelijke taal uitlegt, maakt mensen zelfstandiger. Laat het automatisch oplossen beperkt tot het veilige, mechanische werk, en stuur de rest naar een mens.

Wil je uitzoeken hoe je in jouw bedrijf mensen meer zelfstandigheid kunt geven zonder de sleutels van het koninkrijk uit te delen? Kijk dan op de consulting-pagina hoe ik werk. En op mijn downloads-pagina vind je een Ai-stoplicht dat je helpt vastleggen wie wat zelfstandig mag doen, en waar een mens ertussen hoort.