AI-ontwikkelomgevingen worden steeds slimmer: ze lezen context uit projecten, gebruiken tools en voeren stappen uit binnen één workflow. Precies daardoor kan een nieuwe klasse beveiligingsproblemen ontstaan. Recent onderzoek toont aan dat prompt injection Kiro in Amazon Kiro IDE kan leiden tot datadiefstal via exfiltratie van gevoelige lokale informatie, zonder dat de aanvaller per se een “kwaardige prompt” hoeft in te dienen.
De onderzoekers beschrijven een gebrek zonder CVE-identificatie en plaatsen dit in Kiro IDE 0.7.45 op Windows. Inmiddels is er een oplossing toegepast in een later versienummer. Hieronder leggen we uit hoe het mechanisme werkt, aan welke voorwaarden een aanval gebonden is en welke lessen je als organisatie kunt meenemen voor veilige AI-ontwikkeling.
Wat is prompt injection Kiro precies?
Bij prompt injection Kiro probeert een aanvaller de instructies die een AI-agent “begrijpt” te beïnvloeden met behulp van inhoud die uit het project zelf komt. In plaats van alleen te mikken op een tekstprompt van een gebruiker, wordt de agent gestuurd via repository-inhoud die als instructie kan worden geïnterpreteerd.
In dit geval gaat het om Kiro, een agentic IDE met AI-functionaliteit. Volgens Mindguard kon aanvaller-gecontroleerde projectinhoud de Kiro-agent beïnvloeden en vervolgens ervoor zorgen dat gevoelige lokale informatie naar een extern eindpunt werd gestuurd.
Hoe werkt de kwetsbaarheid in Kiro IDE?
De kern van het probleem is dat Kiro verschillende onderdelen in de IDE met elkaar verbindt: projectcontext, agentbeslissingen en acties die configuratie en netwerkactiviteit kunnen triggeren. Mindguard beschrijft een keten waarin de “trust boundary” tussen onbetrouwde projectdata en beveiligingsgevoelige IDE-operaties faalt.
Concreet beschrijft het rapport een sequentie die neerkomt op:
- repository-inhoud (door de aanvaller) wordt geïnterpreteerd als instructies;
- die instructies sturen de agent;
- de agent leest gevoelige informatie uit de lokale workspace;
- de agent schrijft die informatie in security-relevante IDE-configuratie;
- een daaropvolgende IDE-capabiliteit zet die aangepaste configuratie om in netwerkactiviteit richting het internet.
Belangrijk: het rapport benadrukt dat de gebruiker niet expliciet een verzoek hoeft te doen zoals “Kiro toegang geven tot mijn data”. Met andere woorden: zodra de kwetsbare flow op gang komt, kan exfiltratie plaatsvinden zonder dat de gebruiker dit nadrukkelijk heeft gevraagd.
Wat is Kiro Powers en waarom is dat relevant?
Kiro Powers gaat verder dan alleen “skills”. Volgens de melding wordt Kiro Powers gekoppeld aan configuraties rond Model Context Protocol (MCP)-servers, inclusief besturing via stuur-/routingbestanden zoals een POWER.md-bestand. Daarnaast kunnen er hooks en context-kennis worden meegegeven.
Het stuur-/steering-bestand fungeert als een soort “onboarding manual” voor de agent: het legt persistent context vast en beschrijft welke MCP-tools beschikbaar zijn en wanneer die moeten worden gebruikt. Als een aanvaller juist díe context kan beïnvloeden via projectinhoud, ontstaat een route naar datalekken.
Welke voorwaarden zijn nodig voor een succesvolle aanval?
Volgens Mindguard is de exploit niet volledig “plug-and-play”. Er zijn twee gebruikersacties nodig:
- de gebruiker opent het malafide project via een workspace-bestand via File → Open Workspace From File, in plaats van direct de map te openen;
- daarna moet de gebruiker een bericht naar de agent sturen.
De onderzoekers geven aan dat de uitkomst reproduceerbaar is voor zowel vertrouwde als ontrouwde workspaces. De moeilijkheidsgraad is beoordeeld als laag, wat het extra urgent maakt: zodra de juiste projectopening en de “send message”-stap zijn gezet, kan het kwetsbare proces in gang worden gezet.
Waarom is dit breder dan één IDE?
Dit incident past in een bredere trend: AI-ontwikkeltools combineren steeds vaker interpretatie (begrijpen van context) én uitvoering (best actions) in dezelfde keten. In zo’n omgeving kunnen repositorybestanden context leveren voor een model, terwijl de agent ook bestanden kan lezen, tools kan aanroepen en andere functionaliteit binnen de applicatie kan activeren.
Mindguard stelt daarbij dat AI-kwetsbaarheden lastig te beoordelen zijn wanneer disclosure-processen vooral zijn ingericht op “duidelijk afgebakende” softwarefouten. Hier ontstaan problemen uit interacties tussen modelinterpretatie, applicatielogica, tools, configuratie en externe bronnen.
Met andere woorden: ook als het gaat om Kiro, is het veiligheidsvraagstuk fundamenteler. Het gaat om de vraag hoe onbetrouwbare input doorwerkt in systeemacties.
Vergelijking met eerdere Kiro-issues
Dit is niet de eerste keer dat onderzoekers problemen bij Kiro aankaarten. Mindguard verwijst naar een eerder gerapporteerde bug waarbij steering-file directives konden zorgen dat lokale informatie werd opgenomen in een Markdown-afbeeldingsverzoek en daarna werd verzonden naar een externe server.
Volgens de eerder gemelde techniek kon een aanvaller de steering-file zo vormgeven dat een lokaal bestand werd gelezen en vervolgens als Markdown-image-rendering in een verzoek belandde. De onderliggende les is vergelijkbaar: contextbestanden kunnen misbruikt worden om vertrouwensgrenzen te doorbreken.
Wat is er opgelost en welke versie is veilig?
Na responsible disclosure heeft Amazon een fix doorgevoerd. De melding noemt dat de kwetsbaarheid is aangepakt in Kiro IDE versie 0.8.140. Dat betekent voor teams: controleer of ontwikkelwerkplekken en CI-achtige omgevingen up-to-date zijn, en voorkom dat developers blijven werken met kwetsbare releases.
Daarnaast wordt ook een eerdere access control kwestie genoemd die in juni 2026 is verholpen. Daarbij ging het om onvoldoende toegangsbeperkingen die in een specifiek scenario konden leiden tot het uitvoeren van commando’s via aangepaste instructies en auto-execution op folder open. Die context maakt duidelijk hoe belangrijk het is om niet alleen op één bug te focussen, maar op het patroon van “projectcontext → configuratie → uitvoering”.
Praktische maatregelen voor veilige AI-ontwikkeling
Wat kun je vandaag al doen, ook als je niet precies dezelfde Kiro-instelling gebruikt? Hieronder staan maatregelen die aansluiten op de beschreven aanvalsketen.
1) Beperk blootstelling aan onbetrouwbare workspaces
Omdat de aanval begint bij een specifieke manier van openen (workspace via “Open Workspace From File”), is het verstandig om streng te zijn op welke projecten en workspace-bestanden developers lokaal openen. Zorg dat je beleid en training hierop aansluiten.
2) Houd AI-tools up-to-date
De fix in 0.8.140 is een directe aanwijzing dat patchmanagement voor AI-IDE’s geen bijzaak is. Stel een proces in om versies actief te monitoren en updates snel uit te rollen.
3) Segmentatie en monitoring op IDE-activiteiten
De beschreven keten eindigt in netwerkactiviteit. Daardoor is het zinvol om uitgaand verkeer, wijzigingen in relevante configuratiebestanden en verdachte tool-acties rond AI-agents te monitoren. Richt je niet alleen op malware-signatures, maar ook op “gedragsafwijkingen” die passen bij exfiltratie.
4) Kijk ook naar supply chain risico’s voor projectcontent
Deze kwetsbaarheid laat zien dat repository-inhoud meer kan doen dan code weergeven: het kan context en instructies aanleveren. Combineer dit met je bestaande supply chain security aanpak voor dependencies, scripts en projectbestanden.
Als je wilt doorpakken op het bredere thema rondom aanvallen waarbij projectcontent en vertrouwensgrenzen centraal staan, dan passen deze onderwerpen goed bij je roadmap: TeamPCP-arrestaties: supply chain en credentials en Foreign backdoors en de Amerikaanse stroomketen.
Wat betekent dit voor je security team?
Voor security operations draait de vraag om detecteerbaarheid en responstijd. Als een AI-agent gevoelige lokale data kan doorgeven via configuratie en tool-chains, dan moet je team begrijpen welke acties in jouw omgeving “hoog risico” zijn.
Daarnaast is het nuttig om je incidentrespons te oefenen op scenario’s waarin de gebruiker geen expliciete “toestemming om te exfiltreren” geeft. De melding benadrukt dat exfiltratie kan plaatsvinden zonder dat een gebruiker Kiro expliciet vraagt om toegang of verzending. Dat vraagt om controles op context en dataflows, niet alleen op gebruikersopties.
Wil je dit verder vertalen naar operationele AI-beveiliging? Lees dan ook Security operations klaar voor AI-aanvallen, waarin het belang van voorbereiding en datagedreven aanpakken wordt uitgewerkt.
Conclusie
De onderzoekers maken aannemelijk dat prompt injection Kiro in Amazon Kiro IDE kan leiden tot het uitlekken van gevoelige lokale informatie via een keten die start bij projectinhoud en eindigt bij netwerkactiviteit. De aanval vraagt om specifieke gebruikersacties (zoals het openen van een workspace via File → Open Workspace From File) en een bericht aan de agent, maar de exploit wordt wel als relatief eenvoudig beoordeeld.
De praktische boodschap is helder: werk AI-ontwikkeltools consequent bij, stel beleid op voor het openen van onbetrouwbare workspaces en versterk monitoring op dataflows en IDE-gedrag. Zo voorkom je dat context uit een repository doorsijpelt naar uitvoering en exfiltratie.
Bron: https://thehackernews.com/2026/08/amazon-kiro-prompt-injection-can.html
