Veilig vibecoden tips voor als je zelf apps en agents bouwt met AI

Deel 2 van 2. In deel 1 staat wat vibecoden betekent voor je organisatie en welke afspraken je als directie maakt. Dit deel is voor de collega die daadwerkelijk bouwt.

Je hebt het inmiddels een paar keer gedaan. Je beschrijft wat je wil, de AI-assistent bouwt het, je stuurt bij, en na een middag staat er iets dat werkt. Waarschijnlijk werkt het beter dan je had verwacht. Precies daar zit het risico. Een applicatie die functioneel klopt kan technisch volledig lek zijn, en je merkt daar tijdens het bouwen niets van. De AI zegt niet uit zichzelf dat de autorisatie ontbreekt. Hij zet de wachtwoorden gewoon in de code als je niets anders vraagt.

Dit is de werkwijze die dat voorkomt. Niet alles is voor elk project nodig: een intern lijstje zonder persoonsgegevens is iets anders dan iets waar klantgegevens in staan. Bepaal vooraf in welke categorie je zit, dan weet je hoe zwaar je het moet aanzetten.

Wil je meer weten over wat vibecoden precies is en hoe het werkt? Lees dan onze FAQ: Wat is vibecoden?.

Voordat je begint

Kijk eerst of het al bestaat

De verleiding om alles te bouwen omdat het nu kan is groot. Maar bouwen is goedkoop geworden, beheren niet. Alles wat je maakt, moet je jarenlang onderhouden.

Check dus eerst of het al in licentie zit. Veel organisaties hebben Power Apps, Lists, Forms en Power Automate al binnen hun Microsoft 365-omgeving, met inloggen, backups en rechtenbeheer al geregeld. Dat scheelt je niet alleen bouwwerk maar ook alle stappen hieronder.

Bouw als het je organisatie onderscheidt. Koop als het je alleen ondersteunt.

Spar eerst, bouw daarna

Begin niet met “bouw een app die X doet”. Begin met een gesprek: wat is het probleem, wie gebruikt het, welke gegevens komen erin, welke systemen moeten eraan gekoppeld. Laat daar vervolgens een plan van aanpak uit komen.

Zorg dat er drie dingen in staan die vaak vergeten worden:

• Wat de app expliciet niet gaat doen. Zonder die grens heb je later geen enkel argument tegen scope creep.
• Acceptatiecriteria. Wanneer is het af? “Het werkt” is geen criterium.
• Wie de eigenaar is. Ook als dat jij bent.

Laat iemand anders het plan lezen

Vier ogen op het plan van aanpak, niet pas op het eindresultaat. Op dat moment kost een correctie vijf minuten. Laat de lezer letten op drie dingen: klopt de scope, klopt het welke gegevens erin komen, en bestaat het echt nog niet.

Bepaal vooraf waar het draait en wat het mag kosten

Vraag je een AI-assistent waar de app moet draaien, dan komt er standaard een gratis hostingpartij uit. Dat is een keuze die jij maakt en niet je AI, want zodra er persoonsgegevens in de app komen heb je een verwerkersovereenkomst nodig en moet je weten in welk land de data staat. Dat ook een bekend platform geen garantie is, bleek in april 2026 bij vibecodeplatform Lovable via het platform zelf was broncode van gebruikers op te halen, inclusief de databasewachtwoorden die erin stonden. Lovable wees de verantwoordelijkheid in eerste instantie af.

Kies dus vooraf één platform voor alles wat je bouwt, en zet daar een maandbudget op met een waarschuwing bij overschrijding. Cloudkosten lopen per gebruik door, en één verkeerd ingerichte lus is genoeg voor een onaangename verrassing. Welk platform dat wordt, hangt af van wat je bouwt. Belangrijk daarbij: het hosten van de applicatie en het draaien van een AI-model zijn twee losse vragen.

Bouw je een portaal of applicatie zonder AI erin? Dan heb je meerdere mogelijkheden. Voor de meeste organisaties die al Microsoft 365 gebruiken is Azure daarbij de meest logische keuze, omdat applicaties direct kunnen aansluiten op bestaande identiteiten, beveiligingsmaatregelen en beheerprocessen. Een private cloud of eigen server kan ook, maar realiseer je dat zaken zoals patchbeheer, beschikbaarheid, monitoring en backups dan volledig je eigen verantwoordelijkheid worden. Ook de centrale voordeur verderop in dit artikel moet je dan zelf inrichten, bijvoorbeeld met een reverse proxy en firewall.

Bouw je een agent die zelf een taalmodel aanroept? Dan kom je al snel uit bij Azure of AWS. De zware frontier-modellen draai je niet op eigen hardware, en je wil dat verbruik in een omgeving hebben waar je zelf de regio, de logging, het sleutelbeheer en de kostentoerekening regelt.

Vermijd in een zakelijke omgeving zoveel mogelijk afhankelijkheid van het hostingplatform van je AI-tool. Deze platformen zijn uitstekend voor experimenten, prototypes en testomgevingen, maar bieden vaak minder controle over zaken als identiteitsbeheer, logging, netwerktoegang, back-ups en compliance. Voor applicaties die door meerdere gebruikers worden gebruikt of bedrijfskritisch worden, is een eigen Azure-, AWS- of private cloudomgeving meestal een betere keuze.

Tijdens het bouwen

Houd de scope vast, ook al kriebelt het

Dit is in de praktijk het grootste probleem, en iedereen die ooit heeft gevibecode herkent het. Terwijl je bouwt, bedenk je continu nieuwe functionaliteit. En de AI bouwt alles wat je vraagt, zonder ooit tegen te sputteren. Twee uur later heb je zes half afgemaakte functies en werkt er niets meer helemaal.

De regel: tijdens een bouwronde ligt de scope vast. Elk nieuw idee gaat naar een backlog, zonder uitzondering. Als de ronde af is, beoordeel je die backlog en start je eventueel een nieuwe ronde met een aangepast plan. Zo staat er altijd een werkende versie, en weet je bij elk probleem welke wijziging het veroorzaakte.

Loop je tegen iets aan dat echt niet in het plan staat maar wel nodig is? Dan pas je het plan aan. Dat mag. Wat niet mag, is dat de AI het stilzwijgend zelf invult.

Zet het vanaf commit één in versiebeheer

De chatgeschiedenis van je AI-assistent is geen versiebeheer. Zonder repository heb je geen manier om terug te draaien, geen manier om te laten meekijken en geen manier om het over te dragen. Gebruik Git, en commit per afgeronde functie in plaats van één keer aan het eind.

Laat wachtwoorden en sleutels nooit in de code staan

Dit doet een AI standaard fout. Vraag je om een koppeling met een systeem, dan komt de sleutel gewoon in het codebestand terecht. Staat die code vervolgens in een repository, dan staat je sleutel daar ook, en in de geschiedenis blijft hij staan ook nadat je hem hebt weggehaald.

Gebruik een kluis zoals Azure Key Vault, of nog beter een managed identity waarbij er helemaal geen sleutel is die je kunt lekken. En zet secret scanning aan op je repository.

Let op welke pakketten binnenkomen

AI-assistenten halen softwarebibliotheken van derden binnen. Meestal prima, maar twee dingen gaan mis. Ze gebruiken soms verouderde of verlaten pakketten, en ze verzinnen af en toe pakketnamen die niet bestaan. Dat laatste is inmiddels een bekend aanvalspad: aanvallers registreren die verzonnen namen en zetten er kwaadaardige code onder.

Loop de lijst met afhankelijkheden dus door, leg versies vast en laat er een scan overheen lopen.

Koppel de AI niet rechtstreeks aan je systemen

Zodra je app moet praten met je CRM, je boekhouding of je ticketsysteem, wil je daar geen directe koppeling. Zet er een middlewarelaag tussen, bijvoorbeeld Power Automate, n8n of Zapier, met vooraf ingestelde rechten en standaard alleen leesrechten. Zo heb je één plek waar je kunt zien wat er gebeurt en één plek waar je het kunt afknijpen.

Eén detail dat vaak misgaat: laat die koppeling niet draaien onder een persoonlijk account. Gebruik een service principal of managed identity. Anders valt de hele integratie om zodra die medewerker uit dienst gaat, en kun je achteraf niet herleiden wie wat heeft gedaan.

Gebruik een eigen AI-omgeving, niet de tokens van je chatbot

Zit er AI in de app zelf, laat die dan draaien op een instance in je eigen Azure- of AWS-omgeving. Dat geeft je vier dingen die je met een consumentenabonnement niet hebt: weet in welke regio de data verwerkt wordt, je hebt logging, je kunt kosten toerekenen per applicatie, en je beheert je eigen sleutels.

Monitor het verbruik en zet harde limieten, ook per gebruiker.

Bepaal welke beslissingen langs een mens moeten

“Bij elke stap goedkeuren” klinkt veilig maar werkt averechts. Na dertig keer klikt iedereen door zonder te lezen. Bepaal in plaats daarvan vooraf welke beslissingen echt een mens nodig hebben, en laat de rest lopen.

De categorieën die er altijd bij horen: wijzigingen aan het datamodel, alles rond inloggen en rechten, nieuwe koppelingen naar buiten, publicatie naar productie, en alles wat gegevens verwijdert.

Voordat het live gaat

Laat er een securityreview overheen gaan

Dit is de belangrijkste stap in het hele verhaal. Vibecoded applicaties zien er werkend uit en zijn dat functioneel ook. Wat er structureel misgaat zit onder de motorkap.

De meest voorkomende fout is autorisatie. De app controleert wél of je bent ingelogd, maar niet of jíj bij dít record mag. Pas het volgnummer in de URL aan en je zit in het dossier van iemand anders. Test dit zelf: log in als een gebruiker met weinig rechten en probeer bij gegevens te komen die niet van jou zijn.

Daarnaast: is er een limiet op hoe vaak iemand een verzoek mag doen, wordt invoer van gebruikers gecontroleerd voordat hij in de database belandt, en staan er foutmeldingen aan die te veel prijsgeven.

Laat AI en vulnerability scanners meekijken, maar vertrouw er niet blind op

Een groot voordeel van moderne AI-tools is dat ze verrassend goed zijn in het vinden van technische kwetsbaarheden in code. Laat daarom niet alleen de AI bouwen, maar ook actief controleren. Tools zoals GitHub CodeQL, Semgrep en andere SAST-oplossingen (Static Application Security Testing) kunnen automatisch zoeken naar bekende kwetsbaarheden zoals SQL-injecties, XSS, hardcoded wachtwoorden, onveilige afhankelijkheden en onjuiste invoervalidatie. GitHub ondersteunt bijvoorbeeld geautomatiseerde code scanning met CodeQL.

Voor vibecode-projecten zijn er daarnaast nieuwe AI-gedreven initiatieven ontstaan, zoals Shannon. Shannon analyseert broncode, zoekt naar aanvalspaden en probeert kwetsbaarheden daadwerkelijk te misbruiken voordat een applicatie live gaat. Het project kan als container binnen je eigen omgeving draaien en is daardoor interessant voor organisaties die controle over hun broncode willen houden.

Dat klinkt indrukwekkend, maar er zit een belangrijke beperking aan, deze tools controleren vooral wat er in de code staat. Bij het AI-platform Moltbook werkte de code begin 2026 prima, maar door één ontbrekende database-instelling lagen 1,5 miljoen toegangssleutels en 35.000 e-mailadressen voor iedereen open. Onderzoekers van Wiz vonden het lek binnen enkele minuten, gewoon door de site als normale gebruiker te bekijken. De grootste risico’s bij vibecoden ontstaan vaak juist door zaken die buiten de code liggen:

• Staat de data in Nederland, Europa of ergens anders?
• Is de applicatie gekoppeld aan een single-tenant of multi-tenant Entra ID configuratie?
• Mag iedereen met een Microsoft-account inloggen of alleen medewerkers van je eigen organisatie?
• Zijn Conditional Access en MFA afgedwongen?
• Staat de database publiek bereikbaar?
• Is er een back-upstrategie?
• Is logging ingeschakeld?
• Worden persoonsgegevens langer bewaard dan nodig?

Microsoft beschrijft dat een multitenant-app gebruikers uit andere Entra-tenants kan toelaten, terwijl een single-tenant-app alleen gebruikers uit de eigen tenant accepteert. Voor interne bedrijfsapplicaties is dat een belangrijk ontwerpbesluit dat geen enkele vulnerability scanner voor je neemt.Nog belangrijker: scanners zijn goed in het vinden van fouten in code, maar veel minder goed in het herkennen van fouten in bedrijfslogica, een voorbeeld:

• De applicatie werkt technisch perfect.
• Iedereen logt correct in via Entra ID.
• Alle security scans zijn groen.

Maar een medewerker van afdeling A kan door een fout in de autorisatielogica dossiers van afdeling B bekijken. Technisch gezien draait alles zoals ontworpen. Vanuit security-oogpunt heb je alsnog een datalek. Juist dit soort autorisatie- en procesfouten worden bij vibecoded applicaties regelmatig gemist en vereisen een menselijke review.

Een vulnerability scan is daarom een uitstekend hulpmiddel, maar nooit een vervanging voor een securityreview. Zie het als een extra paar ogen op de code, niet als een eindcontrole van de volledige applicatie.

Bouw nooit zelf een inlogscherm

Hoe overtuigend de AI er ook een neerzet. Gebruik Entra ID single sign-on, of wat je organisatie standaard gebruikt. Dan heb je meteen multifactor, centrale uitschakeling bij uitdiensttreding en logging, en hoef je nooit zelf wachtwoorden op te slaan.

Zet alles achter één centrale voordeur

Alle applicaties achter één ingang, bijvoorbeeld Azure Front Door met een web application firewall ervoor. Host je zelf, dan is het equivalent een reverse proxy met een firewall, maar het principe blijft hetzelfde: één plek waar al het verkeer langskomt. Belangrijk daarbij: sluit de achterdeur ook af. Als je applicatie daarnaast nog gewoon rechtstreeks bereikbaar is op zijn eigen adres, dan is die centrale voordeur decoratie. Regel dat via Private Link of via toegangsbeperkingen op je app service.

Publiceer niet vanuit je AI-assistent naar productie

Werk lokaal, dan naar een testomgeving, dan pas naar productie via een pipeline met een goedkeuringsstap. Gebruik bijvoorbeeld Azure DevOps Pipelines of GitHub Actions waarbij elke wijziging automatisch wordt uitgerold naar een ontwikkel- of testomgeving, maar een publicatie naar productie altijd een handmatige goedkeuring vereist. Zo voorkom je dat een foutieve prompt, een onbedoelde wijziging of een defecte release direct impact heeft op gebruikers of bedrijfsgegevens.

Regel backup en herstel

Ook voor een intern hulpmiddel. Bepaal hoe lang het eruit mag liggen en hoeveel gegevens je maximaal mag verliezen, en richt het daarnaar in. Vibecoded applicaties bevatten vaker echte data dan mensen vooraf denken.

Leg vast wat er staat

Vijf dingen zijn genoeg: wat doet het, welke gegevens zitten erin, welke koppelingen heeft het, wie is de eigenaar, en hoe zet je het terug als het stukgaat. Eén pagina. Maar wel geschreven, want over een jaar weet jij het ook niet meer.

Daarna

Maak de wijzigingsprocedure proportioneel. Een tekstwijziging of een andere kleur doe je gewoon. Een wijziging aan het datamodel, aan rechten of aan koppelingen gaat door de volledige procedure met vier ogen. Eén zwaar proces voor alles zorgt er alleen voor dat mensen het omzeilen.

Zet een reviewdatum in de agenda. Eén keer per jaar: wordt dit nog gebruikt, klopt de documentatie nog, zijn de afhankelijkheden nog actueel, en is de eigenaar nog in dienst.

Weet wanneer je moet stoppen met vibecoden. Zodra een applicatie bedrijfskritisch wordt, gelden er andere eisen. Dat is geen falen van de aanpak. Het prototype heeft dan bewezen dat het probleem echt bestaat en dat de oplossing werkt, en dat is precies waar het voor bedoeld was.

Klaar om live te gaan?

Wat je bouwt en hoe het werkt, blijft van jou. Maar waar het draait en hoe dat is ingericht, bepaalt voor een groot deel hoe veilig het is. Wij denken graag met je mee over een goede plek in Microsoft Azure: met inloggen via Entra ID, één centrale voordeur, backups en kostenbewaking vanaf dag één. Zo staat je applicatie op een fundament dat je niet zelf hoeft uit te vinden.

Samengevat

Dit wil je wel: eerst sparren, dan een plan met een harde scope en met wat er expliciet niet in zit. Vier ogen op dat plan. Één vast platform met een maandbudget. Versiebeheer vanaf het begin. Sleutels in een kluis. Nieuwe ideeën naar de backlog in plaats van er direct in. Een securityreview en een menselijke goedkeuring voordat het live gaat. Alles achter één centrale voordeur en één manier van inloggen. Een eigenaar, documentatie en een reviewdatum.

Dit wil je niet: je AI het hostingplatform laten kiezen. Rechtstreekse koppelingen naar je systemen zonder tussenlaag en zonder beperkte rechten. Applicaties die verspreid staan over verschillende portalen en hostingpartijen zonder dat iemand het overzicht heeft. AI die zelfstandig onomkeerbare beslissingen neemt. En bouwen zonder plan, want dan ga je van hot naar her en is er na een dag niets af.