Hoe u beveiligingsproblemen in door AI gegenereerde applicaties kunt voorkomen

Iemand in je team typte een prompt in een AI-assistent, kreeg binnen twintig minuten een werkend loginscherm of een gegevensinvoerformulier terug, en zette het dezelfde middag live. Niemand in het team is een getrainde beveiligingsingenieur, en niemand vroeg de AI of de gegenereerde code correct machtigingen controleert, invoer schoonmaakt of een API-sleutel in platte tekst blootstelt. Dit is niet hypothetisch — het is momenteel de standaardwerkwijze in duizenden kleine en middelgrote bedrijven die AI-ondersteunde, low-code tools gebruiken om intern software snel te bouwen.

De snelheid is echt en waardevol. Het risico is ook echt, en het verschilt van de risico's die je hebt leren herkennen in traditionele ontwikkeling. Dit artikel beschrijft precies wat fout kan gaan in AI-gegenereerde applicaties, en de concrete controles die je kunt inbouwen voordat deze code klantengegevens of productiesystemen aanraakt.

Waarom vormt AI-gegenereerde code een ander soort beveiligingsrisico?

Traditionele code heeft een menselijke auteur die (hopelijk) de beveiligingsimplicaties van wat hij schreef begreep. AI-gegenereerde code heeft een patroonherkenner die iets produceerde dat statistisch waarschijnlijk werkt — niet iets dat bewezen veilig is.

Concreet toont dit zich op een paar terugkerende manieren:

• De AI optimaliseert voor "het werkt", niet "het is veilig". Vraag een AI-assistent om een opzoekscript voor klanten in FileMaker te bouwen, en het zal zeer waarschijnlijk iets produceren dat de juiste tabel bevraagt en de juiste velden retourneert. Het zal even waarschijnlijk machtigingscontroles overslaan, omdat je die niet hebt gevraagd, en de trainingsgegevens waaruit het heeft geleerd zijn vol met voorbeelden op tutorialniveau die ze overslaan.
• Het hergebruikt patronen uit openbare code, inclusief onveilige. Grote taalmodellen zijn getraind op enorme hoeveelheden openbare code — een aanzienlijk gedeelte hiervan bevat bekende beveiligingsproblemen (hardcoded inloggegevens, ontbrekende invoervalidatie, zwakke sessieafhandeling). Het model weet niet welke voorbeelden goede praktijk waren en welke de reden waren dat een tutorialopslagplaats werd gemarkeerd.
• Het is vol vertrouwen fout. Een AI-assistent zal stellen dat een script "invoer veilig verwerkt" of "de API-sleutel veilig opslaat" met dezelfde toon, ongeacht of dat waar is of niet. Er is geen voorbehoud, geen waarschuwingsvlag — wat betekent dat de mensen die het beoordelen hun eigen scepsis moeten meebrengen.
• Low-code tools vergroten de explosieradius. Platformen zoals FileMaker, en AI-lagen erop gebouwd zoals Klai of formulierbouwers zoals FmBetterforms, stellen één niet-ontwikkelaar in staat om een werkende module in een middag te genereren. Dat is precies het doel van low-code — maar het betekent ook dat beveiligingsbeoordeling nu nodig is op een moment waar, een paar jaar geleden, niemand buiten een ontwikkelingsteam code produceerde.

Wat gaat er in de praktijk werkelijk fout?

Dit zijn niet theoretische categorieën — het zijn de specifieke fouten die we het meest zien wanneer we AI-ondersteunde builds beoordelen.

1. Hardcoded inloggegevens en API-sleutels. Een AI-gegenereerd FileMaker-script roept een externe API aan en de assistent schrijft de API-sleutel rechtstreeks in de scriptstap, omdat dat de snelste manier is om de demo werkend te krijgen. Het zit daar in platte tekst, zichtbaar voor iedereen die het script in Manage Scripts kan openen — inclusief een voormalige werknemer wiens account nooit volledig werd ingetrokken.
2. Ontbrekende of onjuiste machtigingensets. Een gegenereerde layout laat elke ingelogde gebruiker een veld bewerken dat alleen voor managers zou moeten vergrendeld zijn, omdat de prompt "laat gebruikers de orderstatus bijwerken" was en de AI geen manier heeft om je organigram te kennen.
3. Geen invoervalidatie. Een webformulier dat met een AI-ondersteunde low-code tool is gebouwd, accepteert een naamveld dat eigenlijk willekeurige scriptinhoud accepteert, omdat niemand de generator opdroeg dit op te schonen — wat de deur opent voor injectieachtige aanvallen tegen wat voor backend het formulier ook communiceert.
4. Veel te breed API-bereik. Wanneer AI een verbinding tussen twee systemen ondersteunt — zeg, FileMaker naar een boekhoudpakket — is het gebruikelijk dat de gegenereerde integratie volledige lees-/schrijftoegang tot een volledige account aanvraagt, omdat dat het eenvoudigste bereik is om in te stellen, niet omdat de taak het nodig had.
5. Geen audittrail. De gegenereerde code voert de gevraagde actie uit (record verwijderen, prijs bijwerken, gegevens exporteren) maar registreert niet wie het deed of wanneer — prima voor een prototype, maar een aansprakelijkheidskwestie zodra die module echte klanten- of financiële gegevens verwerkt.
6. Gekopieerde logica met stille aannames. AI-tools genereren vaak code die een context met één gebruiker en één locatie aanneemt, omdat dat de eenvoudigste interpretatie van de prompt is — en die aanname faalt stilzwijgend zodra een tweede kantoor, magazijn of franchise hetzelfde systeem gaat gebruiken.

Hoe beoordeel je AI-gegenereerde code op veiligheid voordat het live gaat?

Behandel elke AI-gegenereerde module zoals je code zou behandelen van een junior contractant die je nooit hebt ontmoet — nuttig, vaak goed, altijd nodig voor een tweede oogpaar.

1. Deploy nooit rechtstreeks van de output van de AI. Bouw een regel in je werkwijze: AI-gegenereerde scripts, layouts of connectoren gaan eerst naar een staginggebied, niet rechtstreeks naar het live-bestand of de productieomgeving.
2. Vraag de AI om haar eigen beveiligingskeuzes uit te leggen — en verifieer ze zelf. De vraag "leg uit hoe dit script ongeautoriseerde toegang verwerkt" brengt gaten vaak onmiddellijk aan het licht, omdat de AI of toegeeft dat ze het niet heeft verwerkt of een controle beschrijft die eigenlijk niet in de code staat. Lees het daadwerkelijke script, vertrouw niet alleen op de uitleg.
3. Voer een scan uit op inloggegevens en geheimen. Doorzoek elk gegenereerd script, berekening en webhook op alles wat op een sleutel, wachtwoord of token lijkt. In FileMaker specifiek, controleer scriptstappen, aangepaste functies en de Data API-configuratie — dit zijn de plaatsen waar AI-assistenten doorgaans inloggegevens rechtstreeks loslaten.
4. Controleer machtigingensets tegen de daadwerkelijke organisatiestructuur, niet tegen wat de prompt impliceerde. Iemand die de zaak kent — niet de AI, niet eens de ontwikkelaar — moet bevestigen wie elk veld werkelijk mag zien en bewerken.
5. Test met een account met beperkte machtigingen, niet het beheersaccount. Een groot gedeelte van de toegangscontroleproblemen komt nooit aan het licht tijdens de ontwikkeling omdat de ontwikkelaar als beheerder test die alles toch kan zien.
6. Valideer elk extern invoerveld. Alles wat een klant, leverancier of openbaar formulier indient, moet als onvertrouwd worden behandeld totdat dit expliciet is gecontroleerd — ongeacht wie of wat de validatielogica schreef.
7. Beperk API- en connectorbereiken tot precies wat de taak nodig heeft. Als de integratie alleen de orderstatus hoeft te lezen, accepteer dan geen gegenereerde connector die volledige accounttoegang aanvraagt omdat dat gemakkelijker in te stellen was.
8. Voeg logging toe vóór go-live, niet na een incident. Elke module die financiële gegevens, klantgegevens of gebruikersmachtigingen aanraakt, moet vastleggen wie wat deed en wanneer — dit is vaak het eerste wat een AI-gegenereerde build overslaat.

Wie zou dit eigenlijk moeten beoordelen — de ontwikkelaar, IT, of de zakelijk eigenaar?

Allen drie, op verschillende momenten, omdat elk iets opvangt wat de anderen missen.

• De persoon die het heeft gebouwd (ontwikkelaar of ervaren gebruiker) moet de technische controles hierboven uitvoeren — geheimen, validatie, machtigingensets — voordat iemand anders ernaar kijkt.
• IT of een beveiligingsbewuste reviewer moet bevestigen dat de module in je bestaande toegangscontrolemodel past en geen nieuw aanvalsoppervlak introduceert (een onnodig open API-eindpunt, een te breed connectorbereik) dat IT niet volgde.
• De zakelijk eigenaar of manager die het hulpmiddel aanvroeg is de enige persoon die werkelijk weet wie toegang tot wat zou moeten hebben. "Moet magazijnpersoneel klantenprijzen zien?" is een zakelijke vraag, geen technische, en AI heeft geen manier om dit correct te beantwoorden.

Als je organisatie vandaag niemand heeft die formeel verantwoordelijk is voor deze beoordeling, is dat de eerste leemte om op te vullen — niet noodzakelijk met een nieuwe medewerker, maar met een geschreven checklist en een aangewezen eigenaar voor de goedkeuring, zelfs als dat een stap van 15 minuten is voordat iets live gaat.

Betekent dit dat AI-ondersteunde ontwikkeling te riskant is om te gebruiken?

Nee — maar het betekent wel dat de beoordelingsstap niet kan worden overgeslagen omdat de bouwstap sneller is geworden. De organisaties die echte waarde uit AI-ondersteunde low-code tools halen, zijn degenen die AI behandelen als een snelle eerste schets, niet als een afgewerkt product, voor alles wat echte gegevens of echte gebruikers aanraakt.

In de praktijk ziet dit er als volgt uit: AI genereert het script, de layout of connector in minuten; een mens voert het door een korte, herhaalbare beveiligingschecklist; alleen dan gaat het naar productie. Die checklist kost veel minder tijd dan de besparing die de originele build opleverde — daarom zijn snelheid en veiligheid eigenlijk niet in conflict, zolang iemand eigenaar is van de checkliststap.

Een beveiligingschecklist vóór implementatie voor AI-gegenereerde modules

• Geen hardcoded API-sleutels, wachtwoorden of tokens ergens in het script, de berekening of connector
• Machtigingensets gecontroleerd tegen daadwerkelijke baanrollen, niet afgeleid van de prompt
• Getest met een account met beperkte machtigingen, niet een beheersaccount
• Alle externe inputs gevalideerd en schoongemaakt
• API/connectorbereiken beperkt tot precies wat de taak nodig heeft
• Logging ingebouwd voor elke actie die financiële, persoonlijke of klantgegevens aanraakt
• Uitleg van de AI gecontroleerd tegen de daadwerkelijke gegenereerde code, niet zomaar aanvaard
• Een aangewezen persoon heeft goedkeuring gegeven vóór go-live

Veelgestelde vragen

Kan een AI-assistent de beveiligingsproblemen die zij heeft gemaakt oplossen als ik haar dat gewoon vraag? Soms, maar niet betrouwbaar. De vraag "maak dit veilig" levert vaak oppervlakkige fixes op — een variabele hernoemen, een opmerking toevoegen — zonder de daadwerkelijke leemte aan te pakken, vooral rond machtigingslogica die afhangt van zakelijke context die de AI niet heeft.

Is dit meer van een risico in FileMaker/low-code dan in traditionele codering? Het risico is anders, niet noodzakelijk groter. Traditionele ontwikkeling heeft zijn eigen AI-code-risico's (dezelfde modellen schrijven ook JavaScript en Python). Low-code platformen concentreren het risico omdat zij niet-ontwikkelaars in staat stellen werkende software rechtstreeks uit te zetten, wat betekent dat de beoordelingsstap opzettelijk moet worden toegevoegd in plaats van overgenomen van een bestaand ontwikkelingsproces.

Hoe vaak moeten bestaande AI-gegenereerde modules opnieuw worden beoordeeld? Elke keer dat de gegevensentoegangsmogelijkheden van de module veranderen — een nieuwe gebruikersrol wordt toegevoegd, het begint een nieuwe tabel aan te raken, of het wordt met een nieuw extern systeem verbonden — behandel dat als een nieuwe build en voer de checklist opnieuw uit.

Moeten we AI-gegenereerde code gewoon verbieden totdat we een formeel beoordelingsproces hebben? Dat is zelden praktisch of nodig. Een lichte, geschreven checklist en een aangewezen eigenaar voor goedkeuring geven je het meeste bescherming zonder het team tot stilstand te brengen.

Als je team al AI gebruikt om FileMaker-ontwikkeling sneller te maken, of AI-ondersteunde tools zoals Klai of formulierbouwers zoals FmBetterforms bekijkt, is het de moeite waard om die snelheid met een passende beoordelingsstap te combineren in plaats van deze in te voegen nadat iets kapot gaat. We gaan dieper in op hoe AI de vorm van custom softwareontwikkeling verandert in ons gerelateerde artikel over hoe low-code en AI-ondersteunde ontwikkeling zakelijke software veranderen. Loggix helpt teams die beoordelingsstap in een aangepaste FileMaker-oplossing, een verbonden webapplicatie of een API-integratie inbouwen van het begin af — en gaat, waar nuttig, een praktische consultatiesessie aan zitten om precies in kaart te brengen waar AI veilig je ontwikkeling kan versnellen zonder nieuw risico te introduceren.