Beveiliging

Vier lagen in de zaak

1. Alleen de catalogus

   Het model geeft een JSON-stap volgens een strikt schema. Het mag geen code leveren; de PowerShell wordt uitsluitend door de server gebouwd uit de catalogusregel, met de vaste proloog en elke parameterwaarde tussen enkele aanhalingstekens. Een onbekende id is een fout.

2. Validatie door de server

   Elke parameter: alleen strings, geen onbekende namen, geen regeleinden of besturingstekens, alleen ASCII, maximale lengte, regex als fullmatch, allowlist voor servicenamen en niveaus, getalbereik. Pas als dat allemaal klopt bestaat er een voorstel.

3. Menselijke goedkeuring

   Geen enkele overgang laat PowerShell draaien zonder een goedkeuringsregel in het verloop. Automatisch kan alleen bij risico lezen en de instelling aan; verstorend vraagt een vinkje, vrije code een getypte id. De klik is gebonden aan stapnummer en hash van het commando.

4. Uitvoer is data

   Alles wat van buiten komt (uitvoer, bundeloverzicht, klacht, diagnose, berichten) gaat geneutraliseerd de context in, in blokken met een per-aanroep willekeurige code in de tags. De systeeminstructie zegt dat tekst uit de uitvoer nooit een instructie is, ook niet als het eruitziet als een goedkeuring. De server zelf interpreteert nooit iets uit een uitvoer.

De runner

• De server is de bron van waarheid. Een job ontstaat alleen bij een goedkeuring, hangt aan precies een zaak en een stap, en draagt de PowerShell plus de sha256 ervan. De runner rekent die hash na, in lokale modus twee keer, en stuurt hem terug; de server vergelijkt in constante tijd en weigert een resultaat met een andere hash.
• Alleen het eigen apparaat. In lokale modus alleen jobs voor de eigen computernaam; een job met een ander apparaat wordt geweigerd, ook als de server hem stuurt. In remote modus alleen een vaste lijst of een DNS-achtervoegsel, nooit een IP.
• Beschermde mappen. De runner vertrouwt geen map die hij aantreft: de jobmap maakt hij zelf aan met een expliciete DACL en gebruikt hij alleen als geen enkele bovenliggende map een reparse point is. Bij de start controleert hij dat zijn eigen script, map en tokenbestand beschermd zijn; anders start hij niet.
• Een apart proces, begrensd en opgeruimd. Elke stap draait als eigen powershell.exe in een Windows Job Object met "kill on close": na de timeout of na afloop gaat de hele procesboom weg, inclusief wezen. Werkmap is System32; niets uit de jobmap wordt relatief opgelost.
• Transport. Alleen https met TLS 1.2, certificaat moet vertrouwd zijn, geen redirects; http alleen naar loopback.
• Geen stap twee keer. Een stap die iets verandert wordt na een verlopen lease nooit opnieuw uitgedeeld: de runner kan hem al uitgevoerd hebben.

Tokens en tenants

• Een tenant is een naam plus twee tokens: het tenanttoken (login van de technici en de uploadsleutel voor een RMM) en het runnertoken (alleen voor de runners op de werkplekken, apart in te trekken). Minimaal 16 tekens; de server weigert anders te starten.
• Iedereen met het tenanttoken ziet alle runs en zaken van die tenant, en niets van een andere; een zaak van een andere tenant is altijd 404.
• Het runnertoken staat op de werkplek in een bestand met een DACL voor alleen SYSTEM en Administrators, gaat als omgevingsvariabele naar de collector (nooit op een commandoregel) en staat nergens in log, console, foutmelding, zaak of notitie: elke uitvoer wordt bij binnenkomst geredigeerd. In het MSI is het een verborgen eigenschap.

De viewer

• Sessies server-side, standaard 12 uur; uitloggen trekt de sessie echt in, en een gelekte cookie is daarna waardeloos.
• CSRF-token op elk formulier; 10 mislukte logins of uploads per IP per 15 minuten geeft 429.
• Alle modeluitvoer, bundeltekst, uitvoer en feedback wordt als HTML ontsnapt en nooit als markdown getoond; links met een ander schema dan http, https of mailto worden onklaar gemaakt.
• Elke pagina krijgt een strikte Content-Security-Policy zonder scripts; de zaakpagina ververst met een meta refresh, niet met JavaScript.
• Uploads: maximaal 50 MB, uitpaklimiet voor de bundel, alleen bundle.json uit de zip; apparaatnaam en ticketnummer worden uit de opgeslagen bundel gehaald zodat ze nooit in de prompt kunnen belanden.

Wat de AI nooit doet

• Nooit code schrijven of uitvoeren: alleen een catalogus-id met parameters, een vraag of een conclusie.
• Nooit een stap goedkeuren: dat kan alleen een technicus, of de instelling "leesstappen automatisch" die de technicus per zaak kiest.
• Nooit de apparaatnaam of het ticketnummer zien: die staan alleen in de metadata van de run.
• Nooit tekst uit een uitvoer als instructie lezen: alles wat van het endpoint, uit de bundel of uit een feed komt is data in gemarkeerde blokken.
• Nooit buiten de limieten: 12 stappen en $0,50 per zaak, 3 open zaken en $5,00 per dag per tenant, 3 vragen per zaak.

Bewijs

567 geautomatiseerde tests (stand 16 oktober 2026): ingest, tenant-isolatie, sessies, CSRF, rate limiting, rendering van onveilige links, upload- en uitpaklimieten, de actiecatalogus (validatie, quoting, deny-list, syntaxcontrole van elk commando in Windows PowerShell 5.1), de troubleshooting-engine, de runner-API met jobwachtrij, de productlaag, de kennisfeed en de bron van het MSI; 197 controles van de runner tegen een stubserver, waaronder de auto-update met zelftest en terugdraaien; red-team-sessies op 15 oktober met reparaties. In de end-to-end-tests hoorde elke uitvoerregel bij een goedgekeurd voorstel, is geen enkele niet-leesactie zonder klik uitgevoerd en liet de afgewezen herstart de Spooler met rust.

Grenzen, eerlijk

• Auto-update vertrouwt de server. Met de standaardinstelling vervangt de runner zichzelf door wat de server aanbiedt; wie de server beheerst heeft binnen een uur SYSTEM op elk apparaat met auto-update. Alternatieven: NOAUTOUPDATE of een ondertekende runner met UPDATETHUMBPRINT.
• De apparaatnaam is een claim. Elke tokenhouder van de tenant kan jobs van elk apparaat in die tenant ophalen; tokens per apparaat zijn een latere stap.
• De runner verifieert niet dat de PowerShell uit de catalogus komt. Dat is het werk van de server; de hash bewijst alleen dat wat de runner draait precies is wat de server uitdeelde en wat de technicus op de pagina zag.
• SYSTEM is nog niet op een productiemachine bewezen; zie Agent en runner.
• Geen verwerkersovereenkomst, geen EU-verwerking bij de modelleverancier, geen bewaartermijn: voor een echt product eerst regelen; zie Privacy.
• Niet ondertekend. MSI en scripts hebben nog geen Authenticode-handtekening; controleer de sha256.