Raport Wiz Black October śledzi dziewięć incydentów bezpieczeństwa na platformach AI

Wiz połączył co najmniej dziewięć październikowych ujawnień dotyczących bezpieczeństwa w ostrzeżenie o platformach deweloperskich AI i poświadczeniach powierzanych im przez klientów. Opublikowany 30 października raport Wiz Black October łączy incydenty dotyczące Fireworks AI, Lightning AI, Railway, Warp, OpenCode i innych usług. Napięcie jest praktyczne: platformy upraszczające rozwój oprogramowania stają się również miejscami, w których atakujący mogą znaleźć dostęp do usług wykraczających poza naruszonego dostawcę.

Ujawnienia opisują różne punkty wejścia i różne dotknięte systemy. Nie dowodzą, że każdy incydent należy do jednej skoordynowanej kampanii. Ich wspólne znaczenie wynika z pozycji, jaką te platformy zajmują między deweloperami, aplikacjami a zewnętrznymi dostawcami AI.

Dla klientów presja wykracza poza wybór asystenta programistycznego czy usługi wdrożeniowej. Platforma może pomóc zespołowi korzystać z poświadczeń dostawcy bez ujawniania ich każdemu członkowi zespołu. Ta wygoda wciąż pozostawia istotne pytanie: co się stanie, jeśli ktoś przejmie system przechowujący poświadczenia?

Co faktycznie ustala raport Wiz Black October

Najbardziej jednoznacznym ustaleniem jest nagromadzenie ujawnień, a nie dowód na istnienie jednego atakującego lub wspólnej podatności.

Badacze Wiz, Benjamin Read i Rami McCarthy, wymieniają Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode i Northflank. Ich zestawienie incydentów na platformach AI wskazuje na powtarzające się zainteresowanie poświadczeniami i zmiennymi środowiskowymi, których aplikacje używają do pobierania konfiguracji i sekretów.

To rozróżnienie ma znaczenie, ponieważ kalendarz ujawnień nie jest osią czasu ataków. Firma może wykryć nieuprawnioną aktywność przed opublikowaniem aktualizacji. Może też skorygować zakres incydentu po przeanalizowaniu dodatkowych zapisów. Traktowanie każdej wymienionej daty jako momentu naruszenia stworzyłoby fałszywą sekwencję wydarzeń.

Fireworks dostarcza konkretnego przykładu. W swoim biuletynie firma podaje, że 6 października zidentyfikowała nieuprawnione użycie wewnętrznych poświadczeń, a następnie powiadomiła dotkniętych klientów. Początkowa aktywność dotyczyła zmiennych środowiskowych powiązanych z zadaniami ewaluacyjnymi w ograniczonej grupie kont.

Według jej biuletynu o ujawnieniu poświadczeń, Fireworks nie wykrył nieuprawnionego dostępu do modeli klientów, zbiorów danych, danych treningowych, danych osobowych ani ruchu inferencyjnego. To stwierdzenie opisuje dochodzenie firmy w tamtym czasie, w granicach zadeklarowanego obwodu i kontroli.

Firma zaleciła również dotkniętym klientom rotację poświadczeń podmiotów trzecich za pośrednictwem dostawców, którzy je wydali. To istotna granica ujawnienia. Poświadczenie Fireworks i poświadczenie przechowywane w Fireworks mogą autoryzować dostęp do różnych systemów.

Czytanie tych incydentów łącznie wymaga więc uwagi wobec tego, czym faktycznie dysponuje każdy dostawca. Platforma wdrożeniowa, hostowana konsola programistyczna i środowisko pracy dla deweloperów nie ujawniają identycznych zasobów. Ich klienci korzystają z nich również w różny sposób.

Kategoria „platforma deweloperska AI” jest przydatna do zrozumienia koncentracji aktywności. Staje się mniej użyteczna, gdy zaciera różnice między produktami, sposobami przechowywania i obowiązkami klientów.

Raport należy zatem traktować jako powód do zbadania połączonych ścieżek dostępu. Nie jest on wiarygodną podstawą do założenia, że każdy klient każdego wymienionego dostawcy poniósł porównywalną szkodę.

Ta węższa interpretacja nadal ma znaczenie. Deweloper nie potrzebuje dowodów na skoordynowaną kampanię, aby przejmować się poświadczeniem przechowywanym w usłudze objętej incydentem. Bezpośrednia ekspozycja zależy od uprawnień tego poświadczenia i jego dalszej ważności.

Kluczową zmianą jest nagromadzenie konkretnych ujawnień dotyczących systemów, których deweloperzy używają do łączenia pracy. Nierozstrzygnięte pozostaje pytanie, jak daleko te połączenia pozwoliły rozprzestrzenić się skutkom każdego incydentu.

Presja na klientów wykracza poza naruszoną platformę

Dostawca może opanować własny incydent, podczas gdy klienci nadal muszą zamknąć dostęp w innych miejscach.

Lightning AI ilustruje operacyjną stronę tego problemu. Firma twierdzi, że 15 października zidentyfikowała nieuprawniony dostęp do poświadczeń, a wczesnym rankiem 16 października unieważniła dostęp użytkowników do platformy.

Jej aktualizacja dotycząca incydentu na platformie rozróżnia dotknięte usługi Studio Platform od infrastruktury wynajmu klastrów GPU i usług zarządzanych. Aktualizacja z 28 października informowała o przywróceniu dostępu tylko do odczytu w Drive, a kolejne usługi miały zostać przywrócone później.

Lightning zalecił rotację przechowywanych sekretów i przegląd połączonych usług podmiotów trzecich. Instrukcje te pokazują, dlaczego odzyskiwania sprawności po incydencie nie można mierzyć wyłącznie tym, czy strona logowania dostawcy ponownie działa.

Dostępność i ważność poświadczeń to odrębne kwestie. Przywrócenie środowiska pracy pomaga klientom wznowić pracę. Unieważnienie ujawnionego poświadczenia określa, czy osoba mająca jego kopię może nadal korzystać z usługi, do której ono uprawnia.

Railway opisał podobną granicę. W ujawnieniu z 21 października stwierdził, że nieuprawniona strona mogła uzyskać dostęp do zaszyfrowanych zmiennych środowiskowych oraz pozyskać część ich odszyfrowanej zawartości. Firma zaleciła rotację przechowywanych zmiennych i poświadczeń, a także przegląd nietypowej aktywności.

Ujawnienie dotyczące zmiennych środowiskowych ogłosiło również wstrzymanie wdrożeń na czas dochodzenia. Wprowadziło to kolejną obawę klientów: możliwość publikowania zmian podczas reagowania na potencjalną ekspozycję.

Relacje te wywierają presję na liderów inżynierii, zespoły bezpieczeństwa i właścicieli aplikacji z różnych powodów. Działy inżynierii potrzebują działających wdrożeń. Bezpieczeństwo potrzebuje możliwej do obrony oceny dotkniętego dostępu. Właściciele aplikacji potrzebują zastępczych poświadczeń bez powodowania dodatkowych przestojów.

Te obowiązki się nakładają, ale nie są wymienne. Ktoś może zaktualizować ustawienie aplikacji bez unieważnienia starego poświadczenia u jego źródła. Ktoś inny może unieważnić poświadczenie, zanim zidentyfikuje każdą aplikację, która od niego zależy.

Dla nabywców korporacyjnych zmienia to znaczenie odzyskiwania sprawności przez dostawcę. Przydatna aktualizacja musi wyjaśniać zarówno działania dostawcy mające na celu ograniczenie incydentu, jak i działania, które nadal są konieczne po stronie klienta.

Organizacja musi również odróżnić wpływ specyficzny dla usługi od własnej ekspozycji. Brak awarii obejmującej całą platformę nie dowodzi, że połączone poświadczenia pozostały prywatne. Z kolei awaria nie dowodzi, że dostęp uzyskano do każdego sekretu klienta.

Tworzy to obciążenie dokumentacyjne obok reakcji technicznej. Zespoły muszą zachowywać powiadomienia, identyfikować właścicieli poświadczeń i rejestrować, które usługi wydające poświadczenia potwierdziły ich unieważnienie. W przeciwnym razie „rozwiązane” może oznaczać różne rzeczy dla różnych uczestników.

Przeszukiwalna baza wiedzy może pomóc uporządkować dokumenty techniczne i decyzje dotyczące reakcji. Nie zastąpi jednak dowodów z systemów, które wydały i akceptowały poświadczenia.

Praktyczna presja wykracza więc poza wybór dostawcy. Klienci muszą rozumieć, z którymi kontami zewnętrznymi łączy się ich proces rozwoju oprogramowania i kto może zakończyć ten dostęp.

Wymóg ten pozostaje istotny, nawet gdy śledczy nie zidentyfikowali atakującego. Przypisanie tożsamości może poczekać na dowody. Przegląd dostępu klienta zależy od dotkniętego poświadczenia, a nie od publicznej nazwy atakującego.

Wspólna wygoda tworzy wspólną ekspozycję poświadczeń

Kompromis polega na wyborze między łatwiejszą współpracą a koncentracją dostępu, która tę współpracę umożliwia.

Ujawnienie OpenCode czyni ten kompromis wyjątkowo widocznym. Według The Hacker News incydent dotyczył Console, opcjonalnej usługi hostowanej, w której obszary robocze mogły zapisywać zewnętrzne klucze dostawców AI.

Klucz dostawcy jest poświadczeniem typu bearer, co oznacza, że samo jego posiadanie może autoryzować żądania w granicach jego uprawnień. Trzymanie go z dala od poszczególnych członków zespołu może upraszczać administrację. Usługa hostowana nadal potrzebuje jednak sposobu, aby go użyć.

Według firmy opisywane naruszenie OpenCode Console mogło dotknąć 1,4% użytkowników Console. OpenCode odróżnił te hostowane poświadczenia od kluczy przechowywanych lokalnie przez aplikacje wiersza poleceń i desktopowe.

To rozróżnienie zapobiega nadmiernie szerokim wnioskom dotyczącym produktu. Opisywana ekspozycja dotyczyła konkretnej usługi i sposobu przechowywania poświadczeń. Nie dowodziła, że każda instalacja obsługiwała klucze tą samą ścieżką.

Ujawnia też, dlaczego mechanizmy kontroli widoczne dla klienta wymagają uważnej interpretacji. Limit egzekwowany wewnątrz hostowanej konsoli dotyczy aktywności, którą konsola może obserwować. Bezpośrednie użycie skopiowanego klucza dostawcy przebiega inną ścieżką.

To konsekwencja architektoniczna, a nie dowód, że konkretny limit klienta zawiódł podczas tego incydentu. Jej znaczenie wynika z miejsca, w którym odbywa się egzekwowanie.

To samo rozumowanie ma zastosowanie do usług deweloperskich, choć ich implementacje się różnią. Platforma może chronić sekret przed zwykłymi współpracownikami, zachowując jednocześnie uprzywilejowany dostęp wewnętrzny niezbędny do uruchamiania obciążeń.

Klienci potrzebują zatem czegoś więcej niż stwierdzenia, że sekrety są ukryte w interfejsie. Muszą rozumieć, które systemy mogą pobierać lub używać tych sekretów oraz na jakiej podstawie.

Szyfrowanie również wymaga kontekstu. Szyfrowanie danych w spoczynku chroni przechowywane dane w określonych warunkach. Samo w sobie nie wyjaśnia, co dzieje się, gdy autoryzowana aplikacja lub przejęty uprzywilejowany komponent zażąda odszyfrowanej zawartości.

Sformułowanie Railway czyni to rozróżnienie istotnym, nie ustanawiając przy tym uniwersalnej awarii szyfrowania. Powiadomienie opisywało możliwy dostęp do zaszyfrowanych zmiennych i części odszyfrowanej zawartości. Dalsze wnioski techniczne wymagają dodatkowych dowodów.

Po drugiej stronie tego kompromisu istnieje uzasadniona korzyść. Scentralizowane zarządzanie poświadczeniami może ograniczyć nieformalne udostępnianie i ułatwić zarządzanie dostępem zespołowym.

Przeniesienie każdego poświadczenia na indywidualne maszyny wprowadziłoby inne problemy zarządcze. Październikowe ujawnienia nie wskazują uniwersalnie preferowanej lokalizacji przechowywania. Ustalają, że lokalizacja zmienia granicę zaufania, którą klienci muszą ocenić.

Rozróżnienie OpenCode między środowiskiem hostowanym a lokalnym jest przydatne właśnie dlatego, że precyzuje tę granicę. Zakres zadań ewaluacyjnych Fireworks oraz wyłączenia usług Lightning służą podobnemu celowi.

Wzorzec Wiz Black October stawia więc ostrzejsze pytanie zakupowe niż to, czy platforma „obsługuje sekrety”. Nabywcy muszą wiedzieć, jak usługa ogranicza uprzywilejowany dostęp i powstrzymuje ekspozycję, gdy ten dostęp zawiedzie.

Najlepsza odpowiedź produktowa zapewniałaby wygodną współpracę, jednocześnie ograniczając zakres uprawnień związanych z każdym ujawnionym poświadczeniem. To, czy poszczególni dostawcy spełniają ten standard, wymaga dowodów specyficznych dla danego produktu.

Błędy w cyklu życia poświadczeń mogą przetrwać początkową naprawę

Zastąpienie sekretu pomaga tylko wtedy, gdy stary dostęp zostaje zakończony, a nowy pozostaje poza zasięgiem atakującego.

Wstępny raport Zeabur zawiera szczegółowy opis niepowodzeń w zarządzaniu poświadczeniami. Firma przypisała incydent długoterminowym poświadczeniom administracyjnym przechowywanym w postaci zwykłego tekstu i możliwym do użycia z publicznego internetu.

Jej analiza naruszenia poświadczeń opisała również luki we wcześniejszych działaniach związanych z rotacją. Nie wszystkie poświadczenia wykorzystane w październikowym incydencie zostały objęte reakcją na incydent z sierpnia.

Kolejna sekwencja dotyczyła kopii zapasowych. Zeabur podał, że zastępcze poświadczenie trafiło do kopii zapasowej, a później zostało użyte bez upoważnienia. Firma rozróżniła potwierdzone zdarzenia od ocen dotyczących sposobu, w jaki atakujący uzyskał kopię zapasową.

Te szczegóły są istotne, ponieważ opisują odzyskiwanie jako sekwencję zależności. Utworzenie nowego poświadczenia jest działaniem. Ustalenie, że atakujący nie może go pobrać, jest odrębnym rezultatem.

Szerszy wniosek ma charakter analityczny, a nie stanowi twierdzenia o każdym październikowym incydencie. Reakcja może sprawiać wrażenie kompletnej na poziomie aplikacji, a jednocześnie pozostawić stare poświadczenie ważne w innym miejscu.

Podobnie nowy sekret może zostać zapisany w lokalizacji, która pozostaje narażona. W takim przypadku rotacja zmienia wartość, niekoniecznie zmieniając relację dostępu.

Dlatego aktualizacje dotyczące incydentów powinny wyjaśniać powstrzymanie zagrożenia obok wymiany poświadczeń. Klienci potrzebują pewności, że ścieżka użyta do uzyskania sekretów została zamknięta, zanim założą, że nowe wartości rozwiązują problem.

Kopie zapasowe komplikują tę ocenę, ponieważ zachowują wcześniejsze stany. Ich wartość przy odzyskiwaniu zależy od przechowywania informacji, które systemy produkcyjne mogą później usunąć lub zastąpić.

Nie oznacza to, że kopie zapasowe są z natury niebezpieczne. Oznacza to, że dostęp do kopii zapasowych należy uwzględnić w tej samej analizie poświadczeń co dostęp do działającej usługi.

Raport Zeabur jest szczególnie użyteczny, ponieważ rozdziela poziomy pewności. Zarejestrowany odczyt, ocenione pobranie i niepotwierdzona możliwość to różne ustalenia.

Czytelnicy powinni zachować te rozróżnienia podczas oceny wpływu. Zapis wskazujący dostęp do kontenera nie potwierdza automatycznie zawartości każdego zwróconego wyniku. Brak logów także nie dowodzi, że dostęp nigdy nie nastąpił.

Ta dyscyplina dowodowa ma konsekwencje biznesowe. Klienci decydujący, czy wznowić wrażliwe obciążenia, potrzebują jasnego wyjaśnienia tego, co śledczy zaobserwowali, oraz tego, co pozostaje nieznane.

Stwierdzenie, że poświadczenia zostały zrotowane, daje ograniczone zapewnienie bez informacji o zakresie. Stwierdzenie, że dostęp został zablokowany, daje ograniczone zapewnienie bez wskazania, które ścieżki dostępu zbadano.

Żadne z tego nie wymaga nowej luki specyficznej dla AI. Zwykłe uprawnienia administracyjne stają się szczególnie istotne, gdy zapewniają dostęp do poświadczeń innych usług.

Presja konkurencyjna na platformy jest zatem konkretna. Dostawcy muszą wykazać, że ich proces odzyskiwania obejmuje połączony dostęp, który klienci faktycznie im powierzyli.

Przekonująca odpowiedź wyjaśni granice incydentu, granice naprawy oraz dowody łączące te dwa elementy.

Roje agentów i destylacja pozostają odrębnymi twierdzeniami

Dowody silniej uzasadniają obawy dotyczące ujawnienia poświadczeń niż jednolite wyjaśnienie tożsamości atakującego, automatyzacji lub motywu.

Wiz informuje, że Fireworks, OpenCode i Warp opisały przesłanki wskazujące na ataki z użyciem rojów agentów, czyli ataki angażujące skoordynowanych agentów AI. Zauważa również, że OpenCode i CommandCode powiązały swoje incydenty z destylacją.

Destylacja wykorzystuje wyniki modelu do trenowania innego modelu. Ten możliwy motyw różni się od odsprzedaży poświadczeń lub nieuprawnionego użycia do zwykłych obciążeń.

Te wyjaśnienia mogą się pokrywać, lecz pokrywanie się nie jest dowodem. Atakujący może ukraść dostęp i przekazać go komuś innemu. Cel ostatecznego użytkownika nie ustala automatycznie celu pierwotnego intruza.

Publiczna charakterystyka OpenCode zasługuje na przypisanie z tego samego powodu. Określenie incydentu jako związanego z destylacją nie ustala, kto zażądał wyników ani jak śledczy doszli do tego wniosku.

The Hacker News podał, że istotne szczegóły techniczne pozostały nieujawnione. Czytelnicy nie powinni zatem traktować opisu firmy jako niezależnie ustalonego wyjaśnienia całego incydentu.

Podobnie zautomatyzowana aktywność nie musi dowodzić autonomicznego podejmowania decyzji. Szybkie wykonanie, powtarzające się żądania i aktywność równoległa mogą wynikać z konwencjonalnych skryptów.

Wiarygodne przypisanie ataku roju agentów wymaga dowodów rozróżniających te możliwości. Publiczne opisy powinny wyjaśniać zaobserwowane zachowanie, zanim poproszą czytelników o zaakceptowanie szerszej etykiety.

Nie jest to powód, by odrzucać relacje dostawców. Firmy badające własne systemy mogą posiadać dowody niedostępne publicznie.

To powód, by oddzielić to, co mówią te firmy, od tego, co zewnętrzni czytelnicy mogą zweryfikować. To rozdzielenie chroni analizę przed większą pewnością, niż uzasadniają ujawnione informacje.

Wiz opisuje również dalsze nadużywanie skradzionych poświadczeń, powszechnie nazywane LLMJacking, czyli nieuprawnione użycie dostępu innej strony do modeli językowych. Jego analiza wiąże niektóre kontrole poświadczeń z infrastrukturą odsprzedaży, jednocześnie ograniczając wnioski dotyczące pierwotnych kompromitacji.

To zastrzeżenie ma kluczowe znaczenie. Dostęp do skradzionego klucza może łączyć podmiot z późniejszą aktywnością, nie dowodząc odpowiedzialności za naruszenie, które go ujawniło.

Ta sama powściągliwość dotyczy grupowania wszystkich dziewięciu ujawnień. Wspólne zainteresowanie poświadczeniami AI jest istotnym wzorcem. Nie potwierdza wspólnego operatora, współdzielonych narzędzi ani identycznych celów.

Dla obrońców to rozróżnienie zmienia kolejność priorytetów. Ważność poświadczeń i zaobserwowane użycie mogą wspierać natychmiastowe decyzje. Twierdzenia dotyczące automatyzacji i motywu wymagają własnych dowodów.

Dla dostawców zmienia to, co uznaje się za informacyjną aktualizację. Opisanie atakującego jako zaawansowanego ma mniejszą wartość operacyjną niż wyjaśnienie, jak doszło do dostępu i które mechanizmy kontroli zawiodły.

Dla czytelników właściwa sceptyczna postawa jest konkretna. Należy zaakceptować potwierdzone ujawnienie w jego udokumentowanym zakresie. Szersze twierdzenia o kampanii należy uznawać za tymczasowe, dopóki dowody ich nie połączą.

Raport Wiz Black October jest najsilniejszy, gdy czyta się go z taką dyscypliną. Jego wartość polega na wskazaniu wzorca wymagającego zbadania, bez konieczności uznawania za fakty każdego nierozstrzygniętego wyjaśnienia.

Co pokaże, że platformy się zmieniły

Kolejne istotne dowody będą wynikać z pełniejszych ujawnień, węższych uprawnień poświadczeń oraz niezależnie ocenialnych działań naprawczych.

Pierwszym sygnałem jest lepsze raportowanie techniczne. W nadchodzących miesiącach warto obserwować, czy dostawcy publikują ostateczne harmonogramy, granice dotkniętych systemów oraz wyjaśnienia sposobu, w jaki atakujący uzyskali dostęp.

Takie ujawnienia wzmocniłyby analizę, gdyby potwierdziły powtarzające się słabości związane z przechowywanymi poświadczeniami. Mogłyby również osłabić interpretację o jednolitej kampanii, ustalając niepowiązane punkty wejścia i cele.

Oba wyniki poprawiłyby zrozumienie sytuacji. Celem dalszego raportowania jest doprecyzowanie pierwotnego wzorca, a nie utrzymanie dramatycznej etykiety niezależnie od nowych dowodów.

Użyteczny raport końcowy powinien również uzgodnić wcześniejsze oświadczenia z późniejszymi ustaleniami. Jeśli zakres się rozszerza lub zawęża, klienci muszą zrozumieć, dlaczego śledczy zmienili swoją ocenę.

To ważniejsze niż długość raportu po incydencie. Szczegółowa narracja nadal może pomijać relację dostępu, która określa narażenie klienta.

Drugim sygnałem jest zmiana uprawnień poświadczeń. Warto obserwować udokumentowane zmiany produktów, które ograniczają zakres dostępu usługi hostowanej lub czas utrzymywania tych uprawnień.

Autoryzacja krótkotrwała wygasa automatycznie po określonym czasie. Wąskie uprawnienia ograniczają działania dozwolone przez poświadczenie. Są to różne sposoby ograniczania konsekwencji skopiowanego dostępu.

Sama ich obecność nie potwierdzałaby, że platforma jest bezpieczna. Dowody musiałyby pokazać, gdzie mają zastosowanie, które przepływy pracy pozostają wyłączone oraz co muszą skonfigurować klienci.

Takie zmiany wzmocniłyby argument, że dostawcy rozwiązują podstawowy kompromis. Reakcja ograniczona do wymiany ujawnionych wartości dawałaby słabsze dowody strukturalnej poprawy.

Kupujący powinni także odróżniać zapowiedziane prace od wdrożonego działania. Mapa drogowa opisuje zamiar. Zaktualizowana dokumentacja i obserwowalne egzekwowanie zasad zapewniają solidniejszą podstawę do oceny usługi.

Trzecim sygnałem są wyraźniejsze dowody dotyczące odzyskiwania i dalszego niewłaściwego użycia. Warto obserwować, czy dostawcy i dotknięci klienci wyjaśniają, czy unieważnione poświadczenia zatrzymały nieuprawnioną aktywność oraz czy zastępcze poświadczenia pozostały chronione.

Dalsze niewłaściwe użycie po ogłoszonym oczyszczeniu wymagałoby wyjaśnienia. Mogłoby obejmować niepełne unieważnienie, inne ujawnione poświadczenie lub ścieżkę dostępu, której śledczy jeszcze nie zidentyfikowali.

Opinia publiczna nie powinna zakładać, które wyjaśnienie ma zastosowanie. Istotne jest to, czy późniejsze raportowanie wyjaśnia rozbieżność za pomocą dowodów.

Odwrotnie, udokumentowane zakończenie nieuprawnionej aktywności wspierałoby skuteczność powstrzymania zagrożenia. Nadal pozostawiałoby jednak odrębne pytanie o to, jak dostawcy zapobiegną podobnemu ujawnieniu.

Dla deweloperów te sygnały sprawiają, że ocena dostawców staje się bardziej konkretna. Usługa powinna wyjaśniać granice dostępu w kategoriach odpowiadających aplikacjom i kontom, z których zespół faktycznie korzysta.

Nabywcy korporacyjni powinni oczekiwać tej jasności, zanim uznają przywróconą usługę za kompletną odpowiedź. Pracownicy wiedzy korzystający z połączonych przepływów pracy AI powinni również rozumieć, do których kont mogą dotrzeć ich narzędzia.

Wróć do ujawnień Wiz Black October, gdy dostawcy będą publikować aktualizacje, i porównuj każde nowe twierdzenie z dowodami, które je wspierają. Pytaj, które poświadczenia zostały ujawnione, gdzie nastąpiło unieważnienie i co zmieniło się, zanim udostępniono zastępczy dostęp. Oddzielaj odzyskiwanie platformy od przeglądu połączonych usług, ponieważ decyzje te opierają się na różnych zapisach. Dla zespołu deweloperskiego użytecznym rezultatem jest jaśniejszy obraz tego, kto posiada dostęp i jak ten dostęp się kończy. Dla kupującego jest to dowód, że współpraca nie wymaga już takiej samej koncentracji uprawnień. Kolejne pytanie jest konkretne: którzy dostawcy udokumentują tę zmianę wystarczająco jasno, aby klienci mogli ją zweryfikować?