Google heeft drie ADK AI-workflows verwijderd uit de Agent Development Kit (ADK) Python repository. Aanleiding was een beveiligingsprobleem dat door Pillar Security is onderzocht: een public GitHub-issue bleek een triage-agent te kunnen manipuleren, waardoor een agent met hogere rechten gestart werd.
Belangrijk detail: Google stelde dat het ging om misbruik binnen de automatisering van de repository, niet om een kwetsbaarheid in een distributie van de ADK-bibliotheek zelf. Toch laat de casus scherp zien hoe snel “vertrouwde” AI-automatisering kan doorslaan als autorisatie niet goed is afgebakend.
Wat Google verwijderde: drie AI-workflows uit ADK
Volgens het bericht van The Hacker News haalde Google issue-analyze.yml, issue-fix.yml en pr-analyze.yml weg. Deze workflows waren onderdeel van de repository-automatisering en verwerkten ongeteste input uit issues en pull requests.
De verwijdering gebeurde in een patch waarvan de metadata een author date van 9 juni 2026 draagt. Pillar Security controleerde later dat de workflows inderdaad niet meer aanwezig waren, en Google bevestigde dat het probleem op 21 juli was opgelost.
De kern van het misbruik: prompt-injection naar een privileged agent
Pillar beschrijft een aanvalspad waarbij een openbare GitHub-issue de triage-agent kon sturen naar een commando dat normaal gesproken alleen vanuit een vertrouwde context geactiveerd mocht worden.
Concreet: de publieke agent kon worden prompt-injected zodat hij een reactie plaatste in de vorm van /adk-issue-fix, alsof die kwam van adk-bot. Dat werkte omdat de bot-identity werd herkend als een collaborator.
Daarmee werd de “authenticatiebrug” gevormd: het systeem keek niet naar de herkomst van de inhoud op een manier die manipulatie uitsloot, maar naar wie het commando plaatste—en dat was in de proof-of-concept dus de bot.
Van triage naar code-fixing: waarom de gate faalde
De workflow issue-fix.yml luisterde naar opmerkingen met het commando /adk-issue-fix. Execution werd vervolgens beperkt tot commentatoren die een bepaalde rol hadden (owner, member of collaborator).
Het probleem zat in de implementatie van de gate: de controle beperkte vooral wie de opdrachtpost plaatste, niet of die post via een manipulatie van een vertrouwde agent tot stand was gekomen. Anders gezegd: de gate herkende de “trusted bot”, maar kon niet voorkomen dat het commando zelf door prompt-injection was gegenereerd.
CI-uitvoering en uitlek van tokens in de proof-of-concept
Pillar demonstreerde in een gecontroleerde omgeving dat er sprake kon zijn van willekeurige code-uitvoering op de CI-runner. Daarnaast beschrijft de publicatie dat een personal access token (PAT) van de bot kon worden geëxfiltreerd.
De privileged job had bovendien toegang tot gevoelige geheimen zoals:
- een Google API key
- een Google Cloud service-account credential
In de onderzoekersanalyse staat ook dat de PoC niet aantoont dat er in het wild al misbruik is gemaakt, of dat een gepubliceerde ADK-release gecompromitteerd is geweest.
Google wees er daarnaast op dat de kwetsbare component volgens Pillar in de repository automation zat. Met andere woorden: niet in de gedeelde ADK Python package, maar in de manier waarop GitHub-workflows met credentials en AI-agenten samenwerkten.
Waar begon de aanval: issue-analyze.yml als startpunt
Het aanvalspad startte bij issue-analyze.yml. Deze workflow draait automatisch zodra er een issue wordt geopend. In de beschreven keten:
- de workflow gebruikte ADK_GCP_SA_KEY (service account key)
- ze leverde ADK_TRIAGE_AGENT en GOOGLE_API_KEY aan een “Antigravity coding agent”
- de generated analyse werd als comment geplaatst met het botaccount
Een aparte workflow issue-fix.yml reageerde vervolgens op commando’s in die opmerkingen.
Waarom “GITHUB_TOKEN” vs “werkelijke PAT” tot verwarring leidde
Volgens het verslag verklaarde de privileged job write-toegang voor issues, repository contents en pull requests. Daarbij wordt vaak gedacht aan de standaard GitHub-inzet GITHUB_TOKEN—maar de beschrijving stelt dat de job daadwerkelijk een andere token gebruikte, namelijk ADK_TRIAGE_AGENT PAT.
Met andere woorden: de geconfigureerde permissies in de job betroffen niet noodzakelijk de token waarmee de agent uiteindelijk werkte. Dat maakt het lastig om op basis van workflow-permissies alleen te bepalen welke impact een misbruikscenario kan hebben.
Scopes van tokens waren niet publiek: wel een duidelijk misbruikmodel
Pillar vermeldt dat de exacte scopes van de PAT niet publiek beschikbaar waren. Wel wordt beschreven dat de job het repository-deel check-outte met de PAT, vervolgens authenticatie richting Google Cloud uitvoerde en de agent met zowel de PAT als de API key in een environment liet draaien.
De workflow was ontworpen om code te bewerken, een adk-bot fork te maken, een branch te pushen en vervolgens een pull request te openen.
Dat laat zien dat het systeem in staat was om wijzigingen aan te brengen namens de automation. Een botgegenereerde pull request (met een datum van 4 juni) werd als indicatie genoemd dat de automatisering daadwerkelijk actief was.
Command allowlists waren niet genoeg: hooks en capabilities maakten het mogelijk
De CI-runner implementeerde beperkingen: shell metacharacters zouden geweigerd worden en er werden alleen commands toegestaan waarvan het eerste token gh of git
Maar Pillar laat zien dat die syntactische allowlist geen volledige bescherming bood. Er werd namelijk een mogelijkheid beschreven waarbij de agent via de SDK CapabilitiesConfig() “alle tools” kon inschakelen, inclusief tools die schrijven mogelijk maken.
Daarnaast is het relevant dat Git ondersteunt dat hooks uitvoerbare programma’s kunnen zijn. Met core.hooksPath kan Git worden omgeleid naar een directory met eigen hook-executable’s. Hierdoor bleef er een route bestaan naar code-uitvoering, zelfs als alleen bepaalde commandvormen door de check kwamen.
Wat zegt dit over echte exploits? Nog niet hard bewezen
In de publicatie staat ook dat publieke artifacts niet definitief aantonen of de PAT direct naar de main-branch kon pushen. Pillar beschrijft dat Google had aangegeven dat de service account Vertex AI-toegang had in een specifiek GitHub-management project, maar bredere permissies werden niet openbaar gemaakt.
Daarmee is het misbruikmodel wel concreet aangetoond voor de omgeving van de onderzoekers, maar de downstream impact (bijvoorbeeld exacte repository- en cloud-reach) blijft in de openbare informatie onduidelijk.
Aanbevelingen: bots scheiden, scopes versmallen en AI-input niet als autorisatiesignaal behandelen
Google bevestigt niet alleen het verwijderen van workflows, Pillar doet ook aanbevelingen voor vergelijkbare omgevingen. De belangrijkste punten:
- Gebruik aparte bot-identiteiten voor verschillende rollen en stappen (triage versus fix).
- Beperk token- en tool-scope tot precies wat nodig is.
- Gebruik een autorisatiesignaal dat door onbetrouwbare tekst (zoals door AI gegenereerde prompt-injected input) niet kan worden nagebootst.
Deze lessen passen naadloos bij een breder thema in software supply chain security: automatisering moet minder “trust” inbouwen dan je denkt, vooral wanneer AI-agenten content kunnen produceren die downstream flows activeren.
Vergelijkbare risico’s in AI- en security-automatisering
Als je kijkt naar andere incidenten rond AI-workflows, dan zie je hetzelfde patroon terug: de kwetsbaarheid zit vaak niet in één “bug”, maar in de keten die van input naar uitvoering leidt. Het gaat dan om governance, autorisatie en het voorkomen van onbedoelde escalatie.
Daarom is het ook zinvol om te lezen hoe onderzoekers naar AI-agent governance kijken, bijvoorbeeld in AI-agent governance met Obsidian Security. En als je geïnteresseerd bent in hoe supply chain-aanvallen via tooling juist wél werken, zie ook malafide npm-pakketten via supply chain.
Conclusie: verwijdering is een begin, maar ontwerp moet opnieuw
Het verwijderen van de ADK AI-workflows is een duidelijke stap: Google reageerde op bewijs dat publieke input via GitHub-automatisering de activering van privileged code-fixing kon beïnvloeden. De casus laat tegelijk zien waarom “wie plaatste het commando?” alleen niet genoeg is wanneer een AI-agent dat commando genereert onder invloed van manipulatie.
Voor teams die AI-automation gebruiken in CI/CD en repository workflows is dit een waarschuwing. Zorg voor gescheiden bot-identiteiten, minimale scopes en autorisatie die niet te herleiden is tot door onbetrouwbare tekst gevormde signals. Alleen zo voorkom je dat triage verandert in controleverlies.
Bron: https://thehackernews.com/2026/08/google-deletes-3-adk-ai-workflows-after.html
