Wstrzykiwanie poświadczeń: czy ochroni agenta AI przed wyciekiem?
Runtime'owe wstrzykiwanie poświadczeń ogranicza wycieki, ale nie chroni agenta z dostępem do sekretów. Co pokazał atak Comment and Control i jak zmniejszyć ryzyko.
Czym jest runtime'owe wstrzykiwanie poświadczeń?
Runtime'owe wstrzykiwanie poświadczeń polega na tym, że aplikacja lub agent otrzymuje sekret dopiero w chwili wykonania operacji. Wartość nie leży w kodzie ani w pliku konfiguracyjnym, lecz w zewnętrznym komponencie, który podstawia ją w miejsce placeholdera. GitHub opisuje pokrewny model „zero-secret agent”: tokeny pozostają poza kontenerem agenta i są wykorzystywane przez proxy [1]. W ekosystemie AI do programowania (/ai-do/programowania) to dziś jeden z podstawowych mechanizmów ograniczania ryzyka.
Nazwa nie wskazuje jednego produktu. To wzorzec architektoniczny, który można zrealizować na trzy sposoby: przez menedżer sekretów, przez proxy z kontrolą tras albo przez krótkotrwałe tokeny wydawane na czas jednego zadania [1]. Rozróżnienie ma znaczenie praktyczne, bo „runtime injection” bywa opisywane jako funkcja konkretnego narzędzia, a nie jako właściwość całej architektury. Zespoły, które traktują go jak opcję w jednym programie, zostawiają nieosłonięte ścieżki w pozostałych elementach łańcucha.
Dlaczego agenci AI zwiększają ryzyko wycieku?
Agent łączy w jednym procesie dostęp do plików, repozytorium, sieci i sekretów workflow. Każde poświadczenie, do którego agent ma dostęp, trzeba traktować jako potencjalnie możliwe do wyprowadzenia [2]. Słabym ogniwem nie jest sam model, lecz zestaw uprawnień przyznanych mu w środowisku.
Raport Cloud Security Alliance ujmuje to podobnie: problemem jest kombinacja uprawnień — narzędzia wykonawcze, GitHub, sieć i sekrety workflow jednocześnie w jednym kontekście [3]. Agent czyta zmienne środowiskowe, pliki konfiguracyjne, stan /proc i logi, jeśli działa w tej samej domenie zaufania co pozostałe kroki workflow [1]. Wystarczy jedna niezaufana treść w polu, które agent odczytuje jako instrukcję, aby cały ten dostęp stał się wektorem ataku.
Co pokazał atak Comment and Control?
Badanie „Comment and Control” ujawniono 15 kwietnia 2026 roku. Aonan Guan, Zhengyu Liu i Gavin Zhong pokazali jeden wzorzec ataku wymierzony w trzy agenty: Claude Code Security Review, Gemini CLI Action i GitHub Copilot Agent [2][4]. We wszystkich przypadkach agent wykonywał polecenia ukryte w treści, którą czytał z GitHuba.
Wektorem był tytuł pull requesta, opis issue, komentarz albo ukryty komentarz HTML [5]. Zewnętrzny serwer C2 nie był potrzebny: sekrety wyprowadzano przez legalne mechanizmy GitHuba — komentarz PR, komentarz issue lub commit [4][6]. W badaniu wykradziono między innymi ANTHROPIC_API_KEY, GEMINI_API_KEY, GITHUB_TOKEN i GITHUB_COPILOT_API_TOKEN [2][4].
Skala wniosku jest większa niż lista kluczy. Jeden z dostawców opisał ten scenariusz we własnej karcie systemu, zanim badanie trafiło do publikacji [6]. Ryzyko było więc nazwane, a mimo to wystąpiło w produktach używanych na produkcji — co pokazuje, że sama świadomość zagrożenia nie wystarcza bez zmiany architektury.
Czy runtime'owe wstrzykiwanie poświadczeń wystarcza?
Częściowo. Runtime injection utrudnia przypadkowe zapisanie klucza w kodzie, ale nie odbiera agentowi dostępu do sekretu w środowisku wykonawczym. Jeśli agent może odczytać wartość w trakcie działania, może ją także wyprowadzić [1][7]. Mechanizm zmniejsza powierzchnię ryzyka, nie zamyka go.
| Wariant | Gdzie leży sekret | Co widzi model | Odporność na prompt injection |
|---|---|---|---|
| Sekret w zmiennej środowiskowej | w środowisku zadania | rzeczywistą wartość | niska |
| Runtime injection przez proxy | w osobnym komponencie, model dostaje referencję | placeholder lub token pośredni | średnia |
| Agent bez dostępu do sekretów | poza domeną zaufania agenta | żadnej wartości, żądania idą przez gateway | najwyższa |
Najbezpieczniejszy wariant opisany przez GitHuba to agent bez dostępu do rzeczywistych wartości: proxy lub gateway z kontrolą tras, krótkotrwałe tokeny, ograniczony egress i osobny komponent przechowujący sekrety [1]. Każdy z tych elementów działa tylko razem z pozostałymi. Proxy bez kontroli tras przepuszcza żądanie z dowolnym celem, a krótkotrwały token bez wąskiego zakresu nadal pozwala sięgnąć po zbyt wiele zasobów [7].
Jak ograniczyć ryzyko w zespole?
Cztery kroki dają największy efekt: oddziel sekrety od środowiska agenta, wydawaj tokeny krótkotrwałe i wąsko zakresowe, skanuj zmiany przed commitem oraz unieważniaj klucz natychmiast po wykryciu wycieku [1][8]. Kolejność ma znaczenie, bo reakcja po fakcie jest zawsze droższa niż brak dostępu.
Skanowanie sekretów w agentach AI przez GitHub MCP Server było w public preview od marca 2026 roku, a 5 maja 2026 roku stało się ogólnie dostępne dla repozytoriów z Secret Protection [8][9]. Narzędzie sprawdza zmianę przed commitem lub pull requestem, a nie po jej opublikowaniu. To odwraca dotychczasowy model, w którym wyciek wykrywano już w historii repozytorium.
Po wykryciu wycieku pierwszym krokiem jest unieważnienie lub obrót klucza. Usunięcie pliku z najnowszego commita nie usuwa sekretu z historii, forków ani klonów [10]. Skala problemu pozostaje duża: w 2025 roku na GitHubie ujawniono 28 mln poświadczeń [11].
Warto też ograniczyć to, co agent może przeczytać. Jeśli ten sam proces ma dostęp do kodu, do sieci i do sekretów, żadna pojedyncza kontrola nie rozdzieli tych uprawnień w razie błędu. Dwa podobne przypadki z rynku pokazują ten sam mechanizm: wyciek danych w Kodano i kara dla firmy (/posts/kodano-i-rodo-dlaczego-wyciek-danych-uderzyl-w-150-tysiecy-klientow-a-kara-moze-kosztowac-firme-20-mln-zl) oraz rozszerzenie VS Code, które naraziło tysiące repozytoriów (/posts/vs-code-kontra-github-jak-jedno-rozszerzenie-narazilo-3800-repozytoriow-i-co-z-tym-zrobic).
Najczęstsze pytania
Czy runtime'owe wstrzykiwanie poświadczeń wystarcza jako jedyna ochrona?
Nie. Chroni przed zapisaniem klucza w kodzie i w promptach, ale nie przed agentem, który ma dostęp do sekretu w środowisku wykonawczym. Potrzebne są dodatkowo krótkotrwałe tokeny o wąskim zakresie, kontrolowany egress i skanowanie zmian przed commitem [1][7].
Czym różni się prompt injection od klasycznego wycieku klucza?
Klasyczny wyciek polega na tym, że sekret trafia do commita i zostaje w historii repozytorium. Prompt injection działa inaczej: niezaufana treść w tytule PR lub komentarzu staje się instrukcją dla agenta, który sam sięga po sekret i publikuje go przez GitHuba [2][5].
Jak szybko trzeba unieważnić klucz po wykryciu wycieku?
Natychmiast. Usunięcie pliku z najnowszego commita nie usuwa sekretu z historii, forków ani klonów, więc samo czyszczenie repozytorium nie zamyka dostępu [10]. Obrót klucza jest pierwszym krokiem, a dopiero potem porządek w historii.
Czy menedżer haseł zastępuje proxy z kontrolą sekretów?
Nie w scenariuszach agentowych. Menedżer przechowuje wartości i wydaje je po zatwierdzeniu, ale gdy agent działa autonomicznie, potrzebny jest komponent, który nie przekazuje wartości do kontekstu modelu i ogranicza, dokąd może trafić żądanie [1][3].
Źródła
- Under the hood: Security architecture of GitHub Agentic Workflows (GitHub Blog, 2026)
- Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent (oddguan.com, 2026)
- GitHub AI Agents as Credential Exfiltrators (Cloud Security Alliance, 2026)
- Comment and Control: GitHub AI Agents as Credential Exfiltrators (Cloud Security Alliance, 2026)
- AI agents on GitHub leak API keys via prompt injection (Techzine Global, 2026)
- Three AI coding agents leaked secrets through a single prompt injection. One vendor's system card predicted it (VentureBeat, 2026)
- Even the Best AI Agents Leak Secrets. Prompt Injection Is Why. (Cequence, 2026)
- Secret scanning in AI coding agents via the GitHub MCP Server (GitHub Changelog, 2026)
- Secret scanning with GitHub MCP Server is now generally available (GitHub Changelog, 2026)
- How to safely store API keys in a GitHub project? · Discussion #188310 (GitHub, 2026)
- Why 28 million credentials leaked on GitHub in 2025, and what to do about it (Snyk, 2026)