AI-codeeragenten veranderen hoe snel ontwikkelaars software kunnen bouwen en verzenden, en hoe snel inloggegevens openbaar kunnen worden gemaakt. Volgens het State of Secrets Sprawl Report van GitGuardian uit 2026 lekken commits die zijn geïdentificeerd als AI-ondersteund, ongeveer twee keer zoveel geheimen als door mensen geschreven. De meeste van de snelstgroeiende categorieën gelekte inloggegevens zijn nu verbonden met AI-diensten, wat betekent dat de tools die bedoeld zijn om de ontwikkeling te bevorderen ook de ontmaskering van de sleutels waarvan de ontwikkeling afhankelijk is, versnellen.
Dit is geen nieuwe kwetsbaarheid; Wat nieuw is, is dat AI de schaal en het tempo verandert waarin deze fouten kunnen gebeuren. Een codeeragent kan een heel project lezen, bestanden wijzigen, configuraties genereren en communiceren met externe services in de tijd die een ontwikkelaar nodig heeft om een enkele pull-request te beoordelen. Het belangrijkste probleem is niet dat AI-agenten soms geheimen tegenkomen, maar dat veel van die geheimen nooit zijn ontworpen voor een omgeving waarin software autonoom kan handelen. AI-codeeragenten dragen bij aan de verspreiding van geheimen door inloggegevens in meer bestanden te hardcoderen en bestaande bestanden over meer systemen te verspreiden dan beveiligingsteams kunnen volgen en roteren.
Hoe de wildgroei van geheimen is veranderd in het tijdperk van agenten-AI
Er ontstaat een wildgroei aan inloggegevens, zoals API-sleutels, tokens en serviceaccountreferenties, over meer systemen dan een organisatie op betrouwbare wijze kan inventariseren en roteren – hardgecodeerd in bronbestanden, in configuraties geplakt en in tickets gekopieerd. Beveiligingsteams hebben van oudsher geprobeerd deze wildgroei onder controle te houden door met terugwerkende kracht blootgestelde geheimen op te sporen; Scanners houden opslagplaatsen in de gaten, pre-commit hooks vangen op wat ze kunnen en beveiligingsteams wisselen inloggegevens uit nadat een blootstelling is ontdekt. Die controles zijn nog steeds van belang, maar AI-agenten leggen de beperkingen bloot van het afhankelijk zijn van alleen detectie. Agenten kunnen lokale bestanden lezen, opdrachten uitvoeren, API’s aanroepen, communiceren met Model Context Protocol (MCP)-servers en de configuratie wijzigen. Elke extra mogelijkheid creëert een nieuwe plek waar een legitimatiebewijs nodig kan zijn en een ander pad waarlangs dat legitimatiebewijs zich kan verspreiden.
Dit is de reden waarom organisaties de wildgroei van geheimen in het tijdperk van agentische AI moeten behandelen als een probleem van niet-menselijke identiteit (NHI), en niet als een probleem van modelgedrag. Elke nuttige actie die een agent op een ander systeem onderneemt, heeft een identiteit. Wanneer agenten een database doorzoeken, een API aanroepen en in fasering implementeren, autoriseren sommige referenties die actie. Organisaties kunnen niet op betrouwbare wijze voorspellen welke actie een autonoom systeem zal ondernemen, maar ze kunnen wel bepalen waartoe de identiteit achter dat systeem toegang krijgt.
Hoe AI-codeeragenten geheimen kunnen onthullen
Wat codeeragenten nuttig maakt, is ook wat nieuwe identificatierisico’s met zich meebrengt: agenten hebben context nodig. Een agent die niet een heel project kan lezen, biedt niet veel hulp, vooral niet een agent die voor elke bewerking opnieuw moet worden geautoriseerd. Hieronder staan verschillende manieren waarop dit in de praktijk uitpakt, wat aantoont waarom organisaties voorzichtiger moeten zijn bij het verlenen van toegang aan AI-codeeragenten tot inloggegevens en geheimen.
Agenten hebben toegang tot gevoelige bestanden in de projectcontext
Ontwikkelaars bewaren vaak inloggegevens in .env-bestanden en lokale configuraties, achtergelaten na een eerdere foutopsporingssessie en nooit bedoeld voor broncodebeheer. Een AI-codeeragent met brede toegang tot een project kan deze bestanden mogelijk lezen samen met de applicatiecode die hij moest analyseren. Voor een AI-agent maakt een configuratiebestand met een productie-API-sleutel nog steeds deel uit van de werkomgeving, dus tenzij de toegang expliciet wordt beperkt, kan de referentie beschikbaar komen voor de agent, zelfs als deze niet relevant is voor de taak. Dit verschuift de beveiligingsaannames rond werkstations van ontwikkelaars: lokale inloggegevens in leesbare tekst zijn niet langer alleen toegankelijk voor de ontwikkelaar en de applicaties die er expliciet naar verwijzen, maar zijn nu potentieel ook beschikbaar voor softwareagenten die in dezelfde omgeving opereren.
Agent- en MCP-configuraties kunnen hardgecodeerde referenties bevatten
Installatie-instructies voor agenten en MCP-servers vereenvoudigen routinematig de manier waarop ontwikkelaars AI-applicaties verbinden met databases, API’s en andere externe systemen. Omdat veel integraties authenticatie vereisen, betekent deze vereenvoudiging vaak dat de referenties rechtstreeks in een configuratiebestand worden geplakt. Omdat dat bestand nooit onder versiebeheer valt, kun je gemakkelijk aannemen dat de referentie veilig is. De referentie kan echter nog steeds in leesbare tekst op een ontwikkelaarscomputer bestaan, vaak op een locatie waar de agent leesrechten heeft.
Geheimen worden gedupliceerd op oppervlakken die teams niet mogen scannen
Een geheim leeft zelden op één locatie; dezelfde sleutel komt terecht in een .env-bestand, een CI/CD-variabele of zelfs een Jira-ticket, terwijl engineers problemen met een mislukte implementatie oplossen. Een AI-codeeragent die met deze systemen is verbonden, introduceert nog een kwetsbaarheid: aangezien elke kopie van een geheim authenticeert, zorgt het roteren van de kopie in de repository ervoor dat de rest blijft werken. Dit is de reden waarom het scannen van repository’s alleen de wildgroei van geheimen niet kan oplossen. Een groot deel van de geheime incidenten kan volledig buiten de codeopslagplaatsen ontstaan, met blootstelling aan samenwerkings- en ticketingtools. Daarom heeft het roteren van de kopie die in een opslagplaats wordt gevonden een minimaal voordeel als dezelfde identificatie elders geldig is.
Er zijn vaak te veel machtigingen voor agenten
Een agent heeft voldoende toegang nodig om zijn werk uit te voeren, waardoor er druk ontstaat om brede machtigingen te verlenen om ervoor te zorgen dat zijn taken nuttig zijn. Machtigingen die tijdens het prototypen worden verleend om fouten te voorkomen, kunnen onderdeel worden van een productieproces, dus de oorspronkelijke machtigingen met tijdelijke bedoelingen blijven bestaan; niemand bezoekt ze opnieuw zodra de workflow actief is. Het risico neemt verder toe in multi-agentsystemen. Een orkestratielaag met sleutels voor verschillende agenten kan een domino-effect van gecompromitteerde identiteiten veroorzaken, waarbij aanvallers toegang krijgen tot alles waartoe de orkestrator geautoriseerd was.
De governancekloof is al meetbaar. In de RSAC 2026-enquête van Keeper Security zei 46% van de respondenten dat AI-aangedreven tools toegang hebben tot kritieke systemen en gevoelige gegevens, maar 76% van de respondenten zei dat deze identiteiten niet consequent worden beheerd door een beleid voor geprivilegieerde toegang. Zelfs als toegang wordt verleend, bestaan de controles die normaal gesproken gepaard gaan met dat toegangsniveau vaak niet.
Hoe geheimen veilig te stellen in AI-ondersteunde ontwikkeling
Het volledig verbieden van AI-coderingstools is voor de meeste organisaties niet realistisch, en eerlijk gezegd ook niet nodig. In plaats daarvan moeten organisaties AI-agenten beschouwen als een andere identiteit die in ontwikkelomgevingen actief is en dienovereenkomstig toegang verlenen. Hier zijn verschillende manieren om geheimen veilig te stellen in AI-ondersteunde ontwikkeling:
- Verwijder statische inloggegevens uit de ontwikkelaarsomgeving: In plaats van geheimen op te slaan in .env-bestanden, MCP-configuraties of IDE-instellingen, moeten organisaties geheimen ophalen van een gecentraliseerd geheimbeheerplatform wanneer ze nodig zijn. Als de leesbare tekstreferentie niet op het werkstation staat, kan een agent deze niet per ongeluk lezen vanuit de ontwikkelomgeving.
- Vervang sleutels met een lange levensduur door kortstondige, automatisch geroteerde inloggegevens: Een statische sleutel die lekt, blijft een risico zolang deze geldig blijft, wat maanden of jaren kan duren. Een kortstondige inloggegevens die binnen enkele minuten verlopen en volgens een vast schema roteren, verkleinen dat venster aanzienlijk en maken het niet meer nodig om elk exemplaar te vinden voordat een aanvaller dat doet.
- Geef elke agent zijn eigen scope-identiteit: Gedeelde serviceaccounts maken het bijna onmogelijk om te identificeren welke agent welke actie heeft uitgevoerd, en ze zorgen ervoor dat elke agent de breedste toestemming krijgt die een van hen nodig heeft. Organisaties moeten elke AI-agent alleen de machtigingen geven die nodig zijn voor zijn taak, en deze machtigingen waar mogelijk tijdelijk maken. Door een AI-agent als een aannemer te behandelen, kunnen organisaties deze binnen een bepaalde periode specifieke middelen laten beheren en specifieke acties ondernemen.
- Breid het beheer van geheimen uit tot buiten codeopslagplaatsen: CI/CD-infrastructuur, werkstations voor ontwikkelaars, MCP-configuraties, ticketingsystemen en samenwerkingstools bevatten inloggegevens die het scannen van repository’s nooit ziet, en een groot deel van de geheime incidenten vindt nu zijn oorsprong in deze aanvalsoppervlakken. Beveiligingsteams moeten meer inzicht hebben dan broncontrole.
- Een mens nodig hebben voor gevoelige operaties: Toegang tot inloggegevens, productie-implementaties en wijziging van bevoegdheden mogen niet autonoom worden en moeten in plaats daarvan expliciete goedkeuring inhouden. Modi voor automatisch goedkeuren moeten een doelbewuste beleidsbeslissing zijn met een gedefinieerd bereik, en geen standaard die een ontwikkelaar één keer inschakelt en nooit meer herhaalt.
- Voorraadagenten en MCP-servers zijn al actief: De meeste organisaties hebben meer agents draaien dan ze denken, die door individuele ontwikkelaars zonder goede controle zijn geïnstalleerd. Organisaties moeten weten welke agenten en MCP-servers in hun omgeving actief zijn, wie de eigenaar is, welke identiteiten ze gebruiken en waartoe deze identiteiten toegang hebben.
- Registreer en controleer alle agentactiviteiten: NHI’s hebben hetzelfde toegangspad nodig als menselijke identiteiten. Zonder registratie van welke gegevens een agent heeft gebruikt en wat deze heeft bereikt, kan incidentrespons niet helpen bij het reconstrueren van een inbreuk en heeft deze niets te bewijzen in compliance-audits.
De verspreiding van geheimen is een identiteitsprobleem, geen AI-probleem
Softwareontwikkeling is een van de belangrijkste zakelijke toepassingen voor AI, en geen enkel beveiligingsteam kan dit alleen met beleid veranderen. AI-agenten hebben geen wildgroei aan geheimen gecreëerd; ze lieten zien hoeveel organisaties slechte strategieën hebben voor de beveiliging van machinereferenties. Realistisch gezien is het doel ervoor te zorgen dat de geheimen die AI-agenten tegenkomen niet de moeite waard zijn om te stelen. Dat betekent het elimineren van onnodige statische inloggegevens, het verwijderen van permanente privileges, het verkorten van de levensduur van inloggegevens, het scheiden van identiteiten en het behouden van inzicht in de manier waarop machine-identiteiten worden gebruikt. Meer scannen lost dit probleem niet op, omdat het nog steeds inloggegevens vindt zodra deze zich hebben verspreid; wat helpt is gecentraliseerde controle zonder kennis over hoe geheimen worden opgeslagen, beperkt en verlopen. Met Keeper Secrets Manager kunnen organisaties infrastructuurgeheimen centraal beveiligen, hardgecodeerde inloggegevens uit ontwikkelingsworkflows verwijderen en het gebruik van geheimen controleren als onderdeel van een zero-trust, zero-knowledge platform. AI-agenten zullen sneller en efficiënter blijven werken, maar de referenties erachter moeten een kortere levensduur krijgen en een beperkter bereik krijgen om hun toegang te helpen regelen.
Opmerking: Dit artikel is zorgvuldig geschreven en bijgedragen voor ons publiek door Ashley D’Andrea, Senior SEO en Content Marketing Specialist bij Keeper Security.
