Loop mijn website na op de voor de hand liggende veiligheidsfouten: wie kan
erbij, staan de rechten goed, en welke pakketten zijn verouderd?
Een platform dat met AI-agents is gebouwd, ziet er vaak beter uit dan een platform dat met de hand is gebouwd. Nette code, consistente namen, overal commentaar. En dan licht je het door en vind je acht dingen die niets met code te maken hebben.
Dat is precies wat ons opviel bij een audit van zo'n platform deze maand. We noemen geen namen en geen domeinen, maar de lijst zelf is het waard om langs je eigen project te leggen. Geen van de acht punten is iets wat een model verkeerd heeft gedaan. Alle acht gaan over de omgeving waarin de agents werkten.
1. Tweestapsverificatie op de eigenaar-accounts
Het eerste account van een project is bijna altijd het account met de meeste rechten, en bijna altijd het account waar niemand later nog naar kijkt. Bij een project dat snel is gebouwd, zit daar vaak ook de hostinglogin, het mailadres voor wachtwoordherstel en de koppeling met de repository aan vast.
Zet tweestapsverificatie aan op elk account dat eigenaar is, niet alleen op de accounts waarmee je dagelijks werkt. Dat is tien minuten werk en het is het enige punt op deze lijst dat geen enkele afweging kent.
2. Verouderde pakketten waar niemand naar kijkt
Een agent kiest een pakket, installeert het, en dat pakket blijft staan op de versie van die dag. Wordt er een half jaar aan het project gewerkt, dan sta je met een lijst afhankelijkheden waar al bekende problemen in zitten.
Dit is een controle die je in één opdracht kunt laten draaien en daarna maandelijks herhaalt. Belangrijk is niet de lijst maar de gewoonte: zonder een vast moment kijkt niemand ernaar, want het is nooit urgent.
3. De rechten op je instellingenbestand
Het bestand met je wachtwoorden en API-sleutels hoort door precies één gebruiker leesbaar te zijn. In de praktijk staat het regelmatig op rechten waarmee elke gebruiker op de server het kan openen. Op een eigen server valt dat mee. Op gedeelde hosting is het het verschil tussen "mijn gegevens" en "iedereens gegevens".
Een agent let hier niet op, want het bestand werkt prima met ruimere rechten. Het is iets dat je één keer goed zet en daarna controleert.
4. Mockups die openbaar staan
Bij snel bouwen ontstaan ontwerpvoorbeelden, testpagina's en schermen met voorbeeldgegevens. Die worden gemaakt om te laten zien en daarna vergeten. Ze staan dan nog steeds online, zonder login, vindbaar voor wie de map weet of voor een zoekmachine die ze oppikt.
Loop je eigen project na op mappen met namen als demo, test, mockup en oud. Alles wat niet bij de site hoort, hoort niet in de webroot.
5. De repository op dezelfde server als de site
Dit is de meest voorkomende, en de minst zichtbare. De agents werken op een server, de versiebeheer-repository staat op diezelfde server, en die repository is het enige waar de geschiedenis van het project in zit. Gaat de server stuk, dan ben je niet alleen de site kwijt maar ook de weg terug.
Zet je repository ergens anders. Dat hoeft geen dienst van buiten te zijn als je dat niet wilt; een tweede plek is al genoeg.
6. Geen controle die vanzelf draait
Geen test die bij elke wijziging loopt, geen melding als de site eruit ligt. Bij een project waar mensen aan werken, merkt iemand het binnen een dag. Bij een project waar agents aan werken, is er geen iemand.
Begin klein. Een monitor die je een bericht stuurt als de site niet reageert, en één controle die loopt voordat iets live gaat. Dat is al het verschil tussen "dat wist ik niet" en "ik wist het binnen twee minuten".
7. Twee agents in dezelfde werkmap
Twee opdrachten tegelijk in dezelfde map is vragen om problemen. Agent A leest een bestand, agent B schrijft het, agent A schrijft zijn eigen versie terug. Het resultaat is geen foutmelding maar werk dat stil verdwijnt, en dat ontdek je pas dagen later.
Laat één opdracht af voordat je de volgende start, of geef elke opdracht zijn eigen kopie om in te werken.
8. Agents met volledige toegang tot persoonsgegevens
De zwaarste van de acht. Een agent die een functie moet bouwen rond gebruikersgegevens, heeft meestal geen productiedata nodig. Toch werkt hij er vaak in, omdat dat de omgeving is die klaarstond.
Scheid dat. Bouwen gebeurt op gegevens die niet van echte mensen zijn. Gaat het om gezondheid, financiën of kinderen, dan is dit geen nette-werkwijze-punt meer maar een verplichting.
Veelgemaakte fouten
Denken dat dit over het model gaat. Geen van de acht punten verandert als je een ander model kiest. Ze gaan over rechten, scheiding en controle. Dat zijn keuzes van degene die het project opzet.
De lijst eenmalig afvinken. Punten 2, 4 en 6 lopen weg zodra je weer begint te bouwen. Zet ze in een vast moment, bijvoorbeeld de eerste maandag van de maand.
Alles op de agent willen vastleggen. Een regel in je instructies dat hij voorzichtig moet zijn, is geen bescherming. Rechten, afgescheiden omgevingen en een plek voor je geschiedenis zijn dat wel.
Wachten tot het project af is. De acht punten kosten samen minder dan een dag aan het begin. Achteraf kost punt 8 alleen al een verbouwing.
Wil je dit op je eigen hosting nalopen, dan kun je de eerste vier punten letterlijk aan de assistent vragen; de opdracht boven dit artikel is een goed begin. Wat hij daarbij zelf kan nakijken, staat in Welke controles de assistent zelf kan doen.