Truffle Security vond 543.699 nog geldige credentials in AI-trainingsdata

In een voor AI-training verzamelde dataset bleken 543.699 nog geldige credentials te staan, meldt de Cloud Security Alliance. Dat toont dat secrets management niet mag stoppen bij opslaan en roteren: beperk de scope en levensduur van credentials vooraf, isoleer agentuitvoering tijdens runtime en scan actief buiten de secrets manager naar lekken in code, logs en trainingsdata.

De briefing van de Cloud Security Alliance van 1 oktober 2026 vat een analyse van Truffle Security samen: in een corpus van 224 miljoen publieke GitHub-repositories dat voor het trainen van AI-modellen was samengesteld, testte Truffle Security in juli 2026 543.699 unieke credentials die nog succesvol authenticeerden. Het gaat niet om een nieuw lek, maar om bestaande fouten die via een extra kanaal opnieuw vindbaar werden. Dat kanaal is het punt: trainingsdata is een plek waar een geheim kan belanden en blijven staan.

Voor beslissers betekent dit dat de vraag verschuift van waar bewaren we onze geheimen naar welke systemen kunnen onze geheimen lezen, meenemen of opnieuw tonen. AI-workflows vergroten het aantal van die plekken.

Wat stelde de Cloud Security Alliance precies vast over credentials in AI-trainingsdata?

De Cloud Security Alliance rapporteert dat Truffle Security 543.699 nog geldige credentials vond in een grote verzameling publieke GitHub-code die bedoeld was als trainingsdata. Het nieuwe inzicht is niet dat geheimen in publieke code staan, maar dat het samenstellen van trainingscorpora een aanvullende laag voor ontdekking en blootstelling vormt.

Dat beeld sluit aan op cijfers van GitGuardian, die vaststelde dat publieke code 1,27 miljoen blootgestelde credentials van AI-diensten bevatte en dat een groot deel van eerder als geldig bevestigde geheimen jaren later nog niet was ingetrokken. Volgens GitGuardian is dat precies waar een secrets manager, die alleen beheerde geheimen beschermt, en monitoring van publieke lekken uit elkaar lopen.

Waarom ziet een secrets manager de credentials in logs, caches en trainingsdata niet?

Een secrets manager beschermt de geheimen die er bewust in zijn gezet en beheerd worden. Hij ziet niet automatisch de kopie die een ontwikkelaar in een repository plakte, de token die in een logregel terechtkwam of de sleutel die via een modelcache of trainingsdataset elders beschikbaar werd. Die exemplaren leven buiten de kluis; rotatie verwijdert die kopieën niet en maakt niet noodzakelijk elke blootstellingslocatie ongedaan, ook als zij de gelekte credential soms wel ongeldig maakt.

Mandiant beschrijft in zijn special report hoe agentische workflows credentials kunnen blootleggen via configuraties, tool-caches, terminalgeschiedenis en de output van agents zelf. De exploit-roundup van het OWASP GenAI Security Project voegt daar concrete incidenten aan toe waarin te ruime rechten, toolkoppelingen en MCP-servers tot ongeautoriseerde toegang of pogingen tot exfiltratie van geheimen leidden. Naar onze inschatting is de les uit beide bronnen dat instructies in een prompt geen betrouwbare grens vormen: wie een agent toegang geeft tot privédata, onvertrouwde inhoud én externe communicatie, bouwt zelf een kanaal voor datalekken.

Hoe begrens ik credentials vóór, tijdens en na uitvoering van AI-agents en pijplijnen?

Onze analyse vertaalt de afzonderlijke bronbevindingen naar drie aanvullende controlelagen: vóór, tijdens en na uitvoering.

• Vóór uitvoering. Onze aanbeveling is: geef elke agent een eigen identiteit, gebruik kortlevende en taakgebonden credentials, hanteer minimale rechten en houd ontwikkel-, trainings- en productiedata gescheiden. Mandiant ondersteunt in het bijzonder afzonderlijke agentidentiteiten, kortlevende credentials en least privilege. Zo kan een credential die toch lekt weinig openen en vervalt hij snel.
• Tijdens uitvoering. Onze aanbeveling voor tijdens uitvoering: beperk waar een agent naartoe mag verbinden (egress), leg tool- en MCP-koppelingen vast in beleid, maskeer geheimen in output en logs, en zorg voor runtime-telemetrie plus een onafhankelijk aangestuurde bevoegdheid om tokens direct in te trekken wanneer gedrag afwijkt. Mandiant ondersteunt onder meer egress-beperking, runtime-telemetrie en credential-intrekking.
• Na blootstelling. Scan buiten de secrets manager: publieke repositories, caches, logbestanden, modelartefacten en trainingscorpora. Volg een vondst op met rotatie, bepaal de scope van de schade en leg bewijs van herstel vast.

Onze toevoeging: de bronnen beschrijven deze maatregelen los van elkaar. Het open punt is hoe continue detectie buiten de kluis zich verhoudt tot menselijke verificatie in geautomatiseerde pijplijnen. Een scan die een geheim vindt maar niemand die beslist of en wanneer het wordt ingetrokken, levert geen bescherming maar een lijst. De koppeling tussen automatische detectie en een persoon met intrekkingsbevoegdheid is de plek waar dit in de praktijk vastloopt.

Wat betekent dit nieuws voor bestuurders, juristen en CISO's?

Onze analyse: omdat de Cloud Security Alliance aantoont dat geldige geheimen via trainingsdata opnieuw vindbaar werden, verliest de aanname dat een secrets manager het risico afdekt haar grond, wat bestuurders en CISO's raakt die daarop hun verantwoording bouwen; daarom hoort dit kwartaal de vraag op tafel of er detectie bestaat buiten de kluis, en wie bevoegd is een gelekt token in te trekken. Omdat Mandiant en OWASP laten zien dat agents via caches, logs en tools geheimen kunnen doorsluizen, ontstaat voor de CISO een concreet runtime-risico dat met beleid alleen niet verdwijnt; daarom moet elke productieagent nu een eigen identiteit, kortlevende credentials en begrensde egress krijgen, en moet je een AI-agent met systeemtoegang besturen als privileged identity. Omdat GitGuardian meldt dat een groot deel van bevestigde geheimen jaren later nog niet was ingetrokken, loopt de jurist het risico dat een datalek niet aantoonbaar is afgehandeld; daarom hoort in verwerkersafspraken en leveranciersclausules te staan dat detectie, rotatie en bewijs van herstel binnen een afgesproken termijn gebeuren. Omdat trainingsdata zelf nu een blootstellingslaag is, moet de verantwoordelijke voor modelbouw voortaan vastleggen welke bronnen een corpus voedden en of die op geheimen zijn gescand, voordat training start.

Als samenvatting van die analyse, concreet te beleggen bij een eigenaar:

1. Breng in kaart welke agents en pijplijnen toegang hebben tot langlevende credentials en vervang die door kortlevende, taakgebonden varianten.
2. Richt detectie in buiten de secrets manager op publieke code, logs, caches en trainingsdata, en koppel elke vondst aan een persoon die mag intrekken.
3. Leg per gevoelige workflow vast welke agent, welke scope, welke datomgeving en welke menselijke goedkeuring eraan gekoppeld waren.
4. Zet in leverancierscontracten een aantoonbare termijn voor rotatie en bewijs van herstel na blootstelling.

Deze stappen sluiten aan op de bredere verschuiving van perimeterverdediging naar identiteit en runtime van AI-agents en op de noodzaak van een afgedwongen noodstop en intrekking voor AI-agents. Meer achtergrond staat in onze themahub over AI-security en beveiliging van AI-workflows.

Bronnen: Het artikel steunt op de Cloud Security Alliance (Truffle Security-analyse), het Mandiant-rapport van Google Cloud, de OWASP GenAI exploit-roundup en GitGuardian.