“Vraag eerst om toestemming.” Het is een logische instructie wanneer je AI koppelt aan WordPress, servers of andere beheersystemen. Het model moet een wijziging voorbereiden, uitleggen wat er gaat gebeuren en wachten tot een mens akkoord geeft.
Toch is die zin in een prompt geen echte beveiligingsgrens. Het blijft een gedragsinstructie binnen een gesprek. Een andere formulering, ontbrekende context of fout in de workflow kan ervoor zorgen dat de bedoeling niet op dezelfde manier wordt geïnterpreteerd.
Daarom heb ik toestemming in INDY niet alleen als conversatieregel ingericht. Iedere uitvoerende actie wordt in de backend een centraal taakobject. De backend bepaalt vervolgens of die taak direct mag worden uitgevoerd, eerst op goedkeuring moet wachten, geannuleerd kan worden of opnieuw geprobeerd mag worden.
De prompt helpt de samenwerking begrijpelijk te maken. De backend dwingt de veiligheidsregels technisch af.
Een taalmodel is geen autorisatiesysteem
Een taalmodel is goed in het begrijpen van een opdracht, verzamelen van context en formuleren van een passend voorstel. Autorisatie vraagt om iets anders: vaste toestanden, exacte identifiers en regels die niet afhankelijk zijn van interpretatie.
Stel dat ik vraag om een serverprobleem te onderzoeken. INDY kan vaststellen dat een service-reload waarschijnlijk voldoende is en mij om akkoord vragen. Wanneer ik later alleen “prima” antwoord, moet het systeem zeker weten waarop dat akkoord betrekking heeft.
Was het akkoord voor het onderzoeksvoorstel? Voor het herladen van PHP-FPM? Voor een volledige serverherstart? En geldt het nog wanneer er ondertussen een nieuwe taak is aangemaakt?
Een prompt kan deze context proberen te onthouden. Een backend kan haar exact vastleggen.
Van gebruikersopdracht naar centraal taakobject
Bij een uitvoerende opdracht maakt OPS daarom een taakobject aan. Dat object bevat onder meer de gevraagde actie, het doel, de invoer, de actuele status en het verificatieplan. Het krijgt een uniek taak-ID dat gedurende de volledige levenscyclus gelijk blijft.
Zo ontstaat een scheiding tussen het gesprek en de uitvoering. In het gesprek kan INDY uitleg geven, opties vergelijken en om toestemming vragen. De daadwerkelijke actie bestaat ondertussen als concreet object met een bekende scope.
- Welk domein, bericht, serverobject of incident wordt geraakt?
- Welke begrensde backendfunctie zal worden uitgevoerd?
- Welke invoer is vooraf gecontroleerd?
- Is menselijke goedkeuring verplicht?
- Hoe wordt het resultaat onafhankelijk geverifieerd?
- Is er een gecontroleerde rollback beschikbaar?
Deze gegevens hoeven niet opnieuw uit een los antwoord te worden afgeleid. Ze horen bij de taak zelf.
Goedkeuring moet aan het exacte taak-ID hangen
Een taak met impact krijgt eerst de status awaiting_approval. Ze mag pas worden vrijgegeven wanneer de gebruiker in de actuele conversatie expliciet akkoord geeft én de backendbevestiging het exacte taak-ID bevat.
Dat tweede deel is belangrijk. Een algemeen akkoord mag niet automatisch gelden voor iedere openstaande taak. Misschien zijn er meerdere voorstellen gemaakt. Misschien is de situatie veranderd. Misschien is een eerdere taak al geannuleerd en heeft een nieuwe poging een ander ID gekregen.
Door toestemming aan één onveranderlijk taak-ID te koppelen, wordt de autorisatie beperkt tot precies die voorbereide actie. Een akkoord voor een cacheflush kan niet worden hergebruikt voor een serverherstart. Een akkoord voor het publiceren van bericht 47 geldt niet voor een ander concept.
Het doelobject moet net zo exact zijn
Naast het taak-ID controleert INDY bij verschillende acties ook het doelobject. Een serveractie vereist bijvoorbeeld de actuele servernaam. Een WooCommerce-wijziging vereist hetzelfde product- of verzendmethode-ID in de bevestiging. Een nieuwe site vraagt om bevestiging van het exacte domein.
Deze dubbele koppeling voorkomt dat een geldige toestemming op het verkeerde object terechtkomt. Het taak-ID bevestigt de voorbereide workflow. De doelbevestiging controleert nogmaals waarop de uitvoerende functie daadwerkelijk zal werken.
Dat lijkt misschien overdreven voor eenvoudige handelingen. Zodra een systeem meerdere websites, servers en gelijktijdige opdrachten beheert, is die exactheid essentieel.
Een taakstatus is meer dan geslaagd of mislukt
Een centrale taaklaag maakt ook duidelijk dat uitvoering niet binair is. Een taak kan wachten op toestemming, in een wachtrij staan, actief worden uitgevoerd, opnieuw geprobeerd worden, geannuleerd zijn of wachten op verificatie.
Daarom rapporteert INDY een status als queued, running of retrying niet als voltooid resultaat. De backend heeft de actie dan wel geaccepteerd, maar het eindresultaat is nog niet bekend.
Pas nadat de uitvoering is afgerond en het verificatiecontract is doorlopen, mag een taak als werkelijk voltooid worden beschouwd. Voor een WordPress-publicatie betekent dat bijvoorbeeld dat het bericht gepubliceerd is én de publieke permalink correct reageert.
Annuleren zonder een tweede losse actie te starten
Een ander voordeel van centrale taken is dat annuleren een duidelijke betekenis krijgt. Zolang een taak nog niet definitief is uitgevoerd, kan ze via haar taak-ID worden geannuleerd.
Daarna mag dezelfde actie niet buiten het taakobject om alsnog worden gestart. Anders bestaat het risico dat de gebruiker denkt dat een opdracht is gestopt terwijl een tweede, los uitgevoerde variant toch doorgaat.
De taak is dus niet alleen een logregel. Ze is de eigenaar van de uitvoering. Goedkeuren, annuleren, opnieuw proberen en verifiëren blijven allemaal aan hetzelfde object gekoppeld.
Retries vragen opnieuw om technische context
Wanneer een taak mislukt, is “probeer nog eens” niet altijd veilig. De oorspronkelijke oorzaak kan nog aanwezig zijn, invoer kan verouderd zijn of een deel van de actie kan al zijn uitgevoerd.
Een retry hoort daarom alleen beschikbaar te zijn voor een aantoonbaar mislukte of geannuleerde taak. Eerst moet worden onderzocht waarom de vorige poging niet slaagde. Daarna kan dezelfde taak gecontroleerd opnieuw worden aangeboden, met behoud van pogingen en resultaten in het auditspoor.
Zo voorkom ik dat een tijdelijke fout leidt tot een onbegrensde herhaallus of dubbele wijzigingen.
Rollback is een afzonderlijke bevoegdheid
Sommige wijzigingen kunnen technisch worden teruggedraaid. Ook dat betekent niet dat AI automatisch een rollback mag uitvoeren zodra een verificatie mislukt.
OPS markeert daarom expliciet of een verandering rollbackbaar is en bewaart daarvoor een change-ID. Terugdraaien vereist een nieuwe, expliciete herstelopdracht die precies naar dat change-ID verwijst.
Dit maakt rollback tot een gecontroleerde vervolgactie, niet tot een onzichtbaar onderdeel van foutafhandeling. De gebruiker weet wat wordt teruggezet en de backend weet exact welke eerdere wijziging erbij hoort.
Auditsporen worden onderdeel van het ontwerp
Wanneer iedere actie een centraal taakobject heeft, ontstaat vanzelf een bruikbaar auditspoor. Niet alleen de uiteindelijke status wordt bewaard, maar ook de voorbereiding, vereiste toestemming, uitvoeringspogingen, verificatie en eventuele rollbackinformatie.
Bij een fout kan ik daardoor vragen:
- Welke taak is precies goedgekeurd?
- Door welke begrensde functie is ze uitgevoerd?
- Hoeveel pogingen zijn gedaan?
- Welk resultaat gaf iedere poging?
- Welke onafhankelijke controle is uitgevoerd?
- Is er een herstelobject beschikbaar?
Dat is veel sterker dan alleen een gesprekslog waarin ergens het woord “akkoord” voorkomt.
De prompt blijft belangrijk, maar krijgt de juiste rol
Dit betekent niet dat promptinstructies overbodig zijn. Ze zorgen ervoor dat INDY begrijpelijk uitlegt wat er gaat gebeuren, risico’s benoemt en pas om toestemming vraagt wanneer het voorstel compleet is.
De prompt bewaakt vooral de kwaliteit van de samenwerking. De backend bewaakt de bevoegdheid.
Die combinatie werkt beter dan beide afzonderlijk. Zonder goede uitleg wordt toestemming een blind vinkje. Zonder technische handhaving blijft een zorgvuldig gesprek afhankelijk van correct modelgedrag.
Veilige autonomie vraagt om harde toestanden
Hoe meer INDY zelfstandig kan onderzoeken en voorbereiden, hoe belangrijker een duidelijke grens tussen voorstellen en uitvoeren wordt. Die grens mag niet alleen in natuurlijke taal bestaan.
Een betrouwbare workflow heeft daarom harde toestanden: voorbereid, wachtend op toestemming, goedgekeurd, in uitvoering, te verifiëren, voltooid, mislukt of geannuleerd. Iedere overgang heeft eigen voorwaarden.
Juist die structuur maakt verdere autonomie mogelijk. INDY kan zelfstandig context verzamelen, een beperkte actie selecteren en een volledig voorstel voorbereiden. Maar de backend bepaalt of de volgende stap volgens de actuele taakstatus is toegestaan.
Toestemming is infrastructuur
Ik zie goedkeuring daarom niet langer als één beleefde vraag in een chat. Het is infrastructuur: een technische relatie tussen een gebruiker, een exact taakobject, een doel en een toegestane statusovergang.
De prompt kan zeggen: “Ik wacht op je akkoord.” De backend moet ervoor zorgen dat wachten ook werkelijk verplicht is.
Dat verschil maakt AI-automatisering niet alleen veiliger. Het maakt haar ook beter uitlegbaar, beter te testen en uiteindelijk veel eenvoudiger om verantwoord op te schalen.