Gemini agent-to-agent: prompt przekroczył granicę uprawnień w CI/CD

Pillar Security ujawnił podatny wzorzec automatyzacji w repozytorium Google Agent Development Kit dla Pythona. Publicznie dostępny agent do obsługi zgłoszeń mógł przekazać przygotowaną przez użytkownika instrukcję do bardziej uprzywilejowanego workflow Gemini. W efekcie dane z niezaufanego pull requesta stawały się sterowaniem dla agenta mającego narzędzia MCP, dostęp do powłoki i token GitHub.

Google utwardziło automatyzację po zgłoszeniu, a późniejszy, osobny problem poprawiło pod koniec lipca. Incydent jest jednak ważniejszy niż jedno repozytorium: pokazuje, że handoff między agentami jest wywołaniem przez granicę zaufania, a nie zwykłą rozmową dwóch modeli.

Jak powstała ścieżka eskalacji

Opis Pillar Security rozróżniał dwa poziomy automatyzacji. Agent triage przyjmował treści od użytkowników i komentował pull requesty z uprawnieniami Collaborator. Inne workflow, wywoływane poleceniem @gemini-cli, miały dostęp tylko dla maintainerów i znacznie silniejsze narzędzia.

Badacz skłonił pierwszy agent do umieszczenia specjalnego komentarza, który uruchomił gemini-invoke. Odpowiedź ujawniła zestaw narzędzi oferowanych uprzywilejowanemu agentowi przez MCP, w tym możliwość wykonywania poleceń bash. To otwierało drogę do odczytu sekretów środowiska i tokena GitHub.

Według badacza uzyskane uprawnienia pozwalały modyfikować komentarze, issues i pull requesty, odrzucać recenzje, inicjować kolejne przeglądy oraz tworzyć wiarygodną, lecz fałszywą historię zatwierdzenia zmian. Złośliwy PR nadal wymagał scalenia przez człowieka, więc część scenariusza zależała od socjotechniki. To ogranicza skuteczność, ale nie usuwa naruszenia granicy uprawnień.

Pillar znalazł później drugi problem w automatyzacji opartej na Antigravity SDK, który mógł prowadzić do wykonania kodu bez interakcji maintainera. Google poprawiło go pod koniec lipca.

Model nie jest mechanizmem autoryzacji

Architektura popełnia błąd, gdy zakłada, że agent sam rozpozna „bezpieczną intencję” przekazanej wiadomości. LLM przetwarza tekst jako kontekst; nie zapewnia właściwości referencyjnego monitora. Jeśli niskouprzywilejowany agent może wygenerować format aktywujący workflow o wysokich prawach, poziom zaufania danych zmienia się bez kryptograficznego lub programowego dowodu.

To odpowiednik klasycznego confused deputy. Uprzywilejowany komponent wykonuje operację w imieniu źródła, którego sam nie powinien ufać. MCP i tool calling zwiększają konsekwencje, bo odpowiedź modelu może stać się poleceniem dla powłoki, repozytorium lub chmury.

Bezpieczny wzorzec dla agentów CI/CD

• Nie pozwalaj, aby tekst wygenerowany przez publicznego agenta sam w sobie uruchamiał uprzywilejowane workflow.
• Przenoś tożsamość i poziom zaufania źródła jako niezmienne metadane poza promptem.
• Stosuj osobne tokeny z minimalnym zakresem dla triage, review, etykiet i scalenia; żaden agent nie powinien mieć „każdego polecenia bash”.
• Waliduj dozwolone akcje deterministycznym kodem i policy engine po odpowiedzi modelu.
• Wymagaj świeżej, jawnej zgody człowieka dla zmian kodu, sekretów i publikacji — nie zatwierdzenia odtworzonego z komentarza.
• Izoluj runner, ogranicz sieć i montowanie sekretów, a token wydawaj tuż przed konkretną akcją.
• Loguj pochodzenie każdego handoffu, promptu, narzędzia i decyzji; historia musi być odporna na edycję przez agenta.
• Testuj pośrednie prompt injection w issues, commitach, nazwach gałęzi, logach i wynikach narzędzi.

Praktyczne wzorce opisujemy w sandboxie dla agentów AI oraz przewodniku po bezpieczeństwie MCP.

Fakty źródłowe a wnioski Breachroad

Pillar Security opisuje demonstrację w repozytorium ADK, zakres uzyskanych możliwości i odpowiedzialne zgłoszenie. SecurityWeek relacjonuje, że Google utwardziło pierwszy mechanizm i poprawiło drugi problem. Publiczne źródła nie wskazują na wykorzystanie tego łańcucha do złośliwego scalenia kodu.

Wnioskiem Breachroad jest traktowanie każdego agent-to-agent handoffu jak wywołania API z obowiązkową autoryzacją. Szkolenia z bezpiecznego AI pomagają projektować te granice, a AI red teaming może sprawdzić pośrednie prompty, narzędzia, tokeny i ścieżki eskalacji przed wdrożeniem.