Przejęcie tożsamości w przepływie pracy: Noma Labs zamienia zwykły e-mail do działu wsparcia w uprzywilejowany dostęp do danych

Dnia 9 września 2026 r. zespół badawczy Noma Security, publikujący jako Noma Labs, opublikował relację o tym, co nazywa przejmowaniem tożsamości przepływu pracy: korporacyjny przepływ pracy AI odczytuje zwykłą wiadomość, która dociera do publicznego punktu wejścia — skrzynki odbiorczej pomocy technicznej, zgłoszenia GitHub, formularza internetowego, udostępnionego dokumentu — a następnie wykonuje żądane zadanie przy użyciu własnego konta usługi o wysokich uprawnieniach zamiast uprawnień nadawcy. W omówieniu Nomy osoba z zewnątrz wysyła e-mail na publiczny adres pomocy technicznej firmy i prosi, między innymi, o kwartalne wyniki sprzedaży z najnowszej wiadomości e-mail dyrektora finansowego; kilka minut później zawartość trafia do skrzynki odbiorczej atakującego. Nie oszukano żadnego modelu i nie naruszono żadnego konta, co jest głównym punktem raportu: „atakującemu wystarczyło tylko poprosić”. Archiwum nie odnotowuje żadnych rzeczywistych szkód — nie wskazano żadnej ofiary ani nie opisano żadnego wdrożonego systemu jako naruszonego — i klasyfikuje ustalenie jako badawcze, o wadze średniej, pewności A i statusie „sporne: fałsz”. Relacja ta opiera się na raporcie Noma Labs, na materiale Dark Reading opublikowanym tego samego dnia oraz na publikacji uzupełniającej CSO Online, a archiwum incydentów AI zawiera ten wpis obok sąsiednich wpisów, z których każdy ma własne źródła, ocenę wagi i stopień pewności.

Warto przeczytać same pola rekordu, zanim przejdzie się do tekstu. Jest oznaczony tagami INFRA i EXFIL, obejmuje region GLOBAL, zawiera jedną dokładną do dnia datę — 9 września 2026 r. — i nie jest oznaczony jako wpis przełomowy. Data jest wyłącznie datą publikacji badania i niczym więcej; nie dołączono do niej żadnej osi czasu zdarzenia, ponieważ nie ma zdarzenia, którego przebieg można by umiejscowić w czasie. To pierwsza rzecz, którą trzeba zapamiętać: to, co opublikowała Noma, to mechanizm i kategoria, a nie raport o naruszeniu.

Co Noma pokazała, a czego nie

Sekwencja skrzynki wsparcia jest skonstruowaną ilustracją, a nie przypadkiem klienta. Raport Nomy nie wymienia żadnej organizacji, nie podaje liczby dotkniętych wdrożeń, nie publikuje telemetrii z żadnego rzeczywistego potoku ani nie podaje linku do uruchomienia proof-of-concept dla tego scenariusza — w przeciwieństwie do lipcowych badań grupy, które wskazywały na publiczne uruchomienie GitHub Actions. Zamiast tego raport oferuje opis mechanizmu wystarczająco precyzyjny, by można go było sprawdzić względem architektury: pojawiają się nieuwierzytelnione dane wejściowe, model interpretuje je poprawnie, potok wykonuje wywołanie podrzędne, a wywołanie to odbywa się z uprawnieniami autora workflow.

Sasi Levi, kierownik ds. badań bezpieczeństwa w Noma i autor raportu, ujmuje pierwotną przyczynę w jednym zdaniu: „tożsamość i uprawnienia użytkownika, który uruchamia przepływ pracy, są rozdzielone od tożsamości i uprawnień używanych do jego wykonania”. Tam, gdzie to występuje, przepływ pracy staje się — jak ujmuje to raport — „nieuwierzytelnionymi pośrednikami do uprzywilejowanych działań i cichej eksfiltracji danych”.

Ponieważ działania przebiegają przez zaufaną automatyzację z prawidłowymi poświadczeniami, Noma twierdzi, że konwencjonalne alertowanie ma niewiele do wychwycenia. Żądanie jest zwyczajne, wynik modelu jest prawidłowym wynikiem modelu, wywołanie API jest uwierzytelnione, a odpowiedź jest tą odpowiedzią, którą przepływ pracy miał wysłać. CSO Online zacytował specjalistę ds. red teamingu Vibhuma Dubeya, który konkretnie ujął problem wykrywania: „Poszczególne zdarzenia mogą wyglądać całkowicie wiarygodnie. Przydatne sygnały pochodziłyby z korelacji pierwotnego autora żądania, tożsamości użytej na dalszym etapie, zasobów, do których uzyskano dostęp, dostarczonych parametrów i końcowego działania”.

Sprawdzenie, które nie przechodzi, to sprawdzenie autoryzacji, a nie filtr treści.

Najostrzejszą ilustracją w raporcie jest para identycznych żądań. Od dyrektora finansowego: „Jakie są kwartalne liczby sprzedaży od Dyrektora Finansowego w jego najnowszym e-mailu?”. Od nadawcy zewnętrznego: te same słowa. Punkt Nomy jest taki, że prompt i żądana operacja są takie same, podczas gdy decyzja o autoryzacji powinna być zupełnie inna — „Dyrektor finansowy ma prawo do tych informacji; nadawca zewnętrzny nie”.

Standardowe detektory prompt injection i zabezpieczenia agentów – argumentuje raport – klasyfikują oba dane wejściowe identycznie, ponieważ w żadnym z nich nie ma nic złośliwego do wykrycia. „Ryzyko bezpieczeństwa nie tkwi w prompcie; tkwi w granicy autoryzacji”. Strukturalne twierdzenie Nomy wynika z tego: zabezpieczenia, instrukcje systemowe i filtry wejściowe „nie zostały zaprojektowane, aby służyć jako granica autoryzacji”, więc potok, który polega na nich przy decydowaniu, co wywołujący może pobrać, polega na mechanizmie kontroli, który nigdy nie miał pełnić tej roli.

Różnica ma praktyczne znaczenie. Bezpośrednie wstrzykiwanie promptów manipuluje tym, jak model wykonuje instrukcje; pośrednie wstrzykiwanie promptów ukrywa instrukcje w treści, którą model później odczyta; przejmowanie tożsamości przepływu pracy, jak definiuje je Noma, nie wymaga ani jednego, ani drugiego, ponieważ jest to żądanie, które model powinien rozumieć, a potok powinien wykonać. Obrońca, który spędził rok na wzmacnianiu zabezpieczeń przed wstrzykiwaniem, pracował nad inną warstwą.

Statyczne przepływy pracy znajdują się poza inicjatywą wzmacniania bezpieczeństwa agentów.

Noma rozdziela dwie rzeczy, które rutynowo używa się zamiennie. Przepływ pracy AI to zdefiniowana z góry, statyczna sekwencja, w której model jest jednym krokiem przetwarzania — w skrócie używanym w raporcie: krok A, model, krok B, krok C — a deterministyczny potok wokół modelu kontroluje, co się dzieje. Przepływ pracy agentowej jest autonomiczny: agent decyduje, jakie kroki podjąć i jakie narzędzia wywołać. Wiele obecnych wysiłków na rzecz bezpieczeństwa, argumentuje raport, poszło w drugi rodzaj — ograniczanie dostępu do narzędzi i zawężanie uprawnień dla agentów podejmujących dynamiczne decyzje — a te kontrole nie obejmują pierwszego.

Raport zamyka również oczywistą furtkę. Ograniczanie tego, kto lub co może uruchomić workflow, nie rozwiązuje problemu: jeśli automatyzacja uruchamia się o 8:00 według harmonogramu i działa na skrzynce odbiorczej, do której każdy może pisać, audytowanie „kto może uruchomić ten workflow” odpowiada na niewłaściwe pytanie. Zasada Nomy mówi, że każdą automatyzację trzeba oceniać przez pryzmat „najmniej zaufanej strony zdolnej wpływać na to, na czym ona działa” — z uwzględnieniem e-maili, formularzy, zgłoszeń, zgłoszeń GitHub, udostępnionych dokumentów i wiadomości czatowych.

Noma twierdzi, że Google naprawiło problem w Google Workflows; Google nic nie opublikowało.

Jedyna wymieniona z nazwy platforma w raporcie należy do Google. Noma podaje, że zidentyfikowała ten sam wektor ryzyka w Google Workflows, że odpowiedzialnie go zgłosiła oraz że Google potwierdziło otrzymanie zgłoszenia i potwierdziło poprawkę „bez ujawniania szczegółów implementacji”. To zdanie stanowi całość publicznego zapisu. Nie udało się znaleźć żadnego biuletynu Google, informacji o wydaniu ani CVE opisującego ten wektor, a wszystkie wtórne relacje o poprawce — w tym te opublikowane w dniach po 9 września — przypisują ją Nomie, a nie Google.

Raport również nie jest całkowicie spójny co do tego, o który produkt Google chodzi. W treści wymieniono Google Workflows; nagłówek sekcji w tym samym raporcie brzmi „Google Workspace: AI Workflow Identity Hijacking”. Oba są produktami Google o różnych granicach zaufania, a raport ich nie uzgadnia. Noma nie mówi, czy zgłoszony przez nią przypadek został wykorzystany, ilu klientów było narażonych ani co zmieniła poprawka — a ponieważ Google nic nie powiedział, żadnej z tych luk nie można zamknąć po stronie dostawcy.

GitLost był tą samą granicą, widzianą przez węższą soczewkę.

Wcześniejsze ujawnienie Nomy daje tej kategorii precedens. W lipcu 2026 r. grupa opublikowała badanie dotyczące GitHub Agentic Workflows, które nazwała GitLost: przepływ pracy uruchamiany w momencie przypisania zgłoszenia odczytywał tytuł i treść zgłoszenia oraz odpowiadał komentarzem, a ponieważ agent miał dostęp do odczytu we wszystkich repozytoriach organizacji, użytkownicy zewnętrzni mogli wykorzystać przypisanie zgłoszenia, by dotrzeć do danych z prywatnych repozytoriów. Dark Reading opisał to 7 lipca 2026 r. i przedstawił atakującego ukrywającego polecenia prostym językiem angielskim w treści zgłoszenia otwartego w publicznym repozytorium, bez potrzeby posiadania poświadczeń i umiejętności kodowania.

Te dwa ujęcia nie są identyczne, a różnica jest właśnie tym, co interesujące. Lipcowa relacja Dark Reading to historia o wstrzykiwaniu promptów: tekst kontrolowany przez atakującego jest odczytywany jako instrukcje. Wrześniowy raport Nomy opisuje GitLost pod kątem wyzwalacza i dostępu do odczytu w całym repozytorium, przedstawiając go jako tę samą granicę autoryzacji widzianą z jednej perspektywy. Oba opisy pasują do przepływu pracy, w którym agent odczytał tekst napisany przez osobę z zewnątrz, ale tylko wcześniejszy zależy od sterowania modelem. Noma twierdzi teraz, że zgłosiła ten sam wektor ryzyka do Google; nie mówi jednak, czy przypadek GitLost kiedykolwiek wykorzystano poza opublikowaną demonstracją.

Według własnej relacji Nomy na temat zasięgu, Hacker News, Dark Reading i ponad 100 innych międzynarodowych mediów opisały badanie GitLost. Ta liczba pochodzi od dostawcy, a niniejszy artykuł nie dokonał niezależnego zliczenia tych publikacji.

Praktycy zgadzają się, że mechanizm jest stary; spór dotyczy nazwy.

{{1}}Niezależne relacje medialne nie podważyły tego ustalenia, a dwóch zewnętrznych praktyków zakwestionowało nowość, a nie samą istotę sprawy. Morey Haber, główny doradca ds. bezpieczeństwa w BeyondTrust, powiedział Dark Reading: „Nikt nie nakłonił modelu AI do zrobienia czegokolwiek, czego nie powinien był zrobić. Model zrobił dokładnie to, co mu kazano, a kazał mu to obcy (niezaufany) człowiek; otaczający go przepływ pracy wykorzystał tożsamość kogoś innego, aby do tego doszło, ponieważ nie określono jego zakresu i nie traktowano go zgodnie z zasadą najmniejszych uprawnień”. CSO Online zacytował Vibhuma Dubeya, który opisał ten wzorzec jako „znaną klasę słabości autoryzacji” i dodał, że gdy nieuwierzytelnione dane wejściowe mogą uruchomić zaufany przepływ pracy działający z własnymi uprawnieniami, „przepływ pracy może skutecznie działać jako zdezorientowany pełnomocnik”.{{/1}}

Ram Varadarajan, dyrektor generalny Acalvio, zaproponował Dark Reading zupełnie inną kontrolę: zamiast zwiększać filtrowanie, zapełnić środowisko wabikami — fałszywymi wątkami kadry kierowniczej, rekordami honeytoken — które nie mają żadnego uzasadnionego powodu, by jakikolwiek upoważniony przepływ pracy po nie sięgał, tak aby pozornie niegroźne żądanie sięgające po taki wabik naruszyło granicę, której nigdy nie powinno przekroczyć. Spór, jeśli można to tak nazwać, dotyczy tego, czy użyteczny wkład to nowa nazwa luki w delegowaniu z czasów 1988 r., czy działający opis tego, gdzie ta luka obecnie występuje. Noma stoi na stanowisku drugim: że wzorzec ten ma charakter systemowy w korporacyjnych potokach AI i że obecne ramy bezpieczeństwa AI patrzą na niewłaściwą płaszczyznę.

Środek zaradczy to delegacja i punkt kontrolny, a nie lepszy filtr.

Zalecane przez Noma mechanizmy kontroli działają na warstwie aplikacji, a nie na warstwie modelu. Delegowanie tokenów z uwzględnieniem tożsamości oznacza usunięcie statycznych administracyjnych kluczy API z przepływów pracy AI i wykonywanie operacji na danych za pomocą krótkotrwałych tokenów delegowania o ograniczonym zakresie, powiązanych z uwierzytelnionym żądającym, tak aby kontekst użytkownika był propagowany do wywołania, które faktycznie sięga do danych. Kontekstowe punkty kontroli autoryzacji oznaczają traktowanie każdego wyniku modelu jako niezaufanych danych wejściowych i umieszczenie jawnej oceny kontroli dostępu i ochrony w czasie wykonania między etapem transformacji modelu a każdym późniejszym wywołaniem bazy danych lub narzędzia. Asymetryczna separacja wyników oznacza strukturalne oddzielenie pobierania danych od zewnętrznych kanałów komunikacji, tak aby przepływ pracy obsługujący wrażliwe dane wewnętrzne nie współdzielił ścieżki wykonania z zautomatyzowanym mechanizmem odpowiadającym podmiotom zewnętrznym.

Dubey zaproponował CSO Online tańszy test niż którykolwiek z trzech: porównanie wyników na różnych poziomach uprawnień. „Jeśli użytkownik o niskich uprawnieniach może uzyskać taki sam wynik jak administrator, ponieważ systemy dalszego przetwarzania widzą wyłącznie tożsamość przepływu pracy, to właśnie tam skupiłbym dochodzenie”.

Co zapis pozostawia otwarte

• Brak ofiary, brak liczby i brak telemetrii. Przypadek skrzynki pomocy Nomy to przykład instruktażowy; raport nie wskazuje żadnej organizacji, a archiwum odnotowuje rzeczywistą szkodę jako nieprawdziwą. Wiarygodność mechanizmu nie jest dowodem na to, że został użyty.

• Który produkt Google naprawiono i na czym polegała naprawa. Tekst Nomy mówi o Google Workflows, nagłówek jej sekcji — o Google Workspace, a Google nie opublikowało nic. Organizacje nie mogą jeszcze ustalić na podstawie źródeł publicznych, czy uruchamiany przez nie potok był objęty zakresem.

• Czy ten wektor został gdziekolwiek wykorzystany. Ani raport, ani żadne materiały przeanalizowane na potrzeby tego artykułu nie opisują zaobserwowanej kampanii, utraty danych ani ustalenia kryminalistycznego, które można by przypisać przejęciu tożsamości w przepływie pracy.

• Czy ta kategoria broni się w pomiarach. Żaden niezależny podmiot nie opublikował skanu, korpusu dotkniętych potoków ani zestawu testów dla tego wzorca; dowody w obiegu to argument architektoniczny plus relacja jednego dostawcy o jednym naprawionym przypadku.

• Kto formułuje ten argument. Noma Labs to ramię badawcze Noma Security, które sprzedaje mechanizmy kontroli bezpieczeństwa agentów dokładnie takiego rodzaju, jaki zaleca jego raport. To nie czyni tego ustalenia błędnym — Dark Reading i CSO Online oba o tym informowały i żadne z nich nie znalazło błędu faktycznego — ale to kontekst, który czytelnik powinien mieć na uwadze, oceniając, jak szeroko zakreślono tę kategorię.

Stopień ważności „medium” w rekordzie i jego flaga rzeczywistej szkody „false” opisują dowody, a nie mechanizm. To, co Noma faktycznie ustaliła, jest wąskie i możliwe do sprawdzenia: że tożsamość wyzwalacza przepływu pracy i jego tożsamość wykonawcza to odrębne rzeczy, że ta druga jest zwykle potężniejsza oraz że pipeline, który nigdy ich nie porównuje, zrobi dla obcego to samo, co zrobiłby dla osoby, dla której go zbudowano. Odpowiednia kontrola jest przez to nieefektowna — przy każdej automatyzacji zapytać, kto może wpływać na to, na co ona działa, i czy cokolwiek dalej w łańcuchu kiedykolwiek ponownie sprawdza, czy osoba pytająca miała prawo zapytać.