De grootste beveiligingsvalkuilen als een AI-agent je code schrijft

Zolang je app op je eigen computer draait, kan alleen jij erbij. Zodra hij online staat, kan iedereen erbij. Dat vraagt niet om een cursus beveiliging, maar wel om te weten welke vragen je aan je agent stelt voordat je op "live zetten" klikt.

1. Rechten die niet kloppen

De fout die het vaakst gemaakt wordt, ook door agents: gebruiker A kan bij de gegevens van gebruiker B. Een klant die, door het adres in de browser aan te passen, toch de afspraak van een andere klant ziet. Vraag je agent expliciet om voor elk onderdeel vast te leggen wie wat mag zien en bewerken, en laat hem daarna een test schrijven die het bewijst: maak twee gebruikers aan, laat de één proberen bij de gegevens van de ander te komen, en controleer dat dat niet lukt.

2. Geheimen in de code

Wachtwoorden, API-sleutels en andere geheimen horen nooit in de broncode zelf, maar in een apart instellingenbestand dat niet mee naar GitHub gaat. Een gelekt wachtwoord op een openbare of per ongeluk gedeelde repository is de meest voorkomende manier waarop project van beginners gehackt worden. Vraag je agent om elk geheim in een .env-bestand te zetten en controleer zelf dat dat bestand niet wordt meegestuurd naar je versiebeheer.

3. Invoer die niet gecontroleerd wordt

Alles wat van buiten komt, een formulier, een adres in de browser, kan fout of kwaadwillend zijn. Een leeg verplicht veld, een telefoonnummer vol letters, een tekst van tienduizend tekens: je app moet daar een nette melding op geven, geen witte foutpagina die technische details prijsgeeft. Vraag je agent om elk formulier van validatieregels en duidelijke foutmeldingen te voorzien, en test dat zelf met rare invoer voordat je verdergaat.

4. Geen tests voor de belangrijkste dingen

Een test is een klein programma dat je app gebruikt zoals een mens dat zou doen en controleert of het resultaat klopt. Je hoeft ze niet zelf te schrijven of te lezen; je laat je agent ze maken en bij elke wijziging opnieuw draaien. Groen is goed; rood betekent dat iets kapot is dat eerder werkte. Minstens: een test voor inloggen, voor je belangrijkste formulier, en voor de regel dat gebruiker A gebruiker B niet ziet.

Een review door een tweede gesprek

Een trucje dat wij zelf gebruiken: begin een nieuw gesprek met je agent en vraag hem de code te beoordelen alsof hij hem niet zelf heeft geschreven, specifiek op de vier punten hierboven. Een verse blik vindt dingen die de bouwende agent over het hoofd zag. Doe dit voordat je live gaat, en herhaal het gerust na een grotere wijziging.

Loop je vast, of wil je een tweede paar ogen op je code? Plan een hulpsessie: een developer kijkt een half uur met je mee op scherm en code.