Vibe Coding: de verborgen beveiligingsrisico's van AI-gegenereerde code

Je developer heeft in twee uur een werkende feature gebouwd met AI. Nu wat?

Een developer typt een paar zinnen in Copilot, Cursor of Claude. Twintig minuten later staat er een werkend endpoint. De feature doet wat hij moet doen, de tests slagen, en niemand heeft er handmatig een regel code voor geschreven.

Dit heet vibe coding: je beschrijft in gewone taal wat je wilt, en een AI-model genereert de code eromheen. Het gaat snel, het werkt, en precies dat is het probleem voor een Head of Development. Want 'het werkt' zegt niets over of het veilig is, of het meeschaalt, of iemand anders het over een half jaar kan overnemen.

De AI maakt onderweg keuzes die je niet ziet — over architectuur, over wie waar toegang toe krijgt, over hoe data van het ene systeem naar het andere stroomt. Die keuzes zijn niet zichtbaar in een demo. Ze worden pas zichtbaar als iemand ze misbruikt, of als je probeert te schalen en alles vastloopt.

Wat is vibe coding, en waarom is het risicovoller dan het lijkt?

Vibe coding is geen synoniem voor 'AI helpt bij programmeren'. Het is een specifieke werkwijze: je beschrijft een probleem in natuurlijke taal, het model genereert de volledige implementatie, en je itereert verder op basis van of het resultaat 'goed voelt'. Er wordt daarbij vaak geen traditionele code review, statische analyse of architectuurcheck uitgevoerd — precies de stappen die dit soort fouten normaal afvangen.

Dat is ook waarom onderzoekers dit als een apart risicogebied behandelen. Wiz beschrijft het als een categorie met eigen kwetsbaarheden: bugs in AI-gegenereerde code, supply chain-risico's, IAM-issues en dataverkeer dat je niet had voorzien ( Wiz Academy ). Checkmarx wijst op hetzelfde patroon: AI reproduceert onveilige patronen uit trainingsdata onder tijdsdruk om snel een werkend resultaat te leveren, wat kan leiden tot zwakke authenticatie, gebroken autorisatie en onveilige omgang met gevoelige data ( Checkmarx ).

De snelheid is het lokkertje én het probleem. Hoe sneller je software bouwt, hoe sneller de risico's zich opstapelen zonder dat iemand ze ziet.

De vier risico's die we in de praktijk het vaakst tegenkomen

Generieke waarschuwingen over 'AI-code is onveilig' helpen een Head of Development weinig. Concreet gezien de reviews die wij uitvoeren, komen vier categorieën steeds terug.

1. Te brede permissies

AI-modellen kiezen vaak de makkelijkste weg naar 'het werkt': een service-account met volledige toegang in plaats van precies de rechten die nodig zijn. Dat is geen bug die een test opvangt — de feature functioneert perfect. Het probleem wordt pas zichtbaar als iemand toegang krijgt tot meer dan bedoeld.

2. Secrets in de verkeerde laag

API-sleutels, tokens en wachtwoorden die in code, configuratiebestanden of zelfs frontend-bundels terechtkomen in plaats van in een secrets-manager. OX Security noemt dit expliciet als terugkerend patroon: modellen zetten hardcoded secrets uit hun trainingsdata direct in de applicatiekern ( OX Security ).

3. Ontbrekende inputvalidatie

Een formulier of endpoint dat aanneemt dat binnenkomende data er altijd netjes uitziet. Dit is precies het soort 'non-functional requirement' dat een AI-model overslaat, omdat het niet nodig is om de demo te laten werken — pas bij een onverwachte of kwaadaardige input breekt het.

4. Integraties die te veel data ophalen

Een koppeling met een CRM of ERP-systeem die, om het simpel te houden, in één keer een volledige dataset opvraagt in plaats van precies het benodigde veld. Dat werkt in een test met tien records. Bij duizenden klantrecords wordt het een prestatie- én een privacyprobleem.

Deze vier categorieën zijn precies waarom een generieke checklist vaak niet genoeg is — je hebt iemand nodig die naar de architectuur kijkt, niet alleen naar losse regels code.

Waarom dit niet in een normale demo naar boven komt

Een demo test of de feature doet wat hij moet doen. Een security- en architectuurreview test iets anders: wat gebeurt er als iemand het systeem gebruikt op een manier die niemand had voorzien?

De Moltbook-databreuk is een aansprekend voorbeeld van hoe dit misgaat: een volledig met AI-tools gebouwde applicatie lekte binnen 72 uur na lancering 1,5 miljoen API-tokens en 35.000 e-mailadressen. De kwetsbaarheid zelf was niet ingewikkeld — een ontbrekende toegangscontrole die een ervaren engineer bij een standaard code review had opgemerkt. Maar die review vond niet plaats, omdat de hele applicatie uit conversationele prompts kwam ( OX Security ).

Dat is de kern van het probleem voor een Head of Development: niet dat AI-code per definitie slecht is, maar dat het proces eromheen — de review, de architectuurcheck, de vraag 'wie mag hier straks bij' — vaak wordt overgeslagen omdat de code al 'werkt'.

Hoe je dit vangt vóórdat het productie haalt

De oplossing is niet 'stop met AI-gegenereerde code gebruiken'. De oplossing is een vast controlemoment inbouwen vóórdat code naar productie gaat, gericht op precies de vier categorieën hierboven: permissies, secrets, inputvalidatie en over-fetching integraties.

Bij 48-7 doen we dat via een concrete code- en architectuurreview. Geen dik rapport vol jargon, maar een praktische doorlichting van wat de AI heeft gebouwd: wie heeft waar toegang toe, waar staan de secrets, wat gebeurt er met onverwachte input, en welke data haalt een integratie eigenlijk op. Een eerste review plannen we doorgaans binnen een week in.

Dat sluit aan bij een breder patroon dat we zien: veel AI-projecten stranden niet omdat de proof-of-concept niet werkt, maar omdat niemand het overneemt zodra het richting productie moet — met technische schuld en verloren momentum als gevolg. We werken daarom als één team van discovery tot productie, zonder overdracht naar een ander team halverwege. Hoe dat traject eruitziet, lees je in ons AI implementatie stappenplan .

Je hoeft niets te vervangen om dit te doen. AI-gegenereerde code blijft werken op je bestaande systemen — ERP, CRM, Gmail, Slack — de review komt er alleen bovenop als extra controlelaag, en jij beslist uiteindelijk wat er live gaat.

Vibe coding en de EU AI Act: geen vrijbrief

Beveiligingsrisico's staan los van, maar raken wel aan, de vraag of een AI-toepassing binnen de EU AI Act (2024/1689) in een bepaalde risicocategorie valt. Een tool die zonder review is gebouwd en breed toegang heeft tot klantdata, verdient extra aandacht bij die classificatie. Dit is algemene informatie, geen juridisch advies — raadpleeg bij twijfel een specialist of neem contact op. Meer achtergrond staat in EU AI Act voor bedrijven: wat MKB+ nu moet weten .

Begin met een vrijblijvend gesprek

Twijfel je of een AI-gegenereerde feature, workflow of integratie in je bedrijf klaar is voor productie? Plan een gratis gesprek van 30 minuten of vraag de AI Impact Scan aan. We kijken concreet mee naar wat er is gebouwd — zonder verkooppraat, zonder verplichtingen.

FAQ

Wat is vibe coding en waarom is het riskant?

Vibe coding is het genereren van complete code door AI-modellen aan te sturen met natuurlijke taal in plaats van zelf te programmeren. Het is riskant omdat traditionele controles — code review, statische analyse, architectuurcheck — vaak worden overgeslagen zodra de code 'werkt', waardoor problemen met permissies, secrets, inputvalidatie en dataverkeer onopgemerkt blijven tot ze worden misbruikt.

Werkt vibe coding daadwerkelijk voor productiecode?

Het kan een werkende eerste versie opleveren, en snel ook. Maar 'werkend' en 'productieklaar' zijn niet hetzelfde: zonder een controlemoment gericht op beveiliging en architectuur blijven risico's als te brede permissies of ontbrekende validatie onzichtbaar tot ze in productie problemen veroorzaken.

Is het gênant als mijn team vibe coding gebruikt?

Nee — het is een normale, snelle manier om te bouwen en te itereren, mits er een controlemoment volgt vóór productie. Het wordt pas een probleem als er geen review plaatsvindt en niemand checkt wie waar toegang toe heeft.

Is vibe coding echt zo makkelijk als het lijkt?

Het genereren van werkende code is inderdaad snel en laagdrempelig geworden. Wat niet makkelijker is geworden: weten of die code veilig is, meeschaalt, en overdraagbaar is aan een ander team — dat vraagt nog altijd een gerichte review.

Welke beveiligingsrisico's komen het vaakst voor in AI-gegenereerde code?

In de reviews die wij uitvoeren komen vier categorieën het meest terug: te brede permissies, secrets die in de verkeerde laag staan opgeslagen, ontbrekende inputvalidatie, en integraties die meer data ophalen dan nodig.

Vervangt een code review het gebruik van AI-tools voor development?

Nee. Je hoeft niets te vervangen — AI-gegenereerde code blijft gewoon werken op je bestaande systemen. Een pre-productie review komt er als extra controlelaag bovenop, en jij beslist uiteindelijk wat live gaat.