AI-tools zoals GitHub Copilot veranderen de manier waarop we software ontwikkelen. Ze schrijven steeds vaker mee aan de code: zo is heel het team een stuk minder tijd kwijt. Software developers krijgen er als het ware een digitale collega bij. Maar wel een collega zonder gezicht. Zonder contract. En vaak ook zonder toezicht.
Want wie AI inzet om sneller te bouwen, krijgt er ongemerkt ook iets anders bij: meer risico op gevoelige informatie in de code. Meer digitale toegangen. Minder zicht op wie precies toegang heeft tot wat.
En: met die collega krijgt u ook te maken. Misschien via een leverancier, of een extern developmentteam. Of misschien gewoon via uw eigen IT-afdeling.
Minder tijd kwijt, maar wel meer lekken van gevoelige informatie
Het gebruik van Copilot groeide in één jaar met 27%. Sinds 2025 is het gratis voor miljoenen gebruikers. U kunt zich voorstellen: steeds meer bedrijven gaan ermee aan de slag.
Tegelijk zien we een zorgwekkend patroon. In een analyse van 20.000 projecten met Copilot bleek dat 6,4% minstens één vorm van gevoelige informatie bevatte. Dat is 40% vaker dan in andere projecten. Het gaat om API-sleutels. Toegangstokens. Wachtwoorden. In de code: volledig zichtbaar voor wie ernaar zoekt.
Wilt u de technische kant van dit onderwerp verder verkennen? The Hacker News – waar we bovenstaande statistieken vandaan hebben – publiceerde een uitgebreide analyse over hoe AI-tools leiden tot een explosie van machine-identiteiten. En: hoe CISOs daarmee om kunnen gaan.
Hoe gevoelige data in de code belandt
Een developer werkt aan een intern project en gebruikt Copilot om een functie te schrijven. Copilot suggereert alvast een stukje code, inclusief een test-API-sleutel. Om snel te testen, wordt die vervangen door een echte sleutel of wachtwoord. Het werkt, en de developer gaat door. De code wordt opgeslagen in Git.
Later wordt het project gedeeld met een derde partij. Of gekopieerd naar een andere omgeving. Wat niemand doorheeft: die oude sleutel staat nog in de commitgeschiedenis. Of in een vergeten script. Zo belandt gevoelige toegang van uw eigen systemen in broncode waar die nooit had mogen staan.
Waarom dit u ook raakt: ook als u denkt van niet
Misschien denkt u: “Maar dat zijn toch niet míjn sleutels?” In veel gevallen wel. Want zodra uw eigen developers AI gebruiken, kunnen uw API-sleutels, toegangstokens of testwachtwoorden direct in de code terechtkomen. Soms tijdelijk, vaak onbedoeld, maar wel zichtbaar. En zelfs als u AI niet intern gebruikt, maar via een leverancier: de risico’s verplaatsen zich. Niet het eigenaarschap.
Van slimme suggestie naar eigen toegang
En het stopt niet bij onbedoelde lekken. AI-tools voeren steeds vaker zelfstandig taken uit. Ze halen data op, draaien scripts, maken automatische back-ups. Dat vraagt om toegang. En dus om digitale sleutels.
Zodra zo’n sleutel wordt aangemaakt voor een systeem of proces, ontstaat er een digitale gebruiker: een toegang die niet aan een mens hangt, maar aan software. Dat noemen we in het Nederlands een machine-identiteit.
Wat is dat precies?
Een machine-identiteit is eigenlijk niets meer dan een digitale medewerker. Geen gezicht, geen bureaustoel: maar wél toegang tot uw systemen. Denk aan een script dat automatisch rapporten draait. Of een AI-tool die via een API data ophaalt.
Die systemen loggen niet in met gebruikersnaam en wachtwoord, maar met sleutels, tokens of certificaten. En zolang die actief zijn, heeft die software toegang. Net als een gewone gebruiker.
Het verschil? Mensen melden zich aan: en weer af. En als ze het bedrijf verlaten, heft iemand hun accounts op. Maar machine-identiteiten blijven vaak bestaan. Soms vergeten. Soms zonder beperking. En soms met toegang tot alles.
Waarom dat risico oplevert
Niet alle toegangen zijn gekoppeld aan mensen. En dus mist u zicht. Of grip. Elke keer dat u een AI-tool gebruikt die automatisch iets uitvoert, ontstaat er zo’n identiteit. Vaak zonder dat u het weet. Zonder logging. Zonder beheer. En zonder ‘natuurlijk moment’ om op te ruimen.
Waar menselijke accounts netjes worden gedeactiveerd, blijven machine-identiteiten draaien. Ouderwets geconfigureerd. Onbewaakt. Maar machtig.
Vergeten, overbevoegd en onzichtbaar
AI versnelt het aanmaken van machine-identiteiten. Maar nog belangrijker: het vergroot de kans dat ze vergeten worden. Dat ze te veel rechten krijgen. Of dat niemand ze meer in de gaten houdt.
AI-tools krijgen vaak toegang tot meerdere systemen tegelijk. Omdat ze zelf beslissen hoe ze hun taak uitvoeren. Dus geven we ze liever te veel rechten dan te weinig.
Een AI-agent die automatisch facturen controleert, moet toegang krijgen tot financiële data. Maar wat als datzelfde script ook toegang heeft tot klantgegevens, personeelsinformatie of contracten? Omdat het makkelijker was om “admin” toe te kennen dan het recht fijnmazig te beheren?
Dat lijkt handig. Tot het misgaat. Eén gelekte sleutel kan toegang geven tot systemen waar niemand aan dacht. En wie weet dan nog waarvoor die sleutel bedoeld was? Of wie hem ooit heeft aangemaakt?
Prompts als onverwachte lekken
Het risico zit niet alleen in de code. Ook in de opdrachten die u aan AI geeft.
Stel, iemand uit finance vraagt een AI-chatbot: “Geef me alle transacties boven €100.000. Gebruik API-sleutel: X123.”
Wat gebeurt er met die sleutel? Vaak wordt die opgeslagen. In logs. In het geheugen van het model. Misschien zelfs in de training van toekomstige AI-versies.
Prompt-gebaseerde systemen zijn niet gemaakt voor gevoelige data. Maar mensen gebruiken ze er wel voor. Omdat het makkelijk is. Snel. En niemand hen vertelt dat het onveilig is.
Zeker nu AI toegang krijgt tot cloudopslag, CRM-systemen, interne documenten en chatplatforms, wordt het risico groter dan alleen in de IT-hoek. AI-gebruik leeft door de hele organisatie. Van support tot HR. Van marketing tot inkoop.
Iedereen die AI gebruikt, kan onbedoeld een lek veroorzaken.
Waarom klassieke beveiliging tekortschiet
De meeste securitymaatregelen zijn gebouwd rondom mensen. Menselijke accounts. Menselijke fouten. Menselijke gedragingen.
Maar machine-identiteiten gedragen zich anders. Ze melden zich niet aan via een inlogportaal. Ze klikken niet op phishing-links. Ze werken 24/7. En ze staan buiten zicht van de meeste monitoringtools.
Daarom voldoen traditionele beveiligingsmaatregelen vaak niet. Een wachtwoordbeleid helpt niet als er geen wachtwoord is. Logging slaat niets op als niemand weet dat een identiteit bestaat. Rechtenbeheer faalt als er niemand verantwoordelijk is voor een sleutel die twee jaar geleden door een AI-script werd aangemaakt.
Wat u wél kunt doen
U hoeft AI niet af te remmen. Maar u moet het wel in goede banen leiden. Zonder overzicht is er geen controle.
Zorg dat elke digitale sleutel een eigenaar heeft. Geef alleen toegang die echt nodig is. Laat toegangen automatisch verlopen. Gebruik tools die machine-identiteiten kunnen ontdekken en beoordelen op overmacht. En wees kritisch op automatische code die AI voorstelt.
Denk ook aan de mens. Niet alleen ontwikkelaars gebruiken AI. Ook HR, finance en marketing. Iedereen die prompts intikt, kan per ongeluk iets delen wat nooit gedeeld had mogen worden.
Train uw mensen. Maak risico’s bespreekbaar. Laat beveiliging meebewegen met het tempo van AI. Niet als rem, maar als richting.
Hou grip op wie en wat voor u werkt
AI versnelt. Het is een versneller van werk. Maar ook van fouten. En van blinde vlekken.
Met AI in de toolbox hoeft u echt niet alles zelf te doen. Maar u moet wel weten wat u uit handen geeft. En aan wie. Of beter gezegd: aan wat.
Zorg dat u grip houdt. Niet alleen op uw mensen. Maar ook op de systemen die u namens hen laat werken. Want als u niet weet wie toegang heeft tot uw data, dan weet u ook niet wie het op een dag misbruikt.
Verder praten over dit onderwerp? Of over andere cybersecurity vraagstukken? Neem vrijblijvend contact met ons op.
