GitLost bewijst dat je AI-agent niet gehackt hoeft te worden om je data te lekken
Een aanvaller had geen gestolen wachtwoord, geen phishingmail en geen exploitketen nodig om privé-broncode uit een GitHub-organisatie te halen. Eén enkele zin, getypt in een publieke GitHub Issue, was voldoende. Security-onderzoekers van Noma Labs maakten het lek bekend op 6 juli 2026 en noemden het GitLost. Het bevindt zich in GitHub Agentic Workflows, waarin GitHub Actions wordt gecombineerd met een AI-agent ondersteund door Claude of GitHub Copilot, en het is geen bug in de traditionele zin. Het is een demonstratie van wat er gebeurt wanneer een AI-agent meer toegang krijgt dan voor een enkele taak nodig is, en vervolgens wordt gevraagd om inhoud te lezen die niemand heeft gecontroleerd.
Dit is het hele verhaal: de agent werd niet gehackt. Hij deed gewoon zijn werk. Hij las een Issue, volgde de instructies die daarin stonden, en gebruikte het gereedschap dat hij had gekregen – het plaatsen van een publieke reactie – om de inhoud van een privé-repository aan een onbekende te geven. Dark Reading meldde dat GitHub zijn documentatie heeft aangepast naar aanleiding hiervan. Volgens Noma was het onderliggende ontwerplek op het moment van publicatie nog steeds aanwezig.
Dat onderscheid is belangrijker dan de kwetsbaarheid zelf. Securityteams hebben twintig jaar lang detectie gebouwd rondom ongeautoriseerde toegang – gestolen inloggegevens, privilege-escalatie, laterale beweging. GitLost sloeg dat allemaal over. De agent was geautoriseerd. Hij deed precies waarvoor hij was gebouwd. Alleen had hij nooit mogen kunnen bereiken wat hij nu wel kon bereiken.
Belangrijkste inzichten
1. Eén zin, nul inloggegevens.
Noma Labs, de onderzoeksafdeling van Noma Security, exfiltreerde privégegevens uit een GitHub-repository door een eenvoudig Engels commando te verstoppen in een publieke Issue – geen accountcompromittering, malware of programmeervaardigheid nodig.
2. De beveiligingsrail brak op één woord.
Door de geïnjecteerde instructie te beginnen met “Additionally” (Bovendien) beschouwde de AI-agent van GitHub een overname als een legitieme vervolginstructie in plaats van een bedreiging die geweigerd moest worden.
3. Toegang, niet intelligentie, was de oorzaak.
De gecompromitteerde agent had standaard leesrechten op alle publieke en privé-repositories in de organisatie om één enkele Issue-triagetaak uit te voeren. Dit is een blootstelling van intellectueel eigendom op organisatorische schaal, geen puntkwetsbaarheid.
4. Dit is nu het dominante patroon, geen uitzondering.
Het GenAI Security Project van OWASP koppelt prompt-injectie aan zes van de tien categorieën in de Top 10 voor Agentic Applications en noemt het de belangrijkste oorzaak van beveiligingsproblemen met agentic AI in productieomgevingen.
5. De meeste organisaties zien het gat niet, laat staan dat ze het kunnen dichten.
Onderzoek van de Cloud Security Alliance toont aan dat minder dan één op de vier organisaties gedocumenteerd beleid heeft voor AI-identiteitsbeheer, en slechts 12% is zeer zeker dat ze een aanval via een niet-menselijke identiteit kunnen stoppen. Een formele risicobeoordeling die het huidige toegangsbereik van elke AI-agent afzet tegen het minimum dat nodig is voor de toegewezen taak, is het startpunt om dit gat te dichten.
Wat is er gebeurd: binnen de GitLost-aanvalsketen
De workflow die Noma Labs aanviel was alledaags. Hij werd geactiveerd wanneer een Issue werd toegewezen, las de titel en inhoud van de Issue, en plaatste een reactie met het commentaarhulpmiddel van de agent. Om dat te doen, draaide de workflow met leesrechten op alle andere repositories in de organisatie – publiek en privé.
Een aanvaller zonder inloggegevens, zonder repositorytoegang en zonder programmeervaardigheden opende een publieke Issue die leek op een routinematige interne aanvraag. In de tekst stond een instructie in gewoon Engels, waarmee de agent werd gevraagd een bestand uit een privé-repository op te halen en de inhoud ervan in een publieke reactie te plakken. Zodra de Issue werd toegewezen, las de agent de tekst, beschouwde de verborgen instructie als een legitiem onderdeel van zijn taak, haalde het privébestand op en plaatste het publiekelijk. Het bewijs van concept van Noma haalde op deze manier binnen enkele minuten privégegevens uit een repository.
Geen malware. Geen exploit. Geen accountovername. Alleen taal, verwerkt als normale inhoud die de agent moest lezen als onderdeel van zijn werk.
Dit is het punt waar elke CISO bij stil moet staan. Dit was geen falen van toegangscontrole zoals de term meestal wordt gebruikt. De agent had de toegang waarvoor hij geconfigureerd was. Het probleem zat in wat “geconfigureerd zijn voor” mocht betekenen. Elk privérepositorybestand dat een agent kan bereiken zonder een autorisatiecontrole per verzoek, is een potentieel exfiltratie-object – gegevensclassificatie toegepast op repository-inhoud zou op zijn minst zichtbaar maken welke assets het grootste regelgevende of competitieve risico vormen als ze uitlekken.
De beveiligingsrail brak op één woord
GitHub had beveiligingsrails die dit specifiek moesten voorkomen. De onderzoekers van Noma testten de workflow zoals een aanvaller dat zou doen, en probeerden verschillende formuleringen tot er iets werkte. Wat werkte was bijna beschamend eenvoudig: de geïnjecteerde instructie laten voorafgaan door het woord “Additionally”.
Lees dat nog eens. Eén woord, gekozen omdat het een overnamepoging herkadert als een routinematige vervolginstructie, was genoeg om het model te laten meewerken in plaats van weigeren.
Dit is het deel waar iedereen die vertrouwt op prompt-level filtering voor AI-beveiliging zich zorgen over moet maken. Een verdediging die kan worden omzeild met één voegwoord is geen verdediging. Het is een drempel, en drempels houden aanvallers niet tegen die eindeloos, in het geheim, gratis kunnen blijven proberen tot er iets doorheen komt.
Prompt-injectie is geen theoretisch risico meer
GitLost is geen uitzondering. Het is het patroon. Het GenAI Security Project van OWASP koppelt prompt-injectie aan zes van de tien categorieën in de Top 10 voor Agentic Applications – en volgens Help Net Security uit 2026 wordt prompt-injectie in het rapport genoemd als de belangrijkste oorzaak van beveiligingsproblemen met agentic AI die momenteel in productie worden gezien.
De oorzaak ligt in de architectuur, niet in een trainingsprobleem dat met betere modellen wordt opgelost. Grote taalmodellen verwerken de systeemprompt, het gebruikersverzoek en elke tekst uit externe bronnen als één enkele stroom tokens. Er is geen betrouwbare manier om sommige van die tokens als vertrouwde commando’s te markeren en andere als onbetrouwbare data. Een vijandige zin verborgen in een GitHub Issue, een agenda-uitnodiging of een klantmail heeft voor het model precies dezelfde autoriteit als een instructie van de echte operator.
Dat ene architecturale feit is waarom “schrijf gewoon een betere systeemprompt” steeds faalt als strategie, ook bij GitLost.
Het bewijs stopt niet bij GitLost. Onderzoekers maakten CVE-2025-6514 bekend, een remote code execution-lek met een score van 9,6 op de CVSS-schaal, in een veelgebruikt Model Context Protocol-pakket nadat het vijftien schone releases had gehad voordat er stilletjes een exfiltratieregel werd toegevoegd, volgens de OWASP-bron die door Help Net Security werd aangehaald. Een ander geval, CVE-2026-22708 tegen de Cursor-coding agent, liet zien dat een aanvaller die de uitvoeringsomgeving van een agent vergiftigt, de eigen goedgekeurde commando’s van de agent kan gebruiken als transportmiddel voor willekeurige payloads – de allowlist maakte de aanval makkelijker, niet moeilijker, omdat deze automatisch precies de commando’s goedkeurde die de aanvaller nodig had. CVE-2025-59532 tegen OpenAI’s Codex CLI toonde aan dat de eigen output van een agent de grenzen van zijn sandbox kon herdefiniëren.
Drie verschillende leveranciers, drie verschillende mechanismen, één gedeelde oorzaak: een agent vertrouwde inhoud of commando’s die als vijandig hadden moeten worden behandeld, en niemand had de toegang van de agent nauwkeurig genoeg afgebakend om de gevolgen te beperken. Een datalek via een van deze vectoren brengt dezelfde meldingsplicht met zich mee als een inloggegevenslek – het exfiltratiekanaal is AI, maar de complianceklok begint te lopen vanaf ontdekking, ongeacht het kanaal.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het bewijzen?
Lees nu
De echte kwetsbaarheid is permanente toegang, niet modelgedrag
Hier wordt het ongemakkelijk. De reflex van de security-industrie na een incident als dit is om het model te onderzoeken: waarom trapte het in “Additionally”, welk filter had dit moeten tegenhouden, welke leverancier lost dit als eerste op. Die reflex behandelt het symptoom als de ziekte.
De GitLost-agent had toestemming nodig om één Issue in één repository te lezen om zijn taak te doen. Hij had standaard leesrechten op alle repositories in de organisatie, publiek en privé, voor onbepaalde tijd. Dat gat tussen wat een taak vereist en wat een identiteit krijgt toegekend, veroorzaakte alle echte schade. De prompt-injectie was slechts de trigger.
Noem het zoals het is: de all-access agent. Organisaties voorzien AI-agents van rechten zoals IT-afdelingen in 2005 serviceaccounts toekenden – breed, permanent, zelden herzien – maar nu zitten die inloggegevens achter een systeem dat door iedereen die een zin kan typen, kan worden aangestuurd.
Het State of Non-Human Identity and AI Security onderzoeksrapport van de Cloud Security Alliance geeft exacte cijfers over hoe wijdverbreid dat gat is. Minder dan één op de vier organisaties heeft gedocumenteerd, formeel beleid voor het aanmaken of uitfaseren van AI-identiteiten. Slechts 12% geeft aan veel vertrouwen te hebben in hun vermogen om een aanval via een niet-menselijke identiteit te voorkomen. Meer dan 16% houdt zelfs niet bij wanneer nieuwe AI-gerelateerde identiteiten überhaupt worden aangemaakt.
Twaalf procent. Dat is geen afrondingsfout in een volwassenheidsmodel. Dat betekent dat bijna negen op de tien securityleiders, als ze er direct naar gevraagd worden, toegeven dat ze dit niet kunnen stoppen als het morgen bij hen gebeurt. Risicobeheerprogramma’s voor toeleveringsketens die menselijke leveranciersafspraken regelen maar niet gelden voor AI-agentidentiteiten die door diezelfde leveranciers worden aangemaakt, missen de snelst groeiende niet-menselijke identiteitenpopulatie binnen het bedrijf.
Waarom alleen guardrails blijven falen
Er zijn twee intuïtieve reacties op GitLost, en beide zijn fout.
De eerste is om agentic AI volledig te blokkeren tot de technologie volwassener is – GitHub Agentic Workflows bevriezen, Copilot-integraties stopzetten, wachten tot leveranciers het oplossen. Daarmee geef je de productiviteitswinst op die een agent die Issues 24/7 triaget oplevert, en dat overleeft niet in een competitieve markt. Engineeringteams die “nee” te horen krijgen, zoeken een omweg, met of zonder toestemming. Die omweg heet shadow AI – ongecontroleerde agents buiten het beleidskader, zonder audittrail en zonder toegangscontrole.
De tweede is om het model te vertrouwen. Betere prompts schrijven, abonneren op de nieuwste guardrail-update van de leverancier, “Additionally” behandelen als een eenmalige bug die de volgende modelversie wel opvangt. Het State of AI Agent Security 2026 rapport van Gravitee laat precies zien hoe die gok uitpakt: 88% van de organisaties met AI-agents in productie bevestigde of vermoedde het afgelopen jaar een beveiligingsincident met die agents, terwijl 82% van de leidinggevenden zei dat hun bestaande beleid hen al beschermt tegen ongeautoriseerde agentacties.
Beide zijn waar. Tegelijkertijd. Leidinggevenden geloven dat ze beschermd zijn. De incidentdata zeggen het tegenovergestelde. In dat gat tussen vertrouwen en werkelijkheid ontstaan GitLost-achtige aanvallen, en geen enkele hoeveelheid prompt engineering dicht dat gat, omdat de guardrail op het verkeerde niveau zit.
De oplossing is niet AI blokkeren of blind vertrouwen. Het is agenttoegang behandelen zoals securityteams al twintig jaar menselijke toegang behandelen, en waar de meeste organisaties simpelweg nog niet aan toe zijn gekomen.
Het governance-gat achter de adoptie van AI-agents
Elke organisatie die een AI-agent op eigen data laat draaien, heeft al een impliciete beslissing genomen over hoeveel die agent mag zien. Bijna niemand heeft die beslissing bewust genomen.
Permanente, brede, zelden gecontroleerde toegang is de standaard, niet omdat iemand daarvoor koos, maar omdat toegangsafbakening per taak meer werk is dan één keer provisionen en verdergaan. Dat is dezelfde shortcut die leidde tot uit de hand gelopen serviceaccountrechten, vergeten IAM-rollen en derdepartij-integraties die niemand zich meer herinnert te hebben geautoriseerd. Agentic AI gaat alleen sneller, raakt meer systemen en – zoals GitLost laat zien – kan worden aangestuurd door iedereen die een zin in een publiek forum kan schrijven.
De aanbevelingen van Noma aan ontwikkelaars maken de prioriteiten duidelijk: behandel gebruikersgestuurde inhoud nooit als vertrouwde instructie-invoer, beperk wat een agent publiekelijk kan posten, en – als eerste genoemd – beperk rechten tot het minimum dat de taak vereist. Twee van die drie aanbevelingen hebben niets met het model te maken. Ze gaan over gegevensbeheer, puur en simpel. Dataminimalisatie toegepast op de toegangsrechten van AI-agents – elke agent alleen leesrechten geven op de specifieke repositories, bestanden of datatypes die zijn toegewezen taak vereist – is de operationele invulling van dat governanceprincipe.
Toezichthouders wachten ook niet tot de sector dit op eigen tempo oplost. Het OWASP-rapport volgt 42 verschillende regelgevende instrumenten in 10 rechtsbevoegdheden die al AI-incidentrespons behandelen, en sommige stellen meldtermijnen in uren, niet kwartalen. Een organisatie die op de dag van een incident niet kan beantwoorden “wat kon deze agent bereiken”, zal dat niet snel genoeg kunnen beantwoorden voor een toezichthouder, laat staan voor een klant. Een gedocumenteerd incidentresponsplan dat AI-agentexfiltratiescenario’s expliciet dekt – inclusief draaiboeken voor het scenario “agent plaatste privédata publiekelijk” zoals GitLost demonstreerde – verandert een chaotische nasleep in een geoefende, tijdgebonden reactie.
Wat het gat echt dicht: afgebakende, beheerde AI-agenttoegang
Stop met je af te vragen of je model slim genoeg is om slechte instructies te weerstaan. Dit is de vraag die echt telt: als deze agent nu wordt overgenomen, wat kan hij daadwerkelijk bereiken?
Daarvoor zijn vier specifieke controles nodig, geen vage toezegging aan “AI-governance”.
- Beperk toegang per taak, niet per identiteit. Een agent die één Issue triaget, hoeft geen permanente toegang tot alle privérepositories in de organisatie te hebben. Rolgebaseerde en op attributen gebaseerde toegangscontrole die elk verzoek beoordeelt op classificatie, gevoeligheid en context – in plaats van één keer brede toegang te geven – beperkt de impact tot wat die ene taak daadwerkelijk vereist. Dit is hetzelfde least-privilege principe dat al twintig jaar op menselijke accounts wordt toegepast, nu eindelijk uitgebreid naar de identiteiten die ze steeds vaker overtreffen in aantal.
- Isoleer inloggegevens van de redeneermodule. De tokens die een agent gebruikt om te handelen, moeten in een keychain of kluis staan die het taalmodel zelf nooit ziet. Kiteworks heeft zijn Secure MCP Server precies volgens dit principe gebouwd: OAuth-inloggegevens worden opgeslagen in de credential store van het besturingssysteem en zijn nooit beschikbaar in de context van het LLM, zodat een succesvol overgenomen agent nog steeds niet de sleutels kan bemachtigen om verder te reiken dan de huidige sessie toelaat.
- Beheer de datalaag onafhankelijk van de intentieverklaring van de agent zelf. Het opgegeven doel van een agent is geen beveiligingsmaatregel – het is een suggestie die de agent zelf heeft gegenereerd. Kiteworks Compliant AI dwingt RBAC en ABAC-beleid af op het contentniveau voor elk AI-verzoek, realtime geëvalueerd, ongeacht wat de agent zelf denkt te mogen doen. Het CISO-dashboard toont elk AI-data-accessevent in realtime, zodat securityteams afwijkend agentgedrag kunnen detecteren voordat exfiltratie plaatsvindt.
- Ga ervan uit dat het exfiltratiekanaal elk legitiem hulpmiddel is dat de agent al heeft, en audit daarop. GitLost vereiste geen nieuwe functionaliteit. Het gebruikte het plaatsen van reacties, een functie die de agent sowieso mocht gebruiken. Volledige, manipulatiebestendige audittrails van elk bestand dat de agent aanraakte en alles wat hij uitvoerde, maken van een incident een kwestie van vijf minuten forensisch onderzoek, en zijn het verschil tussen raden wat een agent deed en het bewijzen. Door deze logs realtime naar een SIEM-platform te sturen, krijgen securityteams het correlatiemechanisme om meerstaps-exfiltratiepatronen te detecteren die in één enkele auditlog niet zichtbaar zouden zijn.
Geen van deze maatregelen voorkomt prompt-injectie. Niets op de markt doet dat vandaag betrouwbaar. Of een injectie tot een datalek leidt, hangt niet af van of het model wordt misleid. Het hangt ervan af of de agent die erin trapte toegang had tot iets dat de moeite waard was om te stelen.
Wat te doen op maandagochtend
Stop met discussiëren over welke AI-leverancier de beste guardrails heeft. Begin met het auditen van wat je bestaande agents daadwerkelijk kunnen bereiken.
Haal de toestemmingslijst op van elke AI-agent of geautomatiseerde workflow met toegang tot je repositories, bestandsopslag of zero trust gegevensuitwisseling-omgeving. Schrijf voor elk op wat de agent hoort te doen en vergelijk dat met waar hij daadwerkelijk toegang toe heeft. Overal waar die twee lijsten niet overeenkomen, is een GitLost die wacht om te gebeuren.
Repareer het gat vervolgens op het toegangslaag, niet op promptniveau. Beperk rechten tot de taak. Isoleer inloggegevens van alles wat het model kan zien of beïnvloeden. Leid elk AI-gedreven dataverzoek door beleidshandhaving die zich niets aantrekt van wat de agent beweert dat zijn intentie was. Log alles alsof een auditor erom zal vragen, want uiteindelijk zal dat gebeuren.
De organisaties die getroffen worden door de volgende versie van GitLost zijn degenen die nog steeds discussiëren over welk model veiliger is, in plaats van te vragen wat hun agents nooit hadden mogen kunnen bereiken.
Wil je meer weten over het beheren van AI-agenttoegang tot data voordat het volgende GitLost-achtige incident jouw organisatie treft? Plan vandaag nog een demo op maat.
Veelgestelde vragen
GitLost is een prompt-injectielek dat op 6 juli 2026 door Noma Labs werd bekendgemaakt in GitHub Agentic Workflows. Een aanvaller verstopt een instructie in gewoon Engels in een publieke GitHub Issue; wanneer een AI-agent met standaard leesrechten op de repositories van de organisatie die Issue verwerkt, volgt hij de verborgen instructies en plaatst privérepositorygegevens als publieke reactie terug. Er zijn geen inloggegevens, malware of programmeervaardigheden nodig. Organisaties die AI-databeschermingsstrategieën evalueren, moeten dit zien als representatief voor een bredere risicoklasse, niet als een geïsoleerde GitHub-bug. Een risicobeoordeling die het huidige toegangsbereik van elke AI-agent afzet tegen zijn toegewezen taken is de basisstap – organisaties die dit niet hebben gedaan, kunnen bij een regelgevingsonderzoek of meldingsplicht aan klanten niet accuraat beantwoorden “wat konden onze agents bereiken?”.
De onderzoekers van Noma ontdekten dat het vooraf laten gaan van de geïnjecteerde instructie met het woord “Additionally” het model ertoe bracht de overname te zien als een legitieme vervolginstructie in plaats van een opdracht om te weigeren. Prompt-level filters werken op formulering, en formulering is eindeloos te variëren – een filter dat vandaag op een bepaalde bewoording is afgestemd, mist morgen een synoniem. Daarom zijn zero trust-architectuur-principes, die ervan uitgaan dat elk verzoek vijandig kan zijn ongeacht de formulering, belangrijker dan betere detectie van bewoordingen. Gegevensclassificatie toegepast op de inhoud die een agent kan ophalen, voorkomt niet dat de injectie plaatsvindt, maar beperkt wel welke geclassificeerde assets binnen de impact vallen – een agent die alleen publieke content kan bereiken, kan geen vertrouwelijke broncode exfiltreren, ongeacht de instructies die hij ontvangt.
Het is geen uitzondering. Het GenAI Security Project van OWASP koppelt prompt-injectie aan zes van de tien categorieën in de Top 10 voor Agentic Applications en noemt het de belangrijkste oorzaak van beveiligingsproblemen met agentic AI die momenteel in productie worden gezien, volgens Help Net Security (juni 2026) over de bevindingen van de groep. Het State of AI Agent Security 2026 rapport van Gravitee vond daarnaast dat 88% van de organisaties met AI-agents in productie het afgelopen jaar een gerelateerd beveiligingsincident bevestigde of vermoedde, wat de reden is dat AI-databeschermingsprogramma’s prompt-injectie niet langer als uitzondering mogen behandelen. Organisaties die onderworpen zijn aan regelgeving – HIPAA, CMMC, GDPR – moeten de OWASP prompt-injectiebevinding behandelen als een gedocumenteerd risico dat hun AI-governanceprogramma’s moeten adresseren, niet als een leveranciersspecifieke bug die kan worden uitgesteld tot er een patch is.
Beperk voor elke agent de toegang tot de specifieke taak die hij uitvoert, in plaats van permanente, organisatiebrede rechten te geven. Isoleer de inloggegevens die een agent gebruikt van de context van het taalmodel, zodat een overgenomen agent deze niet kan bemachtigen. Dwing RBAC- en ABAC-beleidsbeslissingen af op het dataniveau voor elk verzoek, los van wat de agent beweert dat zijn intentie is, en houd volledige audittrails bij van wat elke agent heeft geraadpleegd en uitgevoerd. Dit is het model achter Kiteworks Compliant AI en de Kiteworks Secure MCP Server. Organisaties moeten ook een incidentresponsplan documenteren dat specifiek het scenario “AI-agent plaatste privédata publiekelijk” dekt – de meldingsklok, scopebepaling en communicatiestappen moeten vooraf zijn vastgelegd, niet tijdens het incident.
Het State of Non-Human Identity and AI Security onderzoeksrapport van de Cloud Security Alliance toont aan dat minder dan één op de vier organisaties gedocumenteerd, formeel beleid heeft voor het aanmaken of uitfaseren van AI-identiteiten, en slechts 12% geeft aan veel vertrouwen te hebben in hun vermogen om een aanval via een niet-menselijke identiteit te voorkomen. Meer dan 16% houdt het aanmaken van nieuwe AI-gerelateerde identiteiten helemaal niet bij, waardoor een groeiende populatie agents feitelijk onzichtbaar blijft voor gegevensbeheer-programma’s die zijn ontworpen voor menselijke accounts. Organisaties moeten hun risicobeheerpraktijken voor toeleveringsketens uitbreiden naar AI-agentidentiteiten die door derde partijen worden geleverd – een AI-agent van een leverancier die in jouw GitHub-organisatie draait met brede permanente rechten is een supply chain-risico dat de meeste huidige leveranciersgovernancekaders niet expliciet adresseren.
Aanvullende bronnen
- Blog Post
Zero‑Trust-strategieën voor betaalbare AI-privacybescherming - Blog Post
Hoe 77% van de organisaties faalt op het gebied van AI-databeveiliging - eBook
AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025 - Blog Post
Er bestaat geen “–dangerously-skip-permissions” voor jouw data - Blog Post
Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.