GitLost nie oznacza, że dowolne prywatne repozytorium GitHub można ukraść przez publiczny issue. Pokazuje jednak groźną kombinację dla agentów AI: prywatne dane, niezaufane wejście i publiczny kanał wyjścia w jednym workflow.

Agent AI z granicą zaufania między publicznymi issues i prywatnymi repozytoriami

Noma Labs opublikowała GitLost 6 lipca. Celem były GitHub Agentic Workflows, funkcja w preview, która pozwala opisać automatyzację repozytorium w Markdownie i uruchomić agenta w GitHub Actions. GitHub opisuje read-only tokens domyślnie, sandboxing, safe outputs i skanowanie zagrożeń przed publikacją wyniku.

W PoC Noma publiczny issue nakierował agenta na odczyt treści z prywatnego repozytorium i publikację wyniku w publicznym komentarzu. Według Noma i The Hacker News atakujący nie potrzebował skradzionych credentials ani dostępu do private repo. Problemem była architektura: agent czytał publiczny input, miał szeroki read access do private repos i mógł odpowiedzieć publicznie.

Co się wydarzyło

Agentic Workflows zamieniają instrukcje w języku naturalnym na GitHub Actions przez gh-aw. Agent może triage'ować issues, analizować pull requests, badać CI failures albo przygotowywać maintenance work.

Produktowo to wygodne. Security widzi w tym service account z interfejsem językowym.

Workflow testowany przez Noma uruchamiał się po przypisaniu issue. Czytał title i body, a potem odpowiadał komentarzem. Miał też read access do innych repozytoriów organizacji. Issue wyglądał jak zwykła prośba biznesowa. Po uruchomieniu agent pobrał treść z publicznego i prywatnego repozytorium, a następnie wkleił ją do publicznego komentarza.

Dokładna treść testu nie jest potrzebna jako instrukcja. Ważna lekcja brzmi: filtr nie jest granicą bezpieczeństwa. Jeśli granica zależy od tego, czy model rozpozna podejrzaną prośbę, ta granica kiedyś pęknie.

Zakres jest warunkowy

GitLost wymaga kilku elementów: aktywnego agentic workflow, publicznego lub kontrolowanego przez atakującego inputu, tokena z dostępem do prywatnych repozytoriów i publicznego outputu. To nie jest uniwersalny wyciek z GitHuba.

Ale wiele firmowych workflow idzie w tę stronę. Agent czyta tickets, PRs, Sentry events, support messages albo comments. Zbiera wewnętrzny kontekst. Potem publikuje odpowiedź. Wartość powstaje z połączenia stref zaufania. Ryzyko też.

Read-only nie zawsze jest bezpieczne. Taki token nie zrobi push, ale może czytać wrażliwe informacje. Jeśli agent może pisać publicznie, sam odczyt wystarczy do exfiltration.

Lethal trifecta pasuje tutaj dokładnie

Simon Willison opisuje trzy elementy: private data, untrusted content i external communication. W GitLost prywatne dane to repozytorium, niezaufane wejście to publiczny issue, a publiczny komentarz jest kanałem wyjścia.

Usuń jeden element, a ryzyko spada. Publiczny issue bez dostępu do private repos jest mniej groźny. Prywatna analiza bez publicznego outputu trudniej prowadzi do wycieku. Bot piszący publiczne komentarze, ale bez private repo access, ma mniej do ujawnienia.

Co sprawdzić przed wdrożeniem

Zadaj trzy pytania: co agent może czytać, kto może pisać do jego contextu i gdzie agent może wysłać wynik.

Jeśli odpowiedzi brzmią private repositories, każdy autor public issue i public comment, zatrzymaj workflow. To nie jest zwykła automatyzacja, tylko możliwa ścieżka wycieku.

Stosuj tokens per repo albo per purpose zamiast broad org access. Oddziel agentów public-facing od private-facing. Agent odpowiadający na public issues nie powinien być tym samym aktorem, który czyta wrażliwe repozytoria.

Wynik oparty na private data powinien zostać w prywatnym kanale. Wyjście na zewnątrz wymaga review, approval i logów: trigger issue, przeczytane repozytoria, użyty token, proponowany output, osoba zatwierdzająca.

Czego potrzeba od dostawców

Platformy agentów potrzebują widocznych trust labels. Treść z public issues, external PRs, logs, web pages i MCP tools powinna zachować swoje pochodzenie. Policy powinny mówić: ten tekst może pomóc w analizie, ale nie może autoryzować private read ani public write.

Read-only nie wystarczy jako opis, jeśli agent może czytać private data i mówić publicznie. Autonomous nie wystarczy, jeśli administrator nie widzi tools, repos, outputs i network paths.

GitLost nie jest powodem, by porzucić AI automation. Jest powodem, by przestać traktować agentów jak okna czatu. Agent w developer workflow to aktor z credentials. Prosta zasada: nie łącz public input, private data i public output w jednym unattended agent.