CrowdStrike Blueprint Alliance stawia jedność dostawców przeciw luce tożsamości agentów AI

CrowdStrike dołączył do 11 innych założycielskich dostawców nowego sojuszu zbudowanego wokół konfliktu, którego przedsiębiorstwa nie mogą już ignorować. Agenci AI potrzebują szerokiego dostępu, aby być użyteczni, lecz ten sam dostęp utrudnia zarządzanie nimi. CrowdStrike Blueprint Alliance ma na celu wypełnienie tej luki poprzez wspólną architekturę bezpieczeństwa.

Koalicja, formalnie nazwana Blueprint Alliance, została uruchomiona 22 września 2026 roku. Jej członkowie reprezentują obszary tożsamości, infrastruktury chmurowej, cyberbezpieczeństwa, platform danych, tworzenia aplikacji i oprogramowania dla przedsiębiorstw. Ten zakres ma znaczenie, ponieważ agent może podczas realizacji jednego zadania przekraczać granice kilku z tych domen.

Ogłoszenie to coś więcej niż kolejne partnerstwo CrowdStrike w zakresie bezpieczeństwa agentów AI. Wzywa dostawców konkurujących o budżety przedsiębiorstw do wspierania wspólnego modelu operacyjnego. Model ten traktuje agentów jako identyfikowalne podmioty o ograniczonych uprawnieniach, śledzonym delegowaniu, ciągłym monitorowaniu i odwracalnym ograniczaniu skutków.

Trudniejsze pytanie brzmi, czy wspólne zasady przełożą się na interoperacyjne mechanizmy kontroli. Przedsiębiorstwa potrzebują czegoś więcej niż zgody dostawców co do terminologii. Potrzebują spójnego wykrywania, autoryzacji, rejestrowania i wyłączania działania w produktach, które nie zostały zaprojektowane jako jeden system.

CrowdStrike Blueprint Alliance łączy 12 elementów stosu agentów

Sojusz przekształca bezpieczeństwo agentów AI z funkcji na poziomie produktu w problem architektury obejmującej wielu dostawców.

12 członków założycielskich to AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Okta, Proofpoint, Salesforce, ServiceNow, Wiz i Zscaler. GE Appliances oraz World Central Kitchen pełnią funkcję doradców strategicznych.

Według oficjalnego ogłoszenia sojuszu członkowie opracują otwartą, wielodostawcową architekturę referencyjną. Prace rozwijają plan bezpieczeństwa, który Okta po raz pierwszy przedstawiła w marcu 2026 roku.

Architektura zaczyna się od czterech pytań operacyjnych:

• Gdzie znajdują się agenci organizacji?

• Co może zrobić każdy agent?

• Co robi każdy agent?

• Jak powinni reagować obrońcy?

Te pytania brzmią podstawowo. Większość firm nie potrafi jednak odpowiadać na nie konsekwentnie w różnych kontach chmurowych, platformach programowych, środowiskach programistycznych, systemach danych i narzędziach instalowanych przez pracowników.

Agent AI to oprogramowanie, które może interpretować cel, zbierać kontekst, wybierać narzędzia i podejmować działania przy ograniczonym nadzorze. Agent obsługi klienta może przeczytać zgłoszenie wsparcia, sprawdzić historię konta, zatwierdzić zwrot i zaktualizować rekord CRM.

Każdy krok wprowadza inny punkt kontroli. Agent potrzebuje tożsamości, zanim się uwierzytelni. Potrzebuje autoryzacji, zanim uzyska dostęp do rekordu klienta. Jego działania wymagają monitorowania podczas wykonywania zadania. Dostęp musi zostać odebrany po jego zakończeniu.

Zasady założycielskie odzwierciedlają tę sekwencję. Członkowie twierdzą, że każdy agent powinien otrzymać pełnoprawną tożsamość zamiast korzystać z poświadczeń człowieka. Dostęp powinien być ograniczony do zadania, a nie przyznawany na stałe. Delegowanie powinno pozostać śledzalne, gdy jeden agent wywołuje drugiego.

Sojusz apeluje również o ciągłe monitorowanie w czasie działania. Monitorowanie w czasie działania obserwuje, co agent robi podczas pracy, zamiast opierać się wyłącznie na zatwierdzeniu przed wykonaniem. Jeśli zachowanie staje się niebezpieczne, ograniczenie skutków powinno być natychmiastowe i odwracalne.

CrowdStrike wchodzi w to porozumienie od strony wykrywania i reagowania w bezpieczeństwie przedsiębiorstw. Okta wnosi mechanizmy kontroli tożsamości, podczas gdy AWS i Google Cloud reprezentują infrastrukturę. Salesforce i ServiceNow obsługują środowiska aplikacyjne, w których agenci mogą inicjować działania biznesowe.

Databricks obejmuje infrastrukturę danych, a Docker i Lovable dotyczą procesów tworzenia i wdrażania. Proofpoint, Wiz i Zscaler dodają mechanizmy kontroli komunikacji, ekspozycji chmury i dostępu do sieci.

Ten podział ról wyjaśnia, dlaczego żaden pojedynczy członek nie może dostarczyć całej architektury. Platforma tożsamości może uwierzytelnić agenta, ale nie jest w stanie automatycznie widzieć każdego późniejszego działania. Produkt bezpieczeństwa punktów końcowych lub chmury może wykrywać podejrzane zachowanie, nie kontrolując wszystkich uprawnień na wcześniejszych etapach.

Sojusz zaczyna więc od wiarygodnej diagnozy. Bezpieczeństwo agentów obejmuje systemy należące do różnych zespołów i dostarczane przez różnych dostawców. Nierozstrzygniętą kwestią pozostaje, czy dostawcy połączą swoje mechanizmy kontroli wystarczająco głęboko, aby zarządzanie było ciągłe.

Dlaczego agenci AI przekształcają znane problemy z dostępem w szybsze awarie

Agenci wzmacniają stare słabości tożsamości, ponieważ mogą ponownie wykorzystywać uprawnienia, łączyć działania w łańcuchy i działać dłużej niż sesja człowieka.

Tradycyjna automatyzacja w przedsiębiorstwach już korzysta z kont usługowych, kluczy API i tożsamości obciążeń roboczych. Zespoły bezpieczeństwa wiedzą, jak trudne mogą stać się te poświadczenia, gdy ich właściciel jest niejasny lub uprawnienia pozostają aktywne bezterminowo.

Agenci AI dodają do istniejącego problemu niepewne ścieżki decyzyjne. Ich następne działanie może zależeć od wyniku modelu, pobranej treści, odpowiedzi narzędzia lub instrukcji przekazanych przez innego agenta. Oprogramowanie może zmienić trasę działania bez zmiany deklarowanego celu.

Ta elastyczność jest źródłem użyteczności agenta. Jest też powodem, dla którego szeroki, stały dostęp stwarza szczególnie poważne ryzyko. Przejęty lub zmanipulowany agent może wykorzystywać prawidłowe uprawnienia, zachowując się poza intencją operatora.

NIST uznał ten problem tożsamości za priorytet. Jego inicjatywa dotycząca standardów agentów obejmuje bezpieczeństwo, tożsamość, interoperacyjność oraz standardy dla autonomicznych agentów tworzone pod kierownictwem branży.

Agencja opisuje agentów jako systemy zdolne do autonomicznych działań w poczcie e-mail, kalendarzach, tworzeniu oprogramowania, zakupach i innych procesach roboczych. Ich użyteczność zależy od połączeń z systemami zewnętrznymi i danymi wewnętrznymi.

Połączenia te tworzą kilka nakładających się pytań. Czy organizacja potrafi odróżnić agenta od pracownika, który go uruchomił? Czy może zidentyfikować właściciela agenta i pochodzenie oprogramowania? Czy może udowodnić, jakie uprawnienie uzasadniało dane działanie?

Współdzielenie poświadczeń utrudnia uzyskanie odpowiedzi. Pracownik może połączyć asystenta za pomocą osobistego tokena firmowego. Aplikacje działające dalej w łańcuchu widzą wówczas tożsamość pracownika, nawet gdy to agent wybrał i wykonał działanie.

Taki układ osłabia rozliczalność. Aplikacja może zarejestrować prawidłowe żądanie użytkownika, nie ujawniając, czy człowiek zatwierdził konkretną transakcję. Analitycy bezpieczeństwa otrzymują technicznie poprawny log pozbawiony najważniejszego kontekstu.

Ryzyko rośnie, gdy agenci delegują pracę. Główny agent może wywołać wyspecjalizowanego agenta, który następnie uruchamia narzędzie przez odrębną usługę. Każde przekazanie może zacierać informacje o pierwotnym użytkowniku, zatwierdzonym zadaniu i pozostałym zakresie uprawnień.

Dostęp na poziomie zadania oferuje lepszy model. Agent otrzymuje wyłącznie zasoby i uprawnienia potrzebne do jednego zadania. Uprawnienie wygasa po zakończeniu zadania, jego istotnej zmianie lub naruszeniu zdefiniowanego warunku.

Jednak zasada minimalnych uprawnień staje się trudniejsza, gdy wymagana ścieżka nie jest w pełni przewidywalna. Agent badawczy może odkryć, że potrzebuje źródła danych już po rozpoczęciu pracy. Przyznanie wszystkich możliwych uprawnień niweczy cel ograniczania zakresu do zadania.

Przedsiębiorstwa potrzebują zatem dynamicznej autoryzacji. System zasad musi oceniać tożsamość, zadanie, zasób, kontekst i żądane działanie w miarę zmiany procesu roboczego. Kroki wysokiego ryzyka mogą wymagać nowego zatwierdzenia bez zatrzymywania każdego rutynowego działania.

To właśnie presja stojąca za Blueprint Alliance, wyjaśniona w praktycznych kategoriach. Firmy chcą agentów, którzy mogą działać w rozproszonych środowiskach programowych. Zespoły bezpieczeństwa potrzebują, aby te działania pozostawały przypisywalne i ograniczone przy każdym przekazaniu.

Głównym kompromisem jest użyteczny dostęp kontra kontrolowalne uprawnienia

Sojusz odniesie sukces tylko wtedy, gdy ograniczy uprawnienia agentów, nie sprowadzając każdego procesu do powtarzających się zatwierdzeń przez człowieka.

Agent bez dostępu do systemów jest niewiele więcej niż interfejsem konwersacyjnym. Agent z nieograniczonym dostępem może stać się niemonitorowanym administratorem. Wdrożenia w przedsiębiorstwach muszą działać między tymi dwiema skrajnościami.

Rozważmy agenta przygotowującego cotygodniową aktualizację sprzedażową. Może on odczytywać rekordy CRM, pobierać dane produktowe, analizować ostatnie spotkania, sporządzać rekomendacje i publikować podsumowanie. Taki proces obejmuje informacje należące do kilku systemów i zespołów biznesowych.

Agent nie potrzebuje uprawnień do usuwania rekordów klientów ani zmieniania obszarów sprzedaży. Może potrzebować dostępu do odczytu szczegółów kont, lecz tylko tymczasowego pozwolenia na opublikowanie jednego dokumentu. Jego zakres powinien wynikać z zadania.

Tożsamość stanowi podstawę tych decyzji. Organizacja potrzebuje unikalnego rekordu dla agenta, jego właściciela, twórcy i zatwierdzonych możliwości. Ta tożsamość powinna pozostać widoczna, gdy agent deleguje część pracy.

Wytyczne NIST dotyczące tożsamości wskazują, że agenci powinni mieć unikalne identyfikatory, poświadczenia i uprawnienia. Właściwości te powinny pozostać powiązane z osobą lub systemem obsługującym agenta.

Istniejące technologie oferują część podstaw. OAuth może delegować ograniczony dostęp bez udostępniania hasła. Systemy tożsamości obciążeń roboczych mogą uwierzytelniać procesy programowe. Silniki zasad mogą oceniać dostęp do zasobów według zdefiniowanych warunków.

Narzędzia te nie rejestrują jednak automatycznie intencji agenta. Ważny token może pokazywać, że oprogramowanie miało uprawnienie do wywołania API. Nie dowodzi, że wynikające z tego działanie odpowiadało zadaniu zatwierdzonemu przez użytkownika.

To rozróżnienie oddziela uwierzytelnianie od zarządzania. Uwierzytelnianie odpowiada na pytanie, kto lub co przedstawiło poświadczenie. Autoryzacja określa, co dana tożsamość może zrobić. Zarządzanie łączy te uprawnienia z własnością, celem, nadzorem i przeglądem.

Zachowanie w czasie działania dodaje kolejną warstwę. Agent może rozpocząć pracę zgodnie z zasadami, a następnie pobrać z dokumentu złośliwe instrukcje. Pośrednie wstrzyknięcie promptu występuje, gdy niezaufana treść manipuluje modelem za pośrednictwem danych, które agent miał przetworzyć.

Bezpieczna architektura musi zakładać, że zatwierdzenie przed wykonaniem nie wystarcza. Monitorowanie powinno porównywać działania agenta z jego zadeklarowanym zadaniem i dozwolonymi granicami. Obrońcy potrzebują również możliwości wstrzymania lub zakończenia wykonywania.

Odwracalność jest szczególnie ważna. Zatrzymanie agenta zapobiega kolejnym działaniom, ale nie cofa wiadomości, zmiany w bazie danych ani transakcji zewnętrznej. Systemy potrzebują mechanizmów wycofywania zmian wszędzie tam, gdzie wspiera je aplikacja bazowa.

Niektórych działań nie można odwrócić. Ujawniony sekret nie może ponownie stać się prywatny. Płatność wysłana poza organizację może nie wrócić natychmiast. Niszczycielskie polecenie może usunąć dane, zanim monitorowanie wygeneruje alert.

Blueprint Alliance nie może rozwiązać tych zależnych od aplikacji ograniczeń jednym mechanizmem kontroli. Może określić, w jaki sposób produkty wymieniają sygnały dotyczące tożsamości, autoryzacji, telemetrii i reagowania. Każda platforma nadal musi egzekwować odpowiednie działanie.

Dlatego podstawowe napięcie jest kompromisem, a nie prostą luką techniczną. Szerszy dostęp zwiększa możliwości agentów. Silniejsze ograniczenia zmniejszają ekspozycję, ale mogą także przerywać procesy robocze i zwiększać obciążenie związane z zatwierdzaniem.

Najlepszym rozwiązaniem nie jest nieograniczona autonomia ani stałe potwierdzanie przez człowieka. Jest nim autonomia warunkowa, w której działania niskiego ryzyka są realizowane, a wrażliwe kroki uruchamiają bardziej rygorystyczne kontrole. Osiągnięcie tej równowagi wśród 12 dostawców wymaga czegoś więcej niż zgody co do zasad.

Bezpieczeństwo agentów AI CrowdStrike obejmuje teraz kilka sojuszy

CrowdStrike buduje szeroką pozycję w zakresie bezpieczeństwa agentów, jednak nakładające się koalicje mogą również powodować niejasności dotyczące rezultatów.

Blueprint Alliance różni się od Open Secure AI Alliance, do którego CrowdStrike dołączył wcześniej w 2026 roku. Nazwy brzmią podobnie, a obie inicjatywy dotyczą bezpieczeństwa AI, lecz ich deklarowane podejścia są odmienne.

27 lipca CrowdStrike określił się jako partner założycielski otwartej koalicji bezpieczeństwa. Wspierana przez Nvidia inicjatywa kładzie nacisk na otwarte modele, wspólne badania, narzędzia bezpieczeństwa, ewaluację i zbiorową obronę.

Blueprint Alliance koncentruje się wężej na architekturze wielodostawcowej dla agentów przedsiębiorstw. Jej główne obszary to wykrywanie, tożsamość, dostęp o ograniczonym zakresie, śledzalne delegowanie uprawnień, monitorowanie w czasie działania oraz izolowanie zagrożeń.

CrowdStrike oferuje również własne produkty do tworzenia agentów i zapewniania ich bezpieczeństwa. Charlotte AI AgentWorks umożliwia organizacjom budowanie niestandardowych agentów bezpieczeństwa w ramach platformy Falcon. CrowdStrike twierdzi, że środowisko obejmuje mechanizmy zarządzania i zabezpieczenia.

Firmowy ekosystem AgentWorks obsługuje modele i infrastrukturę kilku dostawców. Daje to CrowdStrike bezpośredni interes komercyjny w zasadach regulujących agentów przedsiębiorstw.

Udział w produktach, partnerstwach dwustronnych i koalicjach może wzmacniać wpływ CrowdStrike. Zapewnia firmie dostęp do kilku poziomów dyskusji technicznej — od otwartych badań nad bezpieczeństwem po egzekwowanie zasad w przedsiębiorstwach.

Może jednak również rozpraszać uwagę. Przedsiębiorstwa mają obecnie do czynienia z wieloma sojuszami, ramami, architekturami produktów i proponowanymi standardami. Podobne słownictwo nie gwarantuje zgodnej implementacji.

Architektura referencyjna dokumentuje komponenty i ich relacje. Niekoniecznie zapewnia protokół, certyfikację, zestaw testów ani integrację produkcyjną. Nabywcy powinni odróżniać zgodność architektoniczną od potwierdzonej interoperacyjności.

Szeroki zakres Blueprint Alliance jest zaletą, jeśli członkowie zapewnią działające połączenia między swoimi systemami. Staje się słabością, jeśli każdy dostawca odwzoruje zasady w istniejących produktach bez wspólnego zachowania technicznego.

Na przykład każdy członek może popierać ideę wykrywania agentów, używając jednocześnie różnych identyfikatorów i formatów inwentarza. Każdy może opowiadać się za izolowaniem zagrożeń, udostępniając jednak niezgodne mechanizmy wyłączania.

Grupa będzie potrzebować konkretnych definicji. Co jest uznawane za agenta? Jak rejestrowany jest efemeryczny podagent? Który system posiada autorytatywną tożsamość? W jaki sposób delegowane uprawnienia przemieszczają się między granicami chmury i aplikacji?

Potrzebuje również wspólnego modelu zdarzeń. Monitorowanie w czasie działania jest mniej użyteczne, jeśli jeden produkt nie potrafi interpretować telemetrii drugiego. Reagowanie na incydenty spowalnia, gdy zespoły muszą odtwarzać łańcuchy tożsamości i autoryzacji na podstawie niepowiązanych logów.

Istotna będzie także niezależna walidacja. Dostawcy założycielscy mają zachęty, by kształtować powstający rynek wokół swoich platform. Ich udział jest cenny, ale nie zastępuje testów przeprowadzanych przez klientów, badaczy ani organizacje standaryzacyjne.

Strategiczni doradcy GE Appliances i World Central Kitchen mogą pomóc utrzymać powiązanie prac z rzeczywistymi operacjami. Środowiska produkcyjne, logistyka humanitarna i oprogramowanie dla przedsiębiorstw cechują się różnym poziomem tolerancji dla opóźnień, autonomii i awarii.

Mimo to dwóch doradców nie może reprezentować każdego modelu wdrożenia. Transakcje finansowe, procesy ochrony zdrowia, tworzenie oprogramowania i agenci konsumenccy wprowadzają odrębne wymogi dotyczące odpowiedzialności. Architektura musi pozostać elastyczna, nie stając się przy tym nieprecyzyjna.

Dla nabywców korporacyjnych rozsądną reakcją jest zainteresowanie bez założeń. Lista członków sygnalizuje, że główni dostawcy dostrzegają wspólny problem. Nie dowodzi jeszcze, że ich produkty działają jako jeden zarządzany system.

Architektura referencyjna nie jest jeszcze egzekwowalnym standardem

Największa niepewność dotyczy tego, czy sojusz opublikuje testowalne interfejsy zamiast dokumentu projektowego zgodnego z interesami dostawców.

Ogłoszenie uruchomienia inicjatywy ustanawia zasady i strukturę koalicji. Nie ustanawia obowiązkowego standardu. Nie opisuje też organu certyfikującego ani wiążącego procesu zgodności.

To rozróżnienie ma znaczenie, ponieważ dobrowolne architektury mogą usprawniać planowanie bez zmiany zachowania produktów. Firma może deklarować zgodność z ogólnymi koncepcjami, takimi jak zasada najmniejszych uprawnień i ciągłe monitorowanie, wdrażając je jednak na różne sposoby.

Przewidywana skala sojuszu również wymaga ostrożnego przypisania źródła. W ogłoszeniu przywołano prognozę Gartnera, według której przeciętne globalne przedsiębiorstwo z listy Fortune 500 będzie do 2028 roku korzystać z ponad 150 000 agentów. Stwierdzono również, że tylko 13 procent organizacji uważa, iż posiada odpowiednie mechanizmy zarządzania.

Liczby te przedstawiono w ogłoszeniu koalicji. Nawet jeśli liczba agentów szybko wzrośnie, definicja agenta będzie miała istotny wpływ na każdy taki wynik. Trwałych asystentów, krótkotrwałych podagentów, automatyzacji i wywołań narzędzi nie należy liczyć zamiennie.

Wykrywanie staje się trudne, zanim organizacja osiągnie choćby zbliżoną skalę. Pracownicy mogą autoryzować zewnętrznych asystentów bez centralnego wdrożenia. Deweloperzy mogą tworzyć tymczasowych agentów podczas testów. Produkty SaaS mogą dodawać wbudowanych agentów w ramach rutynowych aktualizacji.

Inwentarz musi zatem łączyć kilka sygnałów. Systemy tożsamości mogą pokazywać poświadczenia i przyznane uprawnienia aplikacji. Platformy chmurowe mogą ujawniać obciążenia robocze. Narzędzia bezpieczeństwa mogą obserwować procesy, aktywność sieciową i zachowanie interfejsów API.

Żaden pojedynczy sygnał nie obejmuje niezawodnie każdego agenta. Agent może istnieć krótko, korzystać ze współdzielonego poświadczenia lub działać w innej aplikacji. Z tego powodu wielodostawcowa struktura sojuszu ma sens.

Interoperacyjność wprowadza jednak własne pytania dotyczące zaufania. Dostawcy muszą zdecydować, jakie dane tożsamościowe, kontekst autoryzacji i telemetrię zachowania będą wymieniać. Klienci będą potrzebować kontroli nad tym, ile wrażliwych informacji przepływa między platformami.

Fałszywe alarmy stanowią kolejne ryzyko. Zautomatyzowane izolowanie może przerwać legalną pracę, jeśli monitoring błędnie zinterpretuje nietypowe działanie. Słabe mechanizmy izolowania pozostawiają niebezpiecznego agenta aktywnego. Architektura potrzebuje sposobów kalibrowania reakcji według wpływu i poziomu pewności.

Mechanizmy kontroli przez człowieka również wymagają starannego projektu. Wymaganie zatwierdzenia każdej decyzji eliminuje znaczną część korzyści produktywności. Pozwalanie operatorom na zatwierdzanie szerokich kategorii może odtworzyć stały dostęp pod inną nazwą.

Koalicja powinna zdefiniować mierzalne właściwości. Uczestniczący produkt mógłby wykazać, że zachowuje historię delegowania podczas przekazania. Inny test mógłby zweryfikować, że cofnięte uprawnienia zatrzymują dostęp w połączonych usługach w określonym przedziale czasu.

Zestawy testów pozwoliłyby klientom porównywać implementacje. Wspólne schematy pomogłyby platformom wymieniać dane dotyczące inwentarza i aktywności. Certyfikacja mogłaby pokazać, że produkt spełnia wymagania bazowe, bez sugerowania pełnego bezpieczeństwa.

Sojusz powinien również dokumentować zachowanie w przypadku awarii. Architektura bezpieczeństwa często opisuje zamierzoną ścieżkę, poświęcając mniej uwagi niedostępnym usługom zasad, opóźnionej telemetrii lub częściowemu cofnięciu uprawnień.

Agent nie powinien uzyskiwać szerszych uprawnień dlatego, że jedna kontrola staje się nieosiągalna. Jednak reakcja domyślnego odrzucenia może zatrzymać kluczowe procesy biznesowe. Odpowiedni tryb awaryjny zależy od zadania i jego konsekwencji.

Dopóki te mechanizmy się nie pojawią, Blueprint Alliance pozostaje poważną propozycją, a nie zweryfikowaną warstwą bezpieczeństwa. Jego wartość polega na skupieniu właściwych kategorii dostawców wokół właściwych pytań. To realizacja zadecyduje, czy to zbieżne podejście zmieni poziom ryzyka.

Trzy sygnały pokażą, czy sojusz potrafi dostarczyć rezultaty

Kolejnym sprawdzianem nie będzie następne ogłoszenie członkostwa, lecz dowody, że architektura działa w niezależnie zarządzanych produktach.

Pierwszym sygnałem jest opublikowana specyfikacja techniczna. Sojusz powinien zdefiniować pola tożsamości agenta, rejestry delegowania, kontekst autoryzacji, formaty telemetrii i interfejsy reagowania.

Szczegółowa specyfikacja wzmocniłaby argument, że członkowie zamierzają budować wspólne mechanizmy kontroli. Wysokopoziomowe ramy z mapowaniami specyficznymi dla produktów osłabiłyby go, ponieważ klienci nadal potrzebowaliby niestandardowej integracji.

Drugim sygnałem jest działająca demonstracja wielodostawcowa. Wiarygodny przykład powinien śledzić jednego agenta w systemach tożsamości, chmury, danych, aplikacji i bezpieczeństwa.

Demonstracja powinna pokazywać uprawnienia ograniczone do zakresu zadania, delegowaną pracę, monitorowanie w czasie działania oraz cofnięcie uprawnień. Powinna także pokazać, jak śledczy odtwarzają łańcuch po niebezpiecznym działaniu.

Dowody te ujawniłyby, czy rozwiązanie CrowdStrike AI agent security może wykorzystywać kontekst tożsamości i aktywności pochodzący od innych członków sojuszu. Pokazałyby również, czy te systemy mogą działać na podstawie wykryć CrowdStrike.

Trzecim sygnałem są niezależne testy. NIST, korporacyjni partnerzy projektowi, badacze bezpieczeństwa lub inna neutralna grupa powinni ocenić, jak architektura radzi sobie ze współdzieleniem poświadczeń, pośrednim wstrzykiwaniem promptów, nadmiernymi uprawnieniami i przejętymi agentami.

Niezależne wyniki wzmocniłyby twierdzenia sojuszu dotyczące bezpieczeństwa. Opóźnione testy, zamknięte demonstracje lub samoocena pozostawiłyby centralne pytanie bez odpowiedzi.

Nabywcy nie muszą czekać, aby poprawiać własne mechanizmy kontroli. Mogą zinwentaryzować obecnych agentów, wyeliminować współdzielone poświadczenia, przypisać jasnych właścicieli i ograniczyć trwałe uprawnienia.

Zespoły powinny również dokumentować, które działania wymagają zatwierdzenia przez człowieka, a które mogą przebiegać automatycznie. Każdy wrażliwy proces wymaga rejestrowania, które łączy agenta, użytkownika, zadanie, uprawnienie, narzędzie i wynik.

Organizacje budujące wewnętrznych agentów mogą przechowywać materiały źródłowe, zatwierdzenia i decyzje operacyjne w przeszukiwalnej bazie wiedzy AI. Taki zapis nie zastępuje telemetrii bezpieczeństwa, lecz może zachować kontekst biznesowy stojący za wdrożeniami agentów.

CrowdStrike Blueprint Alliance jest istotny, ponieważ identyfikuje płaszczyznę kontroli, której brakuje przedsiębiorstwom. Agenci muszą być wykrywalni, indywidualnie identyfikowalni, wąsko autoryzowani, stale obserwowani i możliwi do szybkiego odizolowania.

Jego członkowie muszą teraz przełożyć ten konsensus na interoperacyjne zachowanie. Zespoły przedsiębiorstw powinny pytać dostawców o schematy, testy, gwarancje cofnięcia uprawnień i demonstracje międzyplatformowe. Odpowiedzi pokażą, czy sojusz buduje wspólną infrastrukturę, czy jedynie wspólne słownictwo.