Wewnętrzne zagrożenia ze strony agentów AI stawiają zaufany dostęp w centrum bezpieczeństwa

Agenci AI przekroczyli krytyczną granicę: mogą dziś używać zaufanych poświadczeń do odczytywania danych, wywoływania narzędzi i zmieniania systemów przedsiębiorstwa bez stałego nadzoru.

Ta zmiana przekształca wewnętrzne zagrożenie ze strony agenta AI z kwestii bezpieczeństwa modelu w problem kontroli dostępu. Agent nie musi mieć złośliwych intencji, aby ujawnić rekordy, wysłać nieautoryzowane wiadomości lub uruchomić niebezpieczny proces. Wystarczą mu legalne uprawnienia, szkodliwa instrukcja i dostateczna autonomia działania.

Najnowsza argumentacja Cybersecurity Insiders dobrze ujmuje to odwrócenie perspektywy. Przedsiębiorstwa dotąd traktowały AI jako oprogramowanie wymagające ochrony przed zewnętrznymi atakującymi. Zespoły bezpieczeństwa muszą teraz rozważyć, czy samo oprogramowanie może stać się zaufanym, lecz niebezpiecznym operatorem.

Nie oznacza to, że każdy agent powinien być klasyfikowany jako wrogi. Oznacza to, że organizacje nie mogą już uznawać uwierzytelnienia za dowód bezpieczeństwa działania. Prawidłowa tożsamość odpowiada na pytanie, kto lub co zażądało dostępu. Nie potwierdza jednak, czy żądane działanie odpowiada rzeczywistym intencjom użytkownika.

Wyłaniająca się rywalizacja nie toczy się więc między ludźmi a maszynami. Chodzi o szeroki, trwały dostęp kontra wąskie, specyficzne dla zadania upoważnienie. Zespoły bezpieczeństwa muszą zdecydować, czy agenci odziedziczą liberalne wzorce dostępu stworzone dla pracowników i tradycyjnych aplikacji.

Odpowiedź zadecyduje o tym, czy wdrażanie agentów przyniesie kontrolowaną automatyzację, czy nową klasę trudnych do wykrycia incydentów wewnętrznych.

Wewnętrzne zagrożenie ze strony agenta AI zaczyna się od legalnego dostępu

Definiującym ryzykiem nie jest to, że agent AI przełamuje perymetr, lecz że działa poprzez dostęp celowo przyznany mu przez przedsiębiorstwo.

Tradycyjne programy zarządzania ryzykiem wewnętrznym koncentrują się na pracownikach, wykonawcach i przejętych kontach. Podmioty te już znajdują się wewnątrz granicy zaufania. Mogą niewłaściwie wykorzystywać dane lub systemy bez wykorzystywania podatności dostępnej z zewnątrz.

Agenci zaskakująco dobrze pasują do tego modelu. Mogą posiadać zgody OAuth, tożsamości usługowe, dostęp do API, uprawnienia do baz danych i delegowane uprawnienia. Mogą też łączyć te przywileje w ramach wieloetapowego procesu.

Agent mający przygotować prezentację sprzedażową może przeszukiwać dane klientów, pobierać wewnętrzne notatki i redagować e-mail. Agent programistyczny może odczytać repozytorium, otworzyć terminal, modyfikować pliki i przesłać pull request. Agent wsparcia może sprawdzić informacje o koncie i zainicjować zwrot środków.

Każde pojedyncze uprawnienie może wyglądać rozsądnie. Niebezpieczna zdolność pojawia się, gdy agent łączy je w nieoczekiwanej sekwencji.

To podstawowa różnica między agentem a tradycyjną aplikacją. Tradycyjne oprogramowanie zwykle podąża z góry określonymi ścieżkami. Agent interpretuje cel, wybiera narzędzia i określa kroki pośrednie w czasie działania.

Ta elastyczność tworzy wartość, ale jednocześnie osłabia założenia zapisane w starszych mechanizmach kontroli. Uprawnienie przyznane dla jednego zamierzonego procesu może obsługiwać kilka niezamierzonych procesów. Agent może odkrywać takie ścieżki szybciej niż ludzki operator.

Prompt injection dodatkowo zaostrza problem. Prompt injection to atak polegający na umieszczaniu zwodniczych instrukcji w danych odczytywanych przez system AI. Agent może pomylić te instrukcje z częścią powierzonego mu zadania.

Wyobraźmy sobie asystenta przeglądającego dokumenty z zewnętrznego folderu. Dokument zawiera ukryty tekst nakazujący asystentowi pobrać poufne pliki i wysłać ich zawartość w inne miejsce. Agent może się zastosować, ponieważ oba działania wykorzystują zatwierdzone narzędzia.

System może zarejestrować pomyślne logowanie, ważny token i dozwolone wywołania API. Konwencjonalne monitorowanie widzi autoryzowaną aktywność. Firma widzi wyciek danych.

Wskazówki OWASP dotyczące zagrożeń agentowych identyfikują ryzyka wynikające z autonomicznego planowania, użycia narzędzi, pamięci i interakcji między agentami. Nie są to odizolowane zachowania modelu. To ryzyka na poziomie systemu, tworzone przez połączenie modelu z uprawnieniami.

Ten sam problem pojawia się, gdy agent otrzymuje niedokładnie określony cel. „Rozwiąż wszystkie zaległe zgłoszenia” może skłonić go do wysyłania wiadomości, zmieniania rekordów lub zamykania spraw wymagających przeglądu przez człowieka. Nikt nie musi wcześniej kompromitować modelu.

Dlatego intencja ma równie duże znaczenie jak tożsamość. Bezpieczny projekt musi określać, kto autoryzował zadanie, jakich zasobów ono dotyczy, jakie działania są dozwolone oraz jak długo dane upoważnienie pozostaje ważne.

Bez takich granic uwierzytelniony agent staje się insiderem o wyjątkowo szybkim tempie działania.

Zaufany dostęp staje się nowym perymetrem bezpieczeństwa

Agenci AI sprawiają, że zaufany dostęp jest ważniejszy niż lokalizacja sieciowa, ponieważ ich legalna praca już obejmuje aplikacje, chmury i magazyny danych.

Architektura zero trust przewidziała część tej zmiany. Standard zero trust NIST odrzuca domniemane zaufanie oparte wyłącznie na lokalizacji sieciowej lub własności zasobu. Koncentruje decyzje dotyczące bezpieczeństwa na użytkownikach, aktywach, zasobach i wyraźnej autoryzacji.

Model ten staje się pilniejszy, gdy podmiotem żądającym dostępu jest autonomiczny system. Agent może działać ponad granicami, które wcześniej spowalniały ludzkich insiderów. Nie musi przełączać urządzeń, otwierać wielu interfejsów ani ręcznie kopiować danych między aplikacjami.

Jedna instrukcja może uruchomić łańcuch wywołań narzędzi. Łańcuch ten może prowadzić od platformy komunikacyjnej przez magazyn chmurowy, następnie do bazy danych klientów i zewnętrznej usługi. Agent wykonuje tę sekwencję za pośrednictwem zaufanych integracji.

Zapora sieciowa widzi dozwolone połączenia. Systemy tożsamości widzą rozpoznane poświadczenia. Logi aplikacji pokazują operacje, które przypisane konto mogło wykonywać.

Mimo to łączny rezultat może nadal naruszać politykę.

Bezpieczeństwo musi zatem zbliżyć się do każdego działania. Autoryzacja powinna uwzględniać tożsamość agenta, jego właściciela, bieżące zadanie, żądany zasób, używane narzędzie i otaczające sygnały ryzyka.

Wymaga to odrębnej tożsamości dla każdego wdrożonego agenta. Współdzielone konta usługowe utrudniają dochodzenia, ponieważ kilka agentów może generować aktywność pod jedną nazwą. Pozwalają też na kumulowanie uprawnień, gdy nowe procesy ponownie wykorzystują to samo konto.

Dedykowana tożsamość tworzy ślad własności. Zespoły bezpieczeństwa mogą powiązać agenta z jego sponsorem, przeznaczeniem, dozwolonymi narzędziami, środowiskiem wdrożeniowym i harmonogramem przeglądów. Mogą zawiesić jeden proces bez wyłączania niezwiązanej z nim automatyzacji.

Sama tożsamość jednak nie wystarczy. Jednoznacznie zidentyfikowany agent nadal może mieć nadmierne uprawnienia. Może też wykorzystać ważne uprawnienie w niewłaściwym momencie lub dla niewłaściwego celu.

Skuteczne kontrole muszą ograniczać zarówno zakres, jak i czas trwania uprawnień. Agent przygotowujący kwartalny raport nie powinien zachowywać stałego dostępu do każdego źródła, którego użył. Powinien otrzymać wąsko określone uprawnienia dla bieżącego zadania.

Poświadczenia krótkotrwałe skracają czas dostępny na nadużycie. Dostęp just-in-time przyznaje uprawnienia w chwili rozpoczęcia zadania i odbiera je po jego zakończeniu. Polityki na poziomie narzędzi ograniczają operacje, które agent może wywoływać.

Mechanizmy te odzwierciedlają kluczową lekcję płynącą z wewnętrznego zagrożenia ze strony agenta AI. Zaufanie powinno być przypisane do konkretnego działania w konkretnych warunkach, a nie do agenta na zawsze.

Przedsiębiorstwa muszą również oddzielić odczyt od działania. Agent podsumowujący kalendarz wymaga innych uprawnień niż agent planujący spotkania. System proponujący zmiany w kodzie nie powinien automatycznie otrzymywać zgody na ich wdrożenie.

To rozróżnienie może zniknąć w okresie szybkiego wdrażania. Zespoły zaczynają od asystenta tylko do odczytu, a następnie stopniowo dodają dostęp do zapisu, kontrolę przeglądarki i automatyzację procesów. Pierwotna ocena ryzyka przestaje odpowiadać wdrożonemu systemowi.

Inwentaryzacje agentów muszą zatem śledzić możliwości, a nie tylko instalacje. Zespoły bezpieczeństwa powinny wiedzieć, którzy agenci mogą uzyskiwać dostęp do danych wrażliwych, wywoływać zewnętrzne narzędzia, komunikować się publicznie, modyfikować rekordy lub autoryzować transakcje.

Inwentaryzacja musi zmieniać się równie szybko jak sami agenci.

Dlaczego obecne mechanizmy kontroli insiderów nie wykrywają zachowań agentów

Mechanizmy zaprojektowane z myślą o ludzkiej szybkości i motywacjach mają trudności, gdy oprogramowanie może wykonywać setki legalnych działań bez zmęczenia ani wahania.

Programy zarządzania ryzykiem wewnętrznym związanym z ludźmi często szukają rozpoznawalnych zmian zachowania. Pracownik pobiera nietypowe ilości danych, loguje się o nieoczekiwanej porze lub uzyskuje dostęp do działu poza swoją zwykłą rolą.

Sygnały te nadal są przydatne, lecz agenci tworzą inną wartość bazową. Mogą działać nieprzerwanie. Mogą przetwarzać więcej rekordów niż człowiek. Ich aktywność może pochodzić ze stabilnej infrastruktury chmurowej, a nie z urządzenia końcowego pracownika.

Wysokie tempo działań może wskazywać na normalną automatyzację, a nie złośliwe zachowanie. Niskie tempo działań może mimo to ukrywać starannie ukierunkowane ujawnienie danych. Sam wolumen staje się niewiarygodnym sygnałem.

Trudniej jest również wnioskować o intencji. Ludzki użytkownik zwykle wykonuje działania w interaktywnej sesji. Osoby prowadzące dochodzenie mogą porównać te działania z obowiązkami zawodowymi, komunikacją i znanymi procesami biznesowymi.

Agent przekłada szeroką instrukcję na decyzje pośrednie. Użytkownik może nigdy nie zobaczyć tych decyzji. Końcowe działanie może dzielić od pierwotnego żądania kilka kroków.

Logi muszą zachowywać ten łańcuch. Osoby prowadzące dochodzenie powinny móc odtworzyć instrukcję użytkownika, decyzje modelu, pobrany kontekst, wybór narzędzi, wyniki autoryzacji i końcowe skutki.

Nie oznacza to przechowywania wszystkich wewnętrznych obliczeń modelu. Oznacza utrzymywanie audytowalnego zapisu istotnych działań zewnętrznych oraz uprawnień uzasadniających każde z nich.

Standardowe logi aplikacyjne często dostarczają jedynie fragmentów. Jeden system rejestruje token. Inny zapisuje zapytanie do bazy danych. Trzeci rejestruje wiadomość wychodzącą. Bez wspólnego identyfikatora zadania organizacja nie może połączyć ich w jeden proces agenta.

Problem obserwowalności narasta w systemach wieloagentowych. Jeden agent może delegować badania drugiemu, który prosi trzeci system o wykonanie narzędzia. Uprawnienia mogą przenosić się wzdłuż tego łańcucha, nawet jeśli pierwotny użytkownik nigdy nie zatwierdził każdego uczestnika.

Rekursywne zaufanie opisuje tę rozszerzającą się relację. Organizacja ufa jednemu agentowi, który ufa innej usłudze, która z kolei polega na kolejnej tożsamości lub narzędziu. Efektywna powierzchnia ataku rozciąga się na każde ogniwo.

Wewnętrzne zagrożenie ze strony agenta AI może wykorzystać ten łańcuch bez wywoływania oczywistego zdarzenia naruszenia. Przejęta odpowiedź narzędzia może wpłynąć na agenta planującego. Zatruty wpis pamięci może oddziaływać na przyszłe decyzje. Zewnętrzny dokument może przekierować zaufany proces.

Istniejące zabezpieczenia punktów końcowych i sieci nadal mają znaczenie. Mogą blokować złośliwe oprogramowanie, wykrywać podejrzane cele i izolować przejętą infrastrukturę. Nie potrafią jednak niezawodnie rozstrzygnąć, czy autoryzowane działanie biznesowe odzwierciedla zamierzony rezultat użytkownika.

Taka ocena wymaga bogatszego kontekstu.

Organizacje powinny ustanowić behawioralne wartości bazowe dla każdej roli agenta. Agent raportujący może zwykle odczytywać zatwierdzone źródła danych i zapisywać je w określonym magazynie dokumentów. Próba wysłania e-maila lub uzyskania dostępu do poświadczeń wykraczałaby poza ten profil.

Polityki mogą również wymuszać ograniczenia sekwencji. Odczyt niezaufanej strony internetowej nie powinien natychmiast autoryzować dostępu do poufnych rekordów. Zmiana wrażliwości danych powinna uruchamiać nową decyzję autoryzacyjną.

Zatwierdzanie przez człowieka pozostaje przydatne w przypadku działań o dużym wpływie. Ekrany zatwierdzania muszą jednak prezentować istotne informacje. Niejasna prośba o „kontynuowanie” nie pomaga osobie oceniającej zrozumieć, jakie dane zostaną przeniesione ani które rekordy ulegną zmianie.

Zatwierdzenie powinno wskazywać działanie, miejsce docelowe, zasoby, których dotyczy, oraz oczekiwaną konsekwencję. W przeciwnym razie człowiek staje się ceremonialnym punktem kontrolnym, a nie mechanizmem bezpieczeństwa.

Zasada najmniejszych uprawnień musi wynikać z zadania, a nie z agenta

Najbezpieczniejszy model dostępu przyznaje agentowi minimalne uprawnienia wymagane do wykonania pojedynczego zadania i wymusza nową decyzję, gdy zadanie się zmienia.

Zasada najmniejszych uprawnień od dawna stanowi fundament bezpieczeństwa. Systemy agentowe sprawiają jednak, że jej wdrożenie staje się bardziej wymagające, ponieważ ich przepływy pracy są dynamiczne.

Tradycyjna aplikacja otrzymuje uprawnienia odpowiadające stabilnemu zestawowi funkcji. Agent może wybierać różne narzędzia w zależności od żądania, pozyskanych informacji lub wyników wcześniejszego kroku.

Przyznanie mu z góry wszelkich możliwych uprawnień upraszcza rozwój. Tworzy jednak także nagromadzenie niewykorzystywanych uprawnień. Zmanipulowany agent może użyć możliwości, których bieżące zadanie nigdy nie wymagało.

Lepszą drogę oferuje autoryzacja związana z zadaniem. System ocenia zadeklarowany cel i wydaje ograniczone uprawnienie do niezbędnego zasobu. Uprawnienie to wygasa po zakończeniu kroku lub sesji.

Wzorzec zasady najmniejszych uprawnień firmy Microsoft zaleca zdefiniowanie tożsamości, zakresu, dostępu do narzędzi i audytowalności przed rozszerzaniem autonomii. Podkreśla też znaczenie dedykowanych tożsamości agentów z właścicielami ponoszącymi odpowiedzialność.

Rozważmy agenta przetwarzającego raporty wydatków. Musi on odczytać przesłane dokumenty, porównać je z polityką i przygotować rekomendację. Nie potrzebuje stałego uprawnienia do realizowania płatności.

Jeśli firma później dopuści automatyczny zwrot kosztów poniżej określonego progu, to uprawnienie do zapisu powinno być odrębne. System powinien zapisać politykę, która je autoryzowała, oraz wymagać eskalacji poza wyznaczonym zakresem.

Taki podział ogranicza szkody, gdy coś pójdzie nie tak. Złośliwa instrukcja w rachunku może wpłynąć na rekomendację. Nie powinna jednak automatycznie przyznawać możliwości przekierowania środków.

Ten sam model ma zastosowanie w pracy opartej na wiedzy. Agent badawczy może przeszukiwać zatwierdzone dokumenty zespołu, lecz miejsce docelowe jego wyników powinno pozostać ograniczone. Poufne materiały źródłowe nie powinny trafiać do publicznych promptów, zewnętrznych kanałów ani niepowiązanych projektów.

Decyzje dotyczące dostępu wymagają kontekstu danych. Etykieta pliku, członkostwo w projekcie, blokada prawna, ograniczenie dotyczące klienta lub poziom poufności mogą zmienić ocenę, czy to samo wywołanie narzędzia jest właściwe.

Organizacje tworzące bazę wiedzy AI powinny traktować granice uprawnień jako element jakości wyszukiwania. Użyteczna odpowiedź musi czerpać z istotnych informacji bez przekraczania granic własności i poufności.

Znaczenie ma także projektowanie narzędzi. Szerokie narzędzia tworzą szerokie tryby awarii. Uniwersalny konektor do bazy danych, który może wykonywać dowolne zapytania, niesie większe ryzyko niż funkcja przygotowana do zwracania zatwierdzonych pól.

Deweloperzy powinni udostępniać najwęższą użyteczną operację. Zamiast przyznawać agentowi pełny dostęp do skrzynki pocztowej, usługa może pozwalać mu pobierać wiadomości pasujące do identyfikatora sprawy. Zamiast dostępu do powłoki może udostępniać kontrolowane polecenie budowania.

Powiązanie narzędzi łączy określone tożsamości agentów z konkretnymi operacjami. Agent nie może wywołać każdej dostępnej integracji tylko dlatego, że platforma wie o istnieniu tych narzędzi.

Dane wejściowe i wyjściowe również wymagają walidacji poza modelem. Model nie powinien samodzielnie decydować, czy proponowane przez niego działanie narusza politykę.

Oddzielna warstwa polityk może analizować miejsca docelowe, klasyfikacje danych, limity transakcji i kontekst zadania. Może zablokować, przekształcić lub eskalować operację przed jej wykonaniem.

To rozdzielenie odnosi się do powszechnego błędnego przekonania na temat bezpieczeństwa agentów. Lepsze prompty i silniejsze modele mogą ograniczać błędy, ale nie mogą zastąpić egzekwowalnych granic.

Prompt jest instrukcją. Polityka autoryzacji jest mechanizmem kontroli.

To rozróżnienie ma znaczenie, ponieważ agent może błędnie zrozumieć prompt, odziedziczyć zatruty kontekst lub otrzymać sprzeczne instrukcje. Silnik polityk powinien nadal egzekwować ograniczenia, nawet gdy model zachowuje się nieprzewidywalnie.

Zero Trust pomaga, ale nie rozwiązuje problemu intencji

Zero Trust może ograniczyć zasięg działania agenta, lecz nie jest w stanie automatycznie określić, czy dozwolone działanie służy rzeczywistemu celowi użytkownika.

To kluczowy kompromis w debacie o zaufanym dostępie. Dostawcy zabezpieczeń coraz częściej przedstawiają tożsamość, dostęp warunkowy i Zero Trust jako odpowiedź na ryzyko związane z agentami. Mechanizmy te rozwiązują istotne słabości.

Zero Trust for AI firmy Microsoft rozszerza jawną weryfikację i zasadę najmniejszych uprawnień na dane AI, modele, obciążenia, użytkowników i zachowanie agentów. Microsoft opisuje też agentów, którzy zostali zmanipulowani, mają nadmierne uprawnienia lub są źle ukierunkowani, jako potencjalnych „podwójnych agentów”.

To użyteczne ujęcie, lecz organizacje powinny unikać traktowania Zero Trust jako kompletnej kategorii produktowej. NIST opisuje Zero Trust jako zestaw zasad architektonicznych, a nie pojedynczy zakup technologiczny.

Organizacja może wdrożyć nowoczesne mechanizmy kontroli tożsamości, pozostawiając jednocześnie agentom nadmierne uprawnienia. Może wymagać uwierzytelniania, ale nie odróżniać jednego zadania agenta od drugiego. Może gromadzić logi, których nikt nie analizuje.

Najtrudniejsze przypadki dotyczą działań, które są jednocześnie autoryzowane i wiarygodne.

Agent obsługi klienta może zgodnie z prawem uzyskiwać dostęp do danych klientów i wysyłać wiadomości. Agent programistyczny może zgodnie z prawem modyfikować pliki źródłowe. Agent zakupowy może zgodnie z prawem kontaktować się z dostawcami.

Złośliwa lub błędna wersja każdego z tych działań może wyglądać niemal identycznie na poziomie tożsamości.

Autoryzacja kontekstowa zmniejsza tę lukę. System może pytać, czy miejsce docelowe jest zatwierdzone, czy żądane pola są niezbędne, czy działanie odpowiada historycznemu zachowaniu oraz czy klasyfikacja danych zezwala na transfer.

Modele kontekstowe nadal generują jednak fałszywe alarmy i fałszywe negatywy. Rygorystyczne kontrole mogą przerywać użyteczne przepływy pracy. Luźne kontrole mogą zachować produktywność, jednocześnie dopuszczając szkodliwe kombinacje.

Organizacja musi zdecydować, gdzie kończy się autonomia. Zadania o niskim wpływie, które można odwrócić, mogą tolerować większą swobodę. Zadania o dużym wpływie i nieodwracalne wymagają silniejszej weryfikacji, a często także zatwierdzenia przez człowieka.

Na odwracalność należy zwrócić szczególną uwagę. Agent, który tworzy szkic wiadomości, przygotowuje artefakt możliwy do przejrzenia. Agent, który wysyła wiadomość, zmienia świat zewnętrzny. Agent rekomendujący usunięcie rekordów różni się od agenta, który faktycznie je usuwa.

Architektura bezpieczeństwa powinna odzwierciedlać te różnice.

Zespoły powinny także testować agentów jako systemy, a nie tylko jako modele. Oceny modeli mogą mierzyć, czy agent wykonuje instrukcje w kontrolowanych warunkach. Ryzyko produkcyjne zależy od narzędzi, poświadczeń, pamięci, źródeł danych i otaczających aplikacji.

Ćwiczenia red-team powinny wprowadzać złośliwe dokumenty, niejednoznaczne cele, przejęte odpowiedzi narzędzi oraz nieoczekiwane kombinacje uprawnień. Celem jest obserwacja, czy zewnętrzne mechanizmy kontroli ograniczają skutki awarii.

Framework OWASP pomaga zespołom identyfikować te zagrożenia, a model dostępu do chmury NIST wyjaśnia, jak polityki warstwy tożsamości i szczegółowe kontrole aplikacyjne wspierają Zero Trust w rozproszonych usługach.

Żaden z nich nie gwarantuje, że agent rozumie intencję biznesową. Ta niepewność musi pozostać widoczna w decyzjach wdrożeniowych.

Liderzy bezpieczeństwa powinni zatem kwestionować twierdzenia, że platforma „zabezpiecza agentów”, jeśli nie wyjaśnia zakresu. Czy wykrywa tożsamości agentów? Czy zarządza uprawnieniami? Czy analizuje wywołania narzędzi? Czy chroni prompty i dane? Czy zachowuje ślady audytowe między systemami?

Większość produktów obejmuje tylko część cyklu życia. Przedsiębiorstwa nadal będą potrzebować właścicieli polityk, procesów operacyjnych, reagowania na incydenty i kontroli specyficznych dla aplikacji.

Wewnętrzne zagrożenie ze strony agentów AI nie jest pojedynczą podatnością z jedną poprawką. Jest konsekwencją umieszczania probabilistycznych decydentów w zaufanych przepływach pracy.

Trzy sygnały pokażą, czy zaufany dostęp się poprawia

Kolejny etap bezpieczeństwa AI będzie oceniany na podstawie wdrażalnych mechanizmów kontroli i dowodów z incydentów, a nie szerszych obietnic dotyczących odpowiedzialnych agentów.

Pierwszym sygnałem będzie wdrażanie odrębnych, zarządzanych tożsamości agentów. Organizacje powinny móc wyliczyć agentów, zidentyfikować ich właścicieli, przeglądać ich uprawnienia i wyłączać ich indywidualnie.

Framework tożsamości agentów Microsoft Entra pokazuje, w jakim kierunku zmierzają główne platformy tożsamości. Obsługuje dedykowane konstrukty agentów, rejestrowanie aktywności, zarządzanie i dostęp warunkowy dla podmiotów niebędących ludźmi.

Inni dostawcy tożsamości i chmury będą pod presją, by oferować porównywalne mechanizmy kontroli w heterogenicznych środowiskach. Przedsiębiorstwa rzadko korzystają z jednej platformy agentowej lub jednego systemu tożsamości.

Postęp stanie się wiarygodny, gdy administratorzy będą mogli prześledzić pojedyncze działanie agenta we wszystkich aplikacjach bez polegania na współdzielonym koncie usługi. Jeśli dedykowane tożsamości pozostaną opcjonalne lub zależne od platformy, widoczność nadal będzie fragmentaryczna.

Drugim sygnałem będzie szersze stosowanie krótkotrwałej autoryzacji ograniczonej do zakresu zadania. Platformy agentowe powinny żądać dostępu do zdefiniowanej operacji, zamiast dziedziczyć stałe uprawnienia od użytkownika lub dewelopera.

Ta zmiana będzie wymagać lepszej integracji między systemami orkiestracji a infrastrukturą tożsamości. Platforma musi opisywać zamiar agenta w formie, którą silnik polityk może ocenić.

Interfejsy zatwierdzania także muszą się poprawić. Przed przyznaniem wrażliwych uprawnień użytkownicy powinni widzieć zasób, działanie, miejsce docelowe i oczekiwany efekt.

Jeśli dostawcy będą dostarczać te mechanizmy jako ustawienia domyślne, teza o zaufanym dostępie stanie się silniejsza. Jeśli bezpieczna konfiguracja będzie wymagać rozległej niestandardowej inżynierii, zespoły działające pod presją realizacji będą nadal wybierać szerokie uprawnienia.

Trzecim sygnałem będą publiczne dowody pochodzące z rzeczywistych incydentów i niezależnych testów. Zespoły bezpieczeństwa muszą wiedzieć, jak agenci zawodzą poza demonstracjami.

Użyteczne ujawnienia wyjaśnią początkową instrukcję, ścieżkę dostępu, zaangażowane narzędzia, mechanizm kontroli, który zawiódł, oraz moment, w którym ograniczenie skutków zadziałało. Niejasne odniesienia do niebezpiecznych wyników nie zapewnią wystarczających wskazówek architektonicznych.

Niezależne oceny powinny testować kompletne systemy agentowe pod kątem wstrzykiwania promptów, nadmiernej sprawczości, zatrutej pamięci, ujawnienia poświadczeń i manipulacji między agentami. Powinny także mierzyć, czy mechanizmy kontroli zachowują użyteczność pracy.

Raportowanie incydentów wyjaśni, które ryzyka dominują. Wstrzykiwanie promptów przyciąga znaczną uwagę, lecz błędy konfiguracji, nadmierne uprawnienia, współdzielone tożsamości i niezweryfikowane integracje mogą okazać się równie istotne.

Wynik ukształtuje priorytety wydatków i projektowania. Jeśli większość incydentów będzie dotyczyć skradzionych poświadczeń, ochrona tożsamości zyska pierwszeństwo. Jeśli prawidłowo uwierzytelnieni agenci będą wielokrotnie nadużywać dozwolonych narzędzi, głównym polem walki staną się autoryzacja w czasie działania i kontrole behawioralne.

Przedsiębiorstwa nie muszą czekać na idealne standardy. Mogą już teraz zinwentaryzować agentów, rozdzielić tożsamości, usunąć nieużywane uprawnienia, ograniczyć narzędzia, rejestrować łańcuchy działań i wymagać zatwierdzenia dla operacji nieodwracalnych.

Powinny także określić, co dzieje się, gdy agent zachowuje się nieoczekiwanie. Szybkie zawieszenie, unieważnienie poświadczeń, izolacja przepływu pracy i zabezpieczenie dowodów powinny należeć do planu reagowania na incydenty.

Praktyczne pytanie jest proste: czy Twoja organizacja potrafi wyjaśnić każde istotne działanie agenta i odebrać mu uprawnienia bez wyłączania całego procesu biznesowego?

Jeśli odpowiedź brzmi „nie”, agent cieszy się większym zaufaniem, niż architektura bezpieczeństwa może bezpiecznie obsłużyć.

Zagrożenie wewnętrzne ze strony agenta AI zmienia kolejność działań. Firmy nie mogą najpierw przyznawać szerokiego dostępu, a monitorowanie dodawać dopiero po wdrożeniu. Tożsamość, granice zadań, audytowalność i mechanizmy ograniczania skutków muszą poprzedzać autonomię.

Dla deweloperów i nabywców korporacyjnych kolejna ocena powinna wykraczać poza pytanie, czy agent ukończy demonstrację. Należy zapytać, do czego ma dostęp, kiedy te uprawnienia wygasają oraz czy niezależny mechanizm kontroli może zatrzymać końcowe działanie.

Zaufany dostęp jest dziś polem walki, ponieważ to on przekształca wynik modelu w rzeczywiste konsekwencje. Organizacje, które będą zarządzać tym przejściem, wykorzystają wartość automatyzacji bez traktowania każdego uwierzytelnionego działania jako z natury godnego zaufania.