AI-agenten die samen taken uitvoeren, maken ontwikkeling sneller. Maar die samenwerking brengt ook nieuwe aanvalsroutes met zich mee. Pillar Security beschrijft een agent-tot-agent aanval in Google’s Agent Development Kit (ADK) voor Python, waarbij een laag-geprivilegieerde agent uiteindelijk geautoriseerde acties van een hoger geprivilegieerde agent kon overnemen.
Concreet kon een aanvaller met slimme promptsturing een bot-actie laten escaleren naar een workflow met verregaande rechten. Dat leidde niet alleen tot het uitlekken van de beschikbare tooling, maar ook tot het vergiftigen van de pull request (PR) goedkeurings- en beoordelingsketen. In sommige scenario’s kon dat de deur openen naar bredere compromittering van de software supply chain.
Wat is er aan de hand in Gemini ADK?
In de google/adk-python repository werkten twee typen geautomatiseerde AI-agenten. Er waren laag-geprivilegieerde agenten die interactie met gebruikers toelieten. Daarnaast waren er hoog-geprivilegieerde agenten die alleen toegankelijk waren voor maintainers.
Het probleem zat in hoe prompt-informatie van de ene agent naar de andere kon doorsijpelen. Pillar’s onderzoekers laten zien dat je, door de public-facing (laag-geprivilegieerde) agent te manipuleren, de hoog-geprivilegieerde agent kon laten deelnemen aan taken waarvoor die eigenlijk niet bedoeld was.
Van PR-triage naar hoge privileges
De eerste aanwijzing kwam van een agent die pull requests moest triagen. Die bot reageerde op PR’s als Collaborator—een rol met hoge privileges op de repository.
Daarna vond de onderzoeker een manier om de triage-agent te misleiden. Door een specifieke output-vorm te forceren, kon er een comment op een PR worden geplaatst met daarin een verwijzing naar @gemini-cli gevolgd door een prompt. Die comment activeerde de gemini-invoke workflow.
Dat was het kantelpunt: de geactiveerde workflow had toegang tot een set van tooling die normaal gesproken beperkt zou moeten blijven tot maintainers.
Uitlekken van tools en command execution
De prompt die werd geplaatst in de PR-comment triggerde een reactie van het gemini_invoke.yml workflowgedeelte. In die stap lekte de bot informatie over de tools die de geprivilegieerde agent via een MCP server kon gebruiken.
Volgens de bevindingen bleek dat de bot toegang had tot alle bash-commando’s. Daarmee kon de onderzoeker code remote uitvoeren. Een logisch gevolg was dat ook een GitHub-token in beeld kon komen—de onderzoekers beschrijven dat de code-activiteit mogelijk leidde tot het verkrijgen of benutten van het token waarmee de agent namens zichzelf acties kon uitvoeren.
Wat kon er met die toegang worden gedaan?
Met die escalatie kon de onderzoeker acties uitvoeren die veel verder gingen dan enkel reageren op een PR. De beschreven mogelijkheden omvatten het aanpassen van opmerkingen, PR’s en issues van andere maintainers, collaborators en leden.
Daarnaast kon de aanvaller het beoordelingsproces beïnvloeden: reviews konden worden weggeduwd of wijzigingen konden worden goedgekeurd. Ook kon de geactiveerde keten worden gebruikt om opnieuw geautomatiseerde stappen uit te voeren, zoals gemini-invoke en gemini-review, gericht op andere PR’s.
De onderzoekers benadrukken ook dat het vergiftigen van de PR-approval-lifecycle niet automatisch betekende dat elke schadelijke PR ook direct gemerged zou worden. Een member moest uiteindelijk de boze PR beoordelen en samenvoegen. In de praktijk is dat vaak waar sociale manipulatie binnenkomt.
Waarom sociale engineering zo’n grote rol speelt
Het scenario zoals Pillar het schetst vereist dat een aanvaller eerst vertrouwen opbouwt als collaborator. Vervolgens moet die een PR indienen met kwaadwillende code en deze laten markeren voor beoordeling.
Daarna draait het om een tweede PR met prompts die de agent in staat stellen de status van de eerste PR te laten verschijnen als “triaged”, “reviewed” en “approved”. De aanval bouwt dus een overtuigend spoor dat lijkt op een normale afhandeling—terwijl de echte menselijke review of automatische evaluatie in werkelijkheid nooit op die manier heeft plaatsgevonden.
Een belangrijk detail is hoe de keten de audit-achtige handelingen “nabootst”. De onderzoeker beschrijft dat het editten van triage-reacties aansluit op rechten uit issue-verwerking, terwijl het plaatsen en goedkeuren via botgedrag valt onder PR-specifieke rechten. Door al die stappen aan elkaar te koppelen ontstaat een coherent verhaal dat ‘correct’ oogt voor wie het traject bekijkt.
Hoe werd dit gemeld en opgelost?
Pillar meldde de bevindingen begin juni aan Google. Google heeft vervolgens een oplossing doorgevoerd in de vorm van hardening.
Google zag volgens de rapportage geen basis om dit als bug bounty-waardig te kwalificeren. De reden is dat het uiteindelijke schadelijke effect in het beschreven scenario afhankelijke is van sociale engineering: een aanvaller moet de boze PR via menselijke goedkeuring toch het laatste stadium in krijgen.
Nieuwe kwetsbaarheid in dezelfde repository
Na de eerste ontdekking vond Pillar een tweede issue in dezelfde ADK-omgeving. Deze keer lag de focus op automation features in een agent die is gebaseerd op een Antigravity-SDK.
Ook deze zwakte kon leiden tot remote code execution, maar dan zonder dat een maintainer interactie moest uitvoeren. Google heeft de tweede kwetsbaarheid—volgens de beschikbare informatie—eind juli verholpen.
Waarom dit relevant is voor software supply chain security
De kern van de les zit niet alleen in een enkele bug, maar in de combinatie van factoren: geautomatiseerde agenten, acties op repository-niveau, workflow-triggers en een keten van rechten die zich laat misbruiken via promptsturing.
Voor teams die AI-agents inzetten in ontwikkelpijplijnen (zoals triage, review of release-automatisering) is dit een waarschuwing om te kijken naar:
- Welke agenten welke workflows mogen activeren.
- Of geprivilegieerde acties voldoende zijn afgeschermd tegen input van public-facing componenten.
- Hoe audit trails, labels en review-stappen worden gegenereerd—en of een “geloofwaardige” workflow ook echt betrouwbaar is.
- Welke tokens beschikbaar zijn wanneer code execution mogelijk wordt.
Als je breder wilt lezen over de risico’s rond kwetsbaarheden die ketencomponenten of CI/CD-achtige processen raken, is ook dit artikel relevant: malafide npm-pakketten via supply chain: RAT-alert.
En omdat PR- en repository-processen in de praktijk vaak met bots, autorisaties en workflowrechten werken, helpt het om je eigen proces vergelijkbaar te beoordelen. Ook bij andere platformkwetsbaarheden draait het immers steeds vaker om het misbruiken van geautoriseerde paden.
Praktische aandachtspunten voor je eigen agent-automatisering
Heb je agenten die PR’s triagen of reviews klaarzetten? Dan is het verstandig om je inrichting kritisch te bekijken, zonder te wachten op het volgende publieke rapport.
Beperk workflow-toegang
Laat public-facing agenten niet rechtstreeks workflows triggeren met dezelfde rechten als maintainers. Overweeg een scheiding tussen “signaleren” en “actie uitvoeren”.
Voorkom dat promptoutput tooling kan activeren
Als agenten output genereren die workflowinputs kan vormen (zoals command-aanroepen of CLI-achtige triggers), behandel die output als onbetrouwbaar. Stel strikte validatieregels in.
Controleer tokens en privileges
Onderzoek welke tokens beschikbaar zijn wanneer er iets misgaat. Minimaliseer rechten en zorg dat eventuele command execution niet leidt tot “alles mag”.
Maak PR-statussen controleerbaar
Als label- en reviewstatussen volledig via bots worden gezet, maak dan ook ruimte voor verificatie door mensen of door onafhankelijke signalen die niet alleen op botgedrag leunen.
Conclusie: agent-tot-agent aanval is een supply chain wake-up call
De beschreven agent-tot-agent aanval laat zien hoe een AI-agentarchitectuur die bedoeld is om ontwikkeling te versnellen, toch kan uitmonden in geheimen die blootkomen en in PR’s die worden vergiftigd. Door geprivilegieerde workflows te activeren via manipulatie van een public-facing agent, kon een onderzoeker tooling uitlekken en uiteindelijk code uitvoeren.
Hoewel het uiteindelijke scenario in de rapportage ook sociale engineering vereist, blijft de boodschap helder: wanneer agenten geautomatiseerd namens teams handelen, moet je hun rechten, workflow-koppelingen en betrouwbaarheid van PR-trails zorgvuldig ontwerpen en toetsen. Daarmee beperk je de kans dat een agentische keten verandert in een aanvalsketen.
