W poprzednich tekstach pisaliśmy, że problem z agentami AI nie zaczyna się i nie kończy na samym prompt injection. Najgroźniej robi się wtedy, gdy agent może działać — bo ma narzędzia, integracje i odpowiednio szerokie uprawnienia. Raport GitGuardian pokazuje jeszcze jedną, często pomijaną warstwę tego samego problemu. Zanim agent wykona coś, czego nie powinien, ktoś wcześniej musi rozlać po środowisku sekrety, tokeny i credentials, które w ogóle umożliwią działanie. Chaos uwierzytelnienia i chaos wykonania coraz częściej okazują się tym samym problemem oglądanym z dwóch stron.
GitGuardian podaje, że w 2025 wykryto 28 649 024 nowych hardcoded secrets w publicznych commitach GitHuba, co oznacza wzrost o 34% rok do roku. Raport podkreśla też, że wycieki nie siedzą już tylko w publicznym kodzie. Problem obejmuje repozytoria wewnętrzne, narzędzia współpracy, infrastrukturę self-hosted i środowiska, w których sekrety krążą razem z codzienną pracą. Help Net Security zwraca uwagę, że credentials rozlewają się po kodzie, narzędziach i infrastrukturze, a część z nich pozostaje aktywna zaskakująco długo.
To bardzo dobrze spina się z wnioskami z tekstu o Bedrock. Tam problemem nie był sam prompt injection, ale środowisko pełne uprawnień, integracji i możliwości wykonania. AWS pisze wprost, że prompt injection jest problemem aplikacyjnym i że obrona wymaga m.in. least privilege oraz analizy polityk IAM. Innymi słowy: prompt to tylko wejście. Prawdziwe ryzyko zaczyna się tam, gdzie system ma czym odpowiedzieć światu. Raport GitGuardian pokazuje zaś, że to „czym” coraz częściej są po prostu porozrzucane po środowisku sekrety.
I właśnie tu zaczyna się najciekawsza część tej historii. Permission injection pyta: co agent może zrobić, jeśli już da się nim sterować? Secrets sprawl pyta: jakimi kluczami, tokenami i poświadczeniami agent albo workflow w ogóle dysponuje? To nie są dwa osobne tematy. To dwie warstwy tej samej architektury ryzyka. Jedna mówi o zakresie działania. Druga o paliwie, które to działanie zasila.
Sekret przestał być błędem w kodzie
Przez lata łatwo było opowiadać problem sekretów jako dość prosty błąd developera. Ktoś wkleił token do repozytorium. Ktoś zapomniał o .env. Ktoś opublikował klucz API. Ten model nadal istnieje, ale raport GitGuardian pokazuje, że dziś to za mało. Sekret nie jest już tylko w kodzie. Sekret jest w ruchu. Przechodzi przez commity, pipeline’y, Slacka, wiki, tickety, self-hosted GitLaba, registry obrazów i konfiguracje narzędziowe. Właśnie dlatego GitGuardian podkreśla, że wycieki obejmują także repozytoria prywatne, środowiska wewnętrzne i narzędzia współpracy.
To jest dużo większa zmiana, niż wygląda na pierwszy rzut oka. Kiedyś sekret był problemem lokalnym: błąd w jednym miejscu, który trzeba było usunąć. Dziś sekret coraz częściej jest produktem ubocznym workflow. Powstaje w jednym miejscu, trafia do drugiego, zostaje skopiowany do trzeciego, a potem zaczyna żyć własnym życiem. I właśnie dlatego coraz trudniej traktować secrets sprawl jako kwestię higieny pojedynczego repozytorium. To problem architektury pracy.
AI nie tworzy tego chaosu od zera. AI go przyspiesza
Najciekawsze jest to, że secrets sprawl i agentic AI nie rosną obok siebie przypadkiem. Rosną w tym samym kierunku. Im więcej narzędzi działa automatycznie, im więcej zadań przechodzi przez agenta, im więcej konektorów i workflow łączy systemy, tym większa presja, żeby gdzieś „na chwilę” zostawić token, klucz albo sekret. Raport GitGuardian pokazuje to po stronie ekspozycji credentials. W publicznych commitach wycieki związane z usługami AI wzrosły o 81%, a analiza publicznego GitHuba wskazuje też, że commity wspomagane przez AI częściej zawierają sekrety niż baseline ogólny.
To nie znaczy, że AI „magicznie produkuje” wycieki. To znaczy raczej, że środowisko pełne automatyzacji i agentów tworzy więcej miejsc, w których sekret może zostać użyty, zapisany, skopiowany albo utrwalony. A kiedy taki agent dostaje zadanie do wykonania, nie myśli kategoriami „czy ten dostęp powinien tu być”. Myśli kategoriami „czy da się tym dostępem dowieźć cel”. I właśnie dlatego chaos uwierzytelnienia i chaos wykonania zaczynają być tym samym problemem.
Od promptu do działania — i dalej do credentials
W tekście „Prompt injection. Po erze prostych analogii…” problemem była granica między analizą a wykonaniem. Model przestaje być tylko interfejsem tekstowym, a staje się elementem systemu wykonawczego: czyta dokumenty, używa narzędzi, przegląda web, korzysta z pamięci, wykonuje akcje. To był moment, w którym prompt injection przestawał być tylko błędem interpretacji i stawał się testem zaufania, uprawnień i architektury całego systemu.
Raport GitGuardian pokazuje trzecią warstwę tej samej układanki. Zanim agent wykona coś, czego nie powinien, ktoś wcześniej musi przygotować mu środowisko, w którym wykonanie w ogóle będzie możliwe. To środowisko składa się z tokenów, sekretów, poświadczeń, kluczy API i dostępów rozlanych po całym workflow. Jeśli prompt injection jest próbą przejęcia logiki działania, a permission injection próbą przejęcia zakresu działania, to secrets sprawl jest przejęciem materiału, z którego to działanie w ogóle jest zbudowane.
Credentials jako paliwo workflow
To jest chyba najlepsza rama dla tego problemu: credentials stały się paliwem workflow. Nie są już tylko wrażliwym sekretem schowanym w szafie. Są aktywnym elementem obiegu pracy. Dzięki nim działają pipeline’y, registry, konektory, agenci, systemy CI/CD, integracje SaaS i biblioteki AI. Jeśli są porozrzucane po środowisku, to nie trzeba nawet „hackować” każdej kolejnej warstwy klasycznymi metodami. Wystarczy znaleźć miejsce, w którym legalne poświadczenie już istnieje i może zostać użyte.
To bardzo przypomina logikę, którą widzieliśmy przy Bedrock. Tam problemem było to, że model działał w otoczeniu pełnym integracji, guardrails, knowledge base i uprawnień. Badacze opisywali ataki na permissions, konfigurację i integracje wokół modelu, a nie tylko na sam model. Tutaj jest podobnie. Sekret nie jest ciekawy jako ciąg znaków. Jest ciekawy jako uprawnienie w ruchu, które pozwala workflow przejść od interpretacji do działania.
Dlaczego ten temat jest ważny właśnie teraz
Bo środowisko software delivery coraz bardziej przypomina system naczyń połączonych. Repozytoria, pipeline’y, czaty, wiki, registry, konektory, narzędzia AI i środowiska wykonawcze przestały być odrębnymi światami. Dziś są jednym obiegiem pracy. GitGuardian pokazuje, że sekrety pojawiają się nie tylko w kodzie, ale też w MCP i narzędziach współpracy. To ważne, bo dokładnie tam działają dziś coraz częściej agenci, konektory i automatyzacja.
I właśnie dlatego najciekawszy wniosek z tego raportu nie brzmi: „developerzy nadal wrzucają tokeny do repozytoriów”. To zbyt małe ujęcie. Lepszy brzmi: organizacje budują środowiska, które same produkują i rozpraszają credentials jako naturalny produkt uboczny pracy. A gdy do takiego środowiska dokładamy agentów AI, którzy mają działać szybko, sprawnie i „najlepiej jak potrafią”, chaos uprawnień zaczyna spotykać się z chaosem wykonania.
Co z tego wynika dla security
Najpraktyczniejszy wniosek jest dość prosty: problemu sekretów nie da się już traktować jako samego skanowania repozytoriów. To nadal ważne, ale niewystarczające. Trzeba patrzeć szerzej:
- gdzie credentials powstają,
- gdzie są kopiowane,
- które workflow używają ich automatycznie,
- które agenty i konektory mają do nich dostęp,
- i jak długo pozostają aktywne po ujawnieniu.
W świecie agentów AI to znaczy jeszcze coś więcej. Nie wystarczy pytać, czy agent jest odporny na prompt injection. Trzeba pytać:
- jakie ma uprawnienia,
- z jakich tokenów korzysta,
- co może zrobić z cudzym sekretem, jeśli go znajdzie,
- i czy środowisko nie przygotowało mu już wcześniej zbyt wielu możliwości działania. To dokładnie ten sam wniosek, który płynął z tekstu o permission injection: problem nie zaczyna się przy samym modelu. Zaczyna się przy architekturze, która daje mu realną sprawczość.
Podsumowanie
W dyskusji o agentach AI zbyt łatwo skupiać się na tym, co model „rozumie” albo jak można nim manipulować promptem. Tymczasem realne ryzyko coraz częściej nie zaczyna się w warstwie języka, ale w warstwie wykonania. A ta warstwa jest dziś zasilana przez sekrety, tokeny i poświadczenia rozlane po całym workflow.
Agent nie potrzebuje magicznej autonomii, żeby stać się groźny. Wystarczy środowisko, które wcześniej przygotowało mu zbyt wiele możliwości działania. AI nie tworzy problemu secrets sprawl od zera. AI sprawia, że środowisko pełne porozrzucanych credentials zaczyna działać szybciej, szerzej i bardziej autonomicznie.
Źródła
Help Net Security — omówienie raportu GitGuardian o wzroście wycieków credentials przez kod, narzędzia i infrastrukturę.
GitGuardian — State of Secrets Sprawl 2026, z danymi o 28 649 024 nowych hardcoded secrets, wzroście o 34% oraz wpływie AI na wzrost wycieków.
Cyberflux — Nie prompt injection, tylko permission injection? Czego Bedrock uczy o agentach AI.
Cyberflux — Prompt injection. Po erze prostych analogii. Prawdziwy problem zaczyna się tam, gdzie agent może działać.
AWS Documentation — Prompt injection security – Amazon Bedrock, z zaleceniami least privilege i traktowaniem prompt injection jako problemu aplikacyjnego.
