Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo agentów AI staje się jednym z najważniejszych zagadnień współczesnego DevSecOps. Opisany przypadek związany z Google Agent Development Kit for Python pokazuje, że nawet środowiska z pozornie poprawnym podziałem ról mogą zostać naruszone przez atak typu agent-to-agent, w którym mniej uprzywilejowany komponent staje się kanałem wpływu na bardziej zaufany proces automatyzacji.
To istotna zmiana perspektywy w bezpieczeństwie łańcucha dostaw oprogramowania. Zamiast klasycznego przejęcia pojedynczego systemu CI/CD, napastnik wykorzystuje relacje zaufania pomiędzy agentami AI, komentarzami w repozytorium i zautomatyzowanymi workflow.
W skrócie
- Badacze pokazali możliwość wykorzystania publicznie dostępnego agenta o niskich uprawnieniach do wpływania na uprzywilejowany workflow oparty na Gemini.
- Atak umożliwiał ujawnienie dostępnych narzędzi, wykonywanie poleceń powłoki oraz potencjalne pozyskanie tokena GitHub.
- Skutkiem mogła być manipulacja komentarzami, zgłoszeniami i przebiegiem recenzji pull requestów.
- Scenariusz tworzył realne ryzyko zatrucia procesu wytwarzania oprogramowania i naruszenia integralności repozytorium.
- Problem został zgłoszony i ograniczony poprzez dodatkowe zabezpieczenia oraz utwardzenie mechanizmów ochronnych.
Kontekst / historia
Incydent dotyczył repozytorium google/adk-python, w którym funkcjonowały co najmniej dwie klasy agentów AI. Pierwsza obejmowała agentów reagujących na publiczne interakcje użytkowników, a druga agentów dostępnych wyłącznie w bardziej zaufanym kontekście maintainerskim, wykonujących operacje o większej wadze dla projektu.
Kluczowe znaczenie miało ustalenie, że agent odpowiedzialny za triage pull requestów publikował komentarze z poziomu roli Collaborator. W praktyce oznaczało to powstanie pomostu między publiczną warstwą interakcji a workflow o wyższym poziomie zaufania. Taki model stworzył warunki do nadużycia automatyzacji bez konieczności bezpośredniego ataku na najbardziej uprzywilejowany komponent.
Dodatkowo badacze wskazali również na drugi problem związany z funkcjami automatyzacji opartymi na agencie wykorzystującym Antigravity-SDK. To sugeruje, że nie chodziło wyłącznie o pojedynczą konfigurację, ale o szerszą klasę zagrożeń wynikających z projektowania relacji zaufania w środowiskach agentowych.
Analiza techniczna
Techniczny rdzeń ataku opierał się na wykorzystaniu komentarzy do pull requestów jako nośnika instrukcji przekazywanych pomiędzy agentami. Badacz zdołał wpłynąć na agenta triage tak, aby opublikował komentarz zawierający polecenie w stylu komendy dla gemini-cli. Taki komentarz uruchamiał kolejne elementy łańcucha automatyzacji, w tym bardziej uprzywilejowany mechanizm gemini-invoke.
Po aktywacji uprzywilejowanego workflow możliwe było ujawnienie zestawu narzędzi dostępnych agentowi za pośrednictwem serwera MCP. Z punktu widzenia bezpieczeństwa był to moment krytyczny, ponieważ odsłaniał realne możliwości operacyjne bota i pozwalał ocenić zakres dalszej eskalacji.
Ujawnienie dostępu do poleceń bash oznaczało potencjalną możliwość zdalnego wykonywania kodu w kontekście automatyzacji CI/CD. Jednocześnie pojawiło się ryzyko przejęcia tokena GitHub lub innych wrażliwych danych dostępnych dla agenta. Jeśli taki token zostanie wykorzystany, napastnik może przejść od pojedynczej manipulacji do systematycznego wpływania na artefakty współpracy w repozytorium.
Po uzyskaniu odpowiedniego poziomu kontroli możliwe stawało się modyfikowanie komentarzy, operacje na issue i pull requestach, zmiana statusów recenzji, a także inicjowanie kolejnych workflow związanych z analizą kodu. Szczególnie niebezpieczne było to, że działania te mogły wyglądać jak legalne operacje wykonane przez autoryzowaną automatyzację.
W praktyce scenariusz zatruwania pull requestów wymagał jeszcze komponentu socjotechnicznego. Atakujący musiał zdobyć zaufanie jako collaborator, przygotować odpowiednio spreparowane zgłoszenia oraz doprowadzić do tego, by agent oznaczył wcześniej przygotowaną zmianę jako zweryfikowaną lub gotową do akceptacji. Ostateczne scalenie nadal wymagało człowieka, ale tor decyzyjny mógł zostać znacząco zmanipulowany.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją tego typu ataku jest naruszenie integralności procesu tworzenia oprogramowania. Jeśli agent AI bierze udział w triage, recenzji i zatwierdzaniu zmian, jego kompromitacja może doprowadzić do wprowadzenia złośliwego kodu przy zachowaniu pozorów zgodności z procedurami.
Drugie istotne ryzyko dotyczy ekspozycji sekretów. Tokeny GitHub, zmienne środowiskowe, uprawnienia workflow i narzędzia wykonawcze stanowią wyjątkowo cenny cel dla napastników. Nawet częściowy wyciek takich danych może umożliwić dalszą eskalację uprawnień, lateral movement pomiędzy repozytoriami albo podszywanie się pod legalne automatyzacje.
Trzecim problemem jest utrata wiarygodności logów i ścieżki audytowej. Jeśli bot może tworzyć komentarze, etykiety i recenzje wyglądające na autentyczne, organizacja może mieć trudność z odróżnieniem rzeczywistych decyzji maintainera od artefaktów wygenerowanych przez zmanipulowany workflow.
Rekomendacje
Organizacje wdrażające agentów AI w procesie SDLC powinny przede wszystkim wymusić twardą separację uprawnień między agentami publicznymi i uprzywilejowanymi. Agent analizujący dane wejściowe od użytkownika nie powinien mieć możliwości pośredniego uruchamiania workflow o wyższych uprawnieniach bez silnej walidacji kontekstu, autoryzacji i dodatkowych kontroli bezpieczeństwa.
Konieczne jest także ograniczenie uprawnień tokenów i workflow GitHub Actions zgodnie z zasadą najmniejszych uprawnień. Każdy proces powinien otrzymywać tylko te scope’y, które są niezbędne do wykonania konkretnego zadania. Warto wdrożyć krótkowieczne poświadczenia, izolację sekretów i blokadę dostępu do poleceń systemowych wszędzie tam, gdzie nie są one absolutnie wymagane.
Bardzo ważne jest również traktowanie komentarzy, opisów pull requestów, issue i innych artefaktów współpracy jako niezaufanego wejścia. Agenci AI analizujący takie treści powinni być chronieni przed prompt injection, command injection oraz ukrytą eskalacją pomiędzy workflow. Pomocne będą tu polityki sanitizacji promptów, allowlisty komend oraz ścisłe kontrole przekazywania kontekstu między agentami.
W środowiskach produkcyjnych warto rozdzielić agentów rekomendujących od agentów wykonawczych. Agent może proponować etykiety, priorytety czy wynik recenzji, ale operacje zmieniające stan repozytorium powinny wymagać zatwierdzenia przez człowieka lub odrębny, ściśle ograniczony komponent kontrolny.
Z perspektywy monitoringu należy rejestrować pełny łańcuch wywołań agentów, użyte prompty, transfer kontekstu oraz zestaw uruchamianych narzędzi. Anomalie, takie jak nietypowe wywołania CLI, podejrzane zmiany statusów recenzji wykonywane przez boty czy uruchamianie workflow na podstawie komentarzy, powinny generować alerty wysokiego priorytetu.
Podsumowanie
Przypadek związany z Gemini i Google ADK for Python pokazuje, że zagrożenia dla agentów AI nie wynikają wyłącznie z pojedynczych błędów implementacyjnych. Ich źródłem jest również sama architektura zaufania pomiędzy komponentami automatyzacji, która może umożliwić przejście od publicznej interakcji do wysoko uprzywilejowanych operacji w repozytorium.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że AI w DevOps musi być traktowane jak infrastruktura uprzywilejowana. Bez segmentacji, minimalnych uprawnień, odporności na wstrzyknięcia i pełnej obserwowalności agent AI może stać się nowym wektorem kompromitacji łańcucha dostaw oprogramowania.
Źródła
- https://www.securityweek.com/gemini-agent-to-agent-attack-exposed-secrets-enabled-pull-request-tampering/
- https://www.pillar.security/
- https://github.com/google/adk-python