Trzy błędy w zabezpieczeniach AI narażają przedsiębiorstwa na ryzyko

Google News zwróciło uwagę na ostrzeżenie InfoWorld dotyczące trzech konfliktów, których przedsiębiorstwa nie mogą już traktować jako teoretycznych zagrożeń związanych z AI. Zaufane modele mogą przetwarzać wrogie instrukcje, agenci mogą dziedziczyć nadmierne uprawnienia, a ekrany zatwierdzania przez ludzi mogą ukrywać autoryzowane działanie.

Ten nagłówek ma znaczenie, ponieważ firmy przechodzą od konwersacyjnych asystentów do systemów, które odczytują pliki, wywołują aplikacje, modyfikują kod i uruchamiają procesy biznesowe. Ta zmiana przekształca błędną odpowiedź w potencjalny incydent bezpieczeństwa. Główne napięcie jest teraz jasne: szybkie wdrażanie AI kontra egzekwowalne ograniczenia tego, co każdy system może widzieć i robić.

Problem nie polega na tym, że każdy model nagle stał się złośliwy. Chodzi o to, że znane mechanizmy kontroli często tracą swoje znaczenie, gdy probabilistyczne oprogramowanie znajduje się między danymi, użytkownikami, poświadczeniami i narzędziami. Niedawne incydenty z udziałem Microsoft, Google, Amazon, Anthropic, Cursor i innych dostawców pokazują, jak szybko ta luka może stać się problemem operacyjnym.

Ostrzeżenie Google News dotyczy kontroli, a nie inteligencji

Najbardziej niebezpiecznym błędem przedsiębiorstwa jest traktowanie zachowania modelu jako podstawowej granicy bezpieczeństwa.

Wpis w Google News prowadzi do nagłówka InfoWorld o trzech błędach bezpieczeństwa, które prześladują przedsiębiorstwa. Szerszy sygnał jest ważniejszy niż sezonowa oprawa tematu. Firmy łączą modele językowe z wartościowymi systemami, zanim na nowo zdefiniują granice wokół tych połączeń.

Chatbot dawniej tworzył tekst do sprawdzenia przez człowieka. Agent AI może dziś zdecydować, które narzędzie wywołać, zbudować argumentację, użyć zapisanych poświadczeń i kontynuować działanie przez kilka kroków. Ten rozszerzony zasięg zmienia błędy modelu w problemy bezpieczeństwa aplikacji.

Organizacje często reagują, umieszczając więcej instrukcji w prompcie systemowym. Nakazują modelowi, by nie ujawniał informacji poufnych, nie wykonywał niezaufanych poleceń ani nie podejmował niebezpiecznych działań. Takie instrukcje mogą poprawić zachowanie, ale nie tworzą egzekwowalnej granicy autoryzacji.

Wyjaśnia to wstrzykiwanie promptów. Wstrzyknięcie promptu to złośliwa lub wprowadzająca w błąd treść, która skłania model do wykonania niezamierzonych instrukcji. Pośrednie wstrzyknięcie dociera poprzez materiały pobierane przez model, takie jak e-mail, strona internetowa, dokument, zgłoszenie lub repozytorium.

Model musi interpretować zarówno zaufane instrukcje, jak i niezaufaną treść za pośrednictwem tego samego interfejsu języka naturalnego. W jednym kontekście może rozpoznać zdanie jako dane, a w innym potraktować podobny tekst jako polecenie. Żaden prompt nie może zmienić uprawnień przyznanych przez otaczającą aplikację.

Lista ryzyk OWASP umieszcza wstrzykiwanie promptów na pierwszym miejscu wśród ryzyk dla aplikacji opartych na dużych modelach językowych w 2025 roku. Osobno wskazuje ujawnianie informacji wrażliwych, słabości łańcucha dostaw, niewłaściwą obsługę danych wyjściowych i nadmierną sprawczość.

To rozróżnienie niesie użyteczną lekcję. Wstrzyknięcie promptu często jest wyzwalaczem, lecz o konsekwencji decyduje otaczająca architektura. Asystent z podatnością na wstrzyknięcie, który nie ma dostępu do sekretów ani zapisu, ma ograniczony promień rażenia. To samo dane wejściowe stają się poważnym problemem, gdy agent może czytać pocztę, przeszukiwać prywatne dane, wykonywać kod lub zmieniać zasoby chmurowe.

Dlatego lepsze rozumowanie modelu nie przekłada się automatycznie na lepsze bezpieczeństwo. Bardziej zdolny model może niezawodniej realizować prawidłowe plany. Może też skuteczniej poruszać się po połączonych systemach po tym, jak atakujący przekieruje jego plan.

Przedsiębiorstwa powinny zatem oceniać AI jako niezaufany komponent decyzyjny wewnątrz większego systemu bezpieczeństwa. Model może proponować działanie, ale deterministyczne mechanizmy kontroli muszą decydować, czy jest ono dozwolone. Obejmują one kontrole tożsamości, egzekwowanie polityk, izolację danych wejściowych i walidację danych wyjściowych.

Ta zasada zmienia także sposób, w jaki zespoły badają awarie. Dziwna odpowiedź nie jest jedynie problemem jakościowym, gdy model ma narzędzia. Osoby dokonujące przeglądu muszą zapytać, która tożsamość wykonała żądanie, jakie dane weszły do kontekstu i który stan zewnętrzny uległ zmianie.

Trzy błędy z nagłówka łączy brak tej warstwy kontroli. Firmy ufają modelowi, uprawnieniom wokół niego oraz procesowi zatwierdzania prezentowanemu użytkownikom. Każda warstwa może zawieść, sprawiając jednocześnie wrażenie normalnego działania.

Błąd pierwszy: traktowanie zabezpieczeń modelu jako mechanizmów kontroli bezpieczeństwa

Odmowa modelu jest preferencją behawioralną, podczas gdy reguła kontroli dostępu jest egzekwowalną decyzją.

Przedsiębiorstwa często rozpoczynają przeglądy bezpieczeństwa AI od testowania, czy model odmawia realizacji zabronionych żądań. Taka praca ma wartość, zwłaszcza w zakresie zapobiegania nadużyciom i zgodności z politykami. Nie odpowiada jednak na pytanie, czy cała aplikacja potrafi chronić sekrety lub oprzeć się zmanipulowanemu kontekstowi.

Zabezpieczenie modelu zwykle działa poprzez trening, filtrowanie, klasyfikację lub pisemne instrukcje. Środki te wpływają na odpowiedzi. Nie mogą cofnąć uprawnienia do bazy danych, skrócić czasu życia tokenu ani powstrzymać aplikacji przed przekazaniem poufnych rekordów do kontekstu.

To rozróżnienie staje się istotne, gdy wykorzystywane jest generowanie wspomagane wyszukiwaniem. Generowanie wspomagane wyszukiwaniem, czyli RAG, dostarcza modelowi wybrane dokumenty przedsiębiorstwa przed udzieleniem odpowiedzi. Model może rozumować jedynie na podstawie materiałów przekazanych przez warstwę wyszukiwania, więc uprawnienia do wyszukiwania stanowią część granicy bezpieczeństwa.

Jeśli ta warstwa zwraca dokumenty wyłącznie na podstawie trafności semantycznej, może przekraczać granice organizacyjne. Użyteczny na pierwszy rzut oka fragment może należeć do innego działu, klienta lub sprawy prawnej. Płynne podsumowanie modelu może następnie ukryć podstawowy błąd autoryzacji.

To samo ryzyko pojawia się, gdy aplikacje pobierają treści spoza przedsiębiorstwa. Agent badawczy może odczytywać strony internetowe, załączniki, zgłoszenia wsparcia i udostępnione dokumenty. Każde z tych źródeł może zawierać instrukcje zaprojektowane dla agenta, a nie użyteczne informacje dla pracownika.

Opis Microsoft dotyczący naprawionej podatności EchoLeak pokazuje wagę tej ścieżki. Firma twierdzi, że atak wykorzystywał wieloetapowe wstrzyknięcie między promptami, które w określonych warunkach pozwalało na wyprowadzenie ograniczonych danych dostępnych ofierze. Microsoft rozwiązał problem jako CVE-2025-32711.

Znaczenie wytycznych EchoLeak wykracza poza jeden produkt. Pokazały one, że asystent produkcyjny może połączyć zewnętrzną treść, dostęp wewnętrzny i zachowanie modelu w ścieżkę eksfiltracji danych.

Obrona oparta wyłącznie na promptach prosi model o wykrycie manipulacji. Obrona na poziomie systemu zakłada, że wykrywanie może zawieść. Następnie ogranicza pobierane dane, blokuje niebezpieczne kanały wyjściowe i weryfikuje każdą wrażliwą operację poza modelem.

National Institute of Standards and Technology przyjmuje podobnie szerokie spojrzenie. Jego profil generatywnej AI omawia ryzyka w projektowaniu, rozwoju, wdrażaniu, ocenie i użyciu. Nie sprowadza bezpieczeństwa AI do filtrowania modeli.

Podejście oparte na cyklu życia ma znaczenie, ponieważ aplikacje przedsiębiorstw zawierają wiele komponentów. Obejmują dostawców modeli, bazy danych wektorowych, systemy tożsamości, wtyczki, API, narzędzia monitorujące i interfejsy użytkownika. Przegląd bezpieczeństwa, który testuje wyłącznie model, pozostawia większość tego łańcucha nietkniętą.

Praktyczny test powinien rozpoczynać się od założeń dotyczących skompromitowanego kontekstu. Osoby dokonujące przeglądu mogą umieścić wrogie instrukcje w dokumentach, które aplikacja normalnie pobiera. Mogą następnie obserwować, czy agent ujawnia dane, zmienia swój cel lub próbuje wykonać nieautoryzowane wywołanie narzędzia.

Zespoły powinny powtarzać te testy po zmianie modeli, promptów, konektorów, ustawień wyszukiwania lub opisów narzędzi. Zachowanie AI może się zmienić, nawet gdy kod aplikacji wygląda na niezmieniony. Pomyślna ocena z poprzedniego kwartału nie gwarantuje, że obecny przepływ pracy zachowuje się identycznie.

Aktualizacje modeli tworzą kolejne źródło fałszywego poczucia bezpieczeństwa. Dostawca może poprawić zachowanie polegające na odmowie, jednocześnie wprowadzając inne wzorce planowania. Aplikacja, która polegała na nieudokumentowanej odmowie, może stać się mniej przewidywalna bez żadnej formalnej zmiany uprawnień.

Bezpieczniejsza architektura traktuje prompty jako jedną z warstw obrony. Łączy je z kontrolą dostępu, której model nie może przepisać. Dane wrażliwe powinny pozostawać niedostępne, chyba że użytkownik, zadanie i zasób spełniają wszystkie wyraźnie określone zasady.

Dane wyjściowe również wymagają kontroli, zanim staną się działaniami. Wygenerowane zapytanie do bazy danych powinno przejść autoryzację i walidację. Proponowany e-mail powinien zostać poddany kontroli adresata. Kod powinien wykonywać się w izolowanym środowisku z wąskim dostępem do systemu plików i sieci.

Taka struktura nie eliminuje wstrzykiwania promptów. Uniemożliwia jednak, by skuteczne wstrzyknięcie automatycznie stało się naruszeniem. To bardziej realistyczny cel dla bezpieczeństwa przedsiębiorstw.

Błąd drugi: przyznawanie agentom AI uprawnień na miarę człowieka

Agent powinien otrzymywać najmniejsze tymczasowe uprawnienie potrzebne do wykonania jednego zadania, a nie stały dostęp posiadany przez jego użytkownika.

Drugi błąd pojawia się, gdy przedsiębiorstwo łączy agenta AI z istniejącymi poświadczeniami pracownika. Takie podejście jest wygodne, ponieważ aplikacje już rozumieją te tożsamości. Daje ono jednak probabilistycznej automatyzacji zasięg zgromadzony wokół ludzkiego konta.

Pracownicy często potrzebują szerokiego dostępu, ponieważ ich obowiązki zmieniają się w ciągu tygodnia. Agent obsługujący jedno wąskie żądanie nie potrzebuje tego samego zakresu. Jeśli dziedziczy dostęp do każdej dostępnej skrzynki pocztowej, repozytorium, rekordu klienta i narzędzia chmurowego, jego promień rażenia staje się niepotrzebnie duży.

OWASP opisuje ten problem jako nadmierną sprawczość. Podatność pojawia się, gdy system AI otrzymuje zbyt wiele funkcji, zbyt wiele uprawnień lub zbyt dużą autonomię. Zmanipulowane dane wyjściowe mogą wtedy prowadzić do szkodliwych działań dotyczących poufności, integralności i dostępności.

Słowo „sprawczość” może sprawiać, że ryzyko brzmi abstrakcyjnie. W praktyce oznacza ono zwykłe uprawnienia przypisane nieprzewidywalnemu planującemu. Model wybiera wywołanie narzędzia, aplikacja dostarcza poświadczenia, a inny system akceptuje żądanie jako autoryzowane.

Tradycyjna zasada najmniejszych uprawnień nadal pozostaje właściwym punktem wyjścia. Każdy agent potrzebuje odrębnej tożsamości, zdefiniowanego zadania i krótkiej listy dozwolonych zasobów. Ta tożsamość nie powinna po cichu pożyczać dostępu powłoki programisty ani całego zasobu dokumentów kierownictwa.

Poświadczenia powinny także szybko wygasać. Klucze o długim czasie życia pozwalają, by błąd lub naruszenie utrzymywały się po zakończeniu pierwotnej sesji. Tokeny krótkotrwałe zmniejszają to okno i tworzą bardziej przejrzyste zapisy audytowe dla każdego zadania.

Dostęp do zapisu wymaga odrębnego traktowania od dostępu do odczytu. Wielu asystentów może dostarczać użyteczne podsumowania bez modyfikowania systemów źródłowych. Przedsiębiorstwa powinny zacząć od tego, a następnie dodawać ściśle ograniczone działania dopiero po przetestowaniu całej ścieżki.

Operacje o dużym wpływie wymagają granic transakcyjnych. Agent przygotowujący zwrot środków dla klienta może zgromadzić dowody i zarekomendować kwotę. Odrębna deterministyczna usługa powinna zweryfikować politykę, autoryzację, odbiorcę i limity przed dokonaniem jakiejkolwiek wypłaty.

Ten sam wzorzec dotyczy tworzenia oprogramowania. Agent może zaproponować poprawkę w tymczasowej przestrzeni roboczej. Nie powinien automatycznie dziedziczyć dostępu do danych uwierzytelniających produkcję, systemów wdrożeniowych, osobistych plików konfiguracyjnych ani niepowiązanych repozytoriów.

Dostęp sieciowy również zasługuje na ograniczenia na poziomie zadania. Agent programistyczny, który potrzebuje jedynie dokumentacji pakietu, nie powinien łączyć się z dowolnymi zewnętrznymi serwerami. Asystent badawczy może działać za pośrednictwem zatwierdzonego mechanizmu pobierania, który blokuje prywatne adresy, niebezpieczne protokoły i niezaufane pliki do pobrania.

Opisy narzędzi nie są mechanizmami kontroli uprawnień. Poinformowanie agenta, że funkcja powinna być używana wyłącznie do określonego celu, nie powstrzymuje nieautoryzowanego wywołania. Usługa odbierająca musi egzekwować, kto może ją wywołać, które argumenty są prawidłowe i które zasoby pozostają w zakresie działania.

W tym miejscu wiele programów enterprise AI zderza się z szybkością wdrażania. Zespoły produktowe chcą jednego konektora działającego w wielu przypadkach użycia. Zespoły bezpieczeństwa potrzebują odrębnych zakresów, tożsamości, dzienników i zasad zatwierdzania dla każdego istotnego działania.

To napięcie jest realne, ale szeroki dostęp nie jest jedynym wykonalnym rozwiązaniem. Przedsiębiorstwa mogą wydawać uprawnienia dla poszczególnych zadań. Uprawnienie to wąsko zdefiniowana zgoda, która autoryzuje jedno działanie wobec jednego zasobu przez ograniczony czas.

Takie podejście usprawnia również dochodzenia. Dzienniki mogą pokazać, że konkretna instancja agenta odczytała trzy zatwierdzone rekordy dla jednego zgłoszenia wsparcia. Współdzielone dane uwierzytelniające użytkownika tworzą natomiast strumień działań, który może być trudny do przypisania.

Minimalizacja danych należy do tego samego projektu. Agent nie potrzebuje całego dokumentu, gdy odpowiedź daje przefiltrowane pole. Nie potrzebuje każdego konta klienta, gdy zadanie wskazuje jedno konto.

Zespoły budujące systemy wewnętrzne z możliwością wyszukiwania szybko stają przed tym problemem. Bezpieczna techniczna baza wiedzy musi zachowywać uprawnienia źródłowe zamiast spłaszczać każdy plik do jednego indeksu bez ograniczeń.

Istotne porównanie nie dotyczy agentów i ludzi. Dotyczy stałego dostępu człowieka w porównaniu z dostępem maszyny specyficznym dla zadania. Maszyny działają szybciej, konsekwentnie powtarzają działania i mogą skalować jeden błąd na wiele rekordów.

Przedsiębiorstwa powinny odpowiednio projektować systemy. System, który może wykonać setki działań podczas jednej sesji, potrzebuje bardziej rygorystycznych ograniczeń niż osoba wprowadzająca jedną świadomą zmianę. Szybkość zwiększa zarówno produktywność, jak i skalę szkód.

Błąd trzeci: założenie, że zgoda człowieka czyni działanie bezpiecznym

Zaangażowanie człowieka daje niewielką ochronę, gdy interfejs ukrywa cel, moment lub konsekwencje proponowanego działania.

Wiele produktów enterprise AI angażuje człowieka w proces przed wykonaniem istotnych operacji. Agent wyświetla okno potwierdzenia, a użytkownik decyduje, czy kontynuować. Ten projekt wydaje się uspokajający, ponieważ odpowiedzialność pozostaje wyraźnie po stronie człowieka.

Ochrona zależy od tego, co dana osoba faktycznie może zobaczyć. Niejasny komunikat, taki jak „zezwól na tę zmianę”, nie umożliwia podjęcia świadomej decyzji. Nie zapewnia jej również ekran zatwierdzania zbudowany na treści, na którą może wpływać atakujący.

Badania GhostApproval firmy Wiz ujawniły ten problem w sześciu znaczących asystentach AI do programowania. Dotknięty zestaw obejmował Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity i Windsurf.

Według ustaleń GhostApproval złośliwe repozytorium mogło wykorzystywać dowiązania symboliczne do przekierowania pozornie lokalnej zmiany pliku poza przestrzeń roboczą. Dowiązanie symboliczne to odwołanie systemu plików kierujące jedną ścieżkę do innej lokalizacji.

Widoczne zatwierdzenie mogło wskazywać niewinny plik projektu, podczas gdy rozwiązana ścieżka prowadziła do wrażliwego pliku systemowego. W przypadku niektórych testowanych produktów Wiz poinformował, że zapisy następowały przed uzyskaniem znaczącej autoryzacji. Przekształcało to interfejs z bramki bezpieczeństwa w mechanizm cofania zmian.

Ustalenia nie oznaczają, że każda obecna wersja pozostaje podatna na atak. Wiz zgłosił poprawki lub odpowiedzi kilku dostawców, a zachowanie produktów może szybko się zmieniać. Trwałym problemem jest model zaufania ujawniony przez badania.

Zatwierdzanie przez człowieka działa wyłącznie wtedy, gdy system prezentuje kanoniczne, niezależnie zweryfikowane szczegóły. W przypadku operacji na pliku obejmują one rozwiązaną ścieżkę, typ operacji, różnicę w treści, tożsamość procesu oraz informację, czy cel znajduje się poza autoryzowaną przestrzenią roboczą.

W przypadku wiadomości użytkownicy potrzebują rzeczywistego odbiorcy, dołączonych danych i tożsamości nadawcy. W przypadku płatności potrzebują celu, kwoty, źródła autoryzacji i wyniku kontroli zasad. W przypadku zmiany w chmurze potrzebują konta, zasobu, regionu i oczekiwanego efektu.

Aplikacja musi generować te fakty na podstawie zaufanego stanu systemu. Nie powinna polegać na podsumowaniu agenta w języku naturalnym. Ten sam model, który prosi o zgodę, ma zachętę — celową lub nie — by przedstawiać działanie jako użyteczne.

Równie ważny jest moment. Zatwierdzenie musi nastąpić, zanim system zmieni stan zewnętrzny. Przycisk, który pojawia się po zapisie pliku, wywołaniu API lub wysłaniu wiadomości, nie może zapobiec zdarzeniu.

Przedsiębiorstwa muszą też unikać zmęczenia zatwierdzaniem. Jeśli użytkownicy często otrzymują prośby dotyczące nieszkodliwych operacji, uczą się akceptować je bez sprawdzania szczegółów. Atakujący mogą wtedy ukryć niebezpieczną prośbę pośród znajomych komunikatów.

Lepszym wzorcem jest zatwierdzanie oparte na ryzyku. Działania o niewielkim wpływie mogą być wykonywane w ramach ścisłych ograniczeń. Operacje wrażliwe otrzymują pełniejsze ujawnienie informacji, silniejsze uwierzytelnianie i niezależne kontrole zasad.

Niektóre działania nigdy nie powinny zależeć od jednego kliknięcia. Usunięcie danych produkcyjnych, zmiana zasad dostępu, eksport dużych zbiorów danych lub modyfikowanie danych uwierzytelniających wdrożenia mogą wymagać drugiej tożsamości lub przeglądu poza kanałem.

Nie usuwa to ludzi z procesu. Daje im decyzję, którą mogą realnie ocenić. Ludzie najlepiej sprawdzają się w osądzie, a nie w weryfikowaniu ukrytego stanu technicznego pod presją czasu.

Zespoły bezpieczeństwa powinny testować ekrany zatwierdzania w sposób adversarialny. Mogą pytać, czy długie nazwy plików ukrywają miejsce docelowe, czy formatowanie może zaciemniać ostrzeżenia oraz czy skompromitowany dokument może wpływać na wyświetlany tekst.

Powinny też badać warunki wyścigu. Stan poddany przeglądowi musi pozostać niezmieniony między zatwierdzeniem a wykonaniem. Jeśli atakujący może zastąpić plik, miejsce docelowe lub argument po zatwierdzeniu, widoczna decyzja nie obejmuje już rzeczywistego działania.

Zainteresowanie Google News bezpieczeństwem enterprise AI odzwierciedla szerszą korektę. „Człowiek w pętli” nie jest pełnym opisem kontroli. Osoby dokonujące przeglądu muszą wiedzieć, który człowiek, jakie informacje, który moment i która niezależnie egzekwowana granica są zaangażowane.

Dlaczego przedsiębiorstwa wciąż powtarzają te trzy błędy

Bodźce wdrożeniowe nagradzają widoczne możliwości AI, podczas gdy niezawodne granice pozostają wolniejsze i mniej widoczne dla kupujących.

Te trzy błędy utrzymują się, ponieważ każdy z nich oferuje wygodny skrót. Instrukcje w promptach są łatwiejsze niż przeprojektowanie kontroli dostępu. Współdzielone dane uwierzytelniające są łatwiejsze niż tworzenie tożsamości specyficznych dla zadania. Przyciski potwierdzenia są łatwiejsze niż budowanie weryfikowalnych przepływów autoryzacji.

Dema wzmacniają te skróty. Udane demo nagradza szeroki dostęp, ponieważ agent może znaleźć więcej informacji i ukończyć więcej kroków. Ograniczony dostęp powoduje więcej odmów, prac konfiguracyjnych i pozornego tarcia.

Produkcja odwraca tę kalkulację. Każdy podłączony system wprowadza kolejną relację zaufania. Każde dodatkowe uprawnienie zwiększa potencjalny wpływ. Każdy zautomatyzowany krok skraca czas dostępny obrońcy na zauważenie nietypowego zachowania.

Własność organizacyjna dodaje kolejny problem. Zespoły produktowe wybierają modele i konektory. Zespoły ds. tożsamości zarządzają danymi uwierzytelniającymi. Zespoły bezpieczeństwa monitorują zdarzenia. Zespoły prawne definiują ograniczenia dotyczące danych. Jednostki biznesowe decydują, które przepływy pracy są istotne.

Agent może przekroczyć wszystkie te domeny w trakcie jednego zadania. Jeśli żaden zespół nie odpowiada za cały łańcuch wykonania, każda grupa może zakładać, że inna kontrola powstrzyma awarię.

Zapewnienia dostawców mogą pogłębiać tę lukę. Umowy enterprise mogą obejmować retencję danych, trenowanie modeli i szyfrowanie. Te zabezpieczenia są ważne, ale nie naprawiają zbyt szerokich uprawnień klienta ani niebezpiecznego projektu przepływu pracy.

Dostawca może chronić przechowywane prompty, podczas gdy klient ujawnia wewnętrzne rekordy poprzez wyszukiwanie kontekstowe. Może izolować infrastrukturę modelu, podczas gdy przedsiębiorstwo przyznaje agentowi nadmierny dostęp do chmury. Odpowiedzialność pozostaje współdzielona w całym stosie.

Produkty bezpieczeństwa również mają trudności, gdy aktywność AI przypomina legalną pracę. Autoryzowany pracownik może poprosić zatwierdzonego asystenta o podsumowanie umowy. Ten sam przepływ pracy staje się niebezpieczny, gdy umowa zawiera ukrytą instrukcję przekierowującą agenta.

Tradycyjny monitoring widzi uwierzytelnionego użytkownika, zatwierdzoną aplikację i dozwolone żądanie danych. Brakującym sygnałem jest relacja między niezaufanym kontekstem a działaniem, które po nim nastąpiło.

Przedsiębiorstwa potrzebują bogatszych śladów tej relacji. Przydatne dzienniki rejestrują pobrane źródła, decyzje modelu, wywołania narzędzi, wyniki zasad, zatwierdzenia i wynikające z nich zmiany stanu. Wrażliwe treści można chronić, zachowując jednocześnie wystarczające dowody do dochodzenia.

Celem nie jest nieograniczony nadzór nad pracownikami. Jest nim rozliczalna automatyzacja. Ludzie powinni rozumieć, kiedy system AI uzyskuje dostęp do danych firmowych i jakie działania podejmuje w ich imieniu.

Shadow AI komplikuje tę pracę. Shadow AI oznacza korzystanie przez pracowników z niezatwierdzonych modeli, agentów lub konektorów poza normalnym zarządzaniem. Zablokowanie każdego publicznego narzędzia może wypchnąć aktywność na prywatne konta i niezarządzane urządzenia.

Lepsza odpowiedź łączy zatwierdzone alternatywy z egzekwowalnymi kontrolami na warstwach tożsamości, przeglądarki, punktów końcowych i danych. Pracownicy potrzebują praktycznej ścieżki do legalnej pracy. Zespoły bezpieczeństwa potrzebują widoczności tego, gdzie przemieszczają się chronione informacje.

Firmy powinny również oddzielać eksperymenty od produkcji. Piaskownica może zapewnić dane syntetyczne, jednorazowe dane uwierzytelniające, izolowane sieci i ograniczone narzędzia. Udane eksperymenty mogą następnie przejść przez jawne modelowanie zagrożeń, zanim otrzymają rzeczywisty dostęp.

Proces ten wymaga więcej niż listy kontrolnej zgodności. Każdy przepływ pracy potrzebuje scenariusza nadużycia. Osoby dokonujące przeglądu powinny pytać, co się stanie, gdy pobrana treść kłamie, model wybierze niewłaściwe narzędzie lub użytkownik zatwierdzi wprowadzającą w błąd prośbę.

Powinny następnie przetestować odzyskiwanie. Czy przedsiębiorstwo może natychmiast unieważnić tożsamość agenta? Czy może zidentyfikować zmienione rekordy? Czy może cofnąć działania bez zaufania temu samemu modelowi, który je spowodował?

Najsilniejszym kontrargumentem jest to, że te kontrole spowolnią wdrażanie. To prawda w przypadku niektórych wdrożeń. Nierozwiązane wady uprawnień i zatwierdzania powodują jednak opóźnienia później — poprzez reagowanie na incydenty, awaryjne ograniczenia i utratę zaufania.

Kolejna niepewność dotyczy samych modeli. Dostawcy nadal ulepszają obsługę instrukcji i wykrywanie ataków. Ulepszenia te mogą ograniczyć skuteczną manipulację, ale nie uzasadniają usuwania deterministycznych ograniczeń.

Bezpieczeństwo enterprise powinno poprawiać się wraz ze zmianami modeli, a nie zależeć od tych zmian. Dobrze zaprojektowana aplikacja staje się bezpieczniejsza dzięki lepszemu modelowi, pozostając jednocześnie ograniczona, gdy model zawiedzie.

Na co liderzy bezpieczeństwa powinni zwracać uwagę w następnej kolejności

Kolejny etap będzie mierzony projektem uprawnień, niezależnymi testami i przejrzystością incydentów, a nie wynikami odmów modeli.

Pierwszym sygnałem jest to, czy dostawcy publikują istotne analizy powdrożeniowe dotyczące incydentów bezpieczeństwa agentów. Przydatne ujawnienia opisują początkowe dane wejściowe, dostępne narzędzia, dane uwierzytelniające, awarię mechanizmów ograniczających i końcowy wpływ. Niejasne odniesienia do „nieoczekiwanego zachowania” dają niewiele wskazówek.

Sekcje postmortem powinny również wyjaśniać, co zmieniło się po incydencie. Nowy prompt jest słabszym dowodem niż cofnięte uprawnienie lub przeprojektowana bramka autoryzacyjna. Liderzy ds. bezpieczeństwa powinni odróżniać dostrajanie zachowania od naprawy architektury.

Drugim sygnałem jest wdrażanie mechanizmów tożsamości przeznaczonych dla agentów. Przedsiębiorstwa potrzebują odrębnych tożsamości maszynowych, krótkotrwałych poświadczeń, zakresów dostępu na poziomie zasobów oraz możliwości awaryjnego cofnięcia uprawnień. Produkty, które jedynie podszywają się pod użytkownika, pozostawiają ważne pytania bez odpowiedzi.

Nabywcy powinni pytać, czy jeden agent może podczas zadania uzyskać dostęp do niepowiązanych aplikacji. Powinni żądać dowodów, że polityka bezpieczeństwa obowiązuje przy każdym wywołaniu narzędzia. Powinni również sprawdzić, czy logi łączą działania z użytkownikiem i sesją, z których się wywodzą.

Trzecim sygnałem są powtarzalne testy regresji bezpieczeństwa. Testowanie regresji AI sprawdza, czy znane ataki powracają po zmianach modeli, promptów, narzędzi, mechanizmów wyszukiwania lub uprawnień. Powinno być wykonywane przed wdrożeniem i po każdej istotnej aktualizacji.

Testy te wymagają realistycznych, wrogich treści. Zespoły powinny umieszczać ataki w e-mailach, stronach internetowych, dokumentach, repozytoriach i odpowiedziach narzędzi. Bezpośrednie prompty użytkowników obejmują tylko część powierzchni wejściowej aplikacji.

Niezależne badania pozostaną niezbędne. Oceny dostawców często koncentrują się na normalnym użyciu i znanych atakach. Zewnętrzni badacze inaczej podchodzą do granic zaufania, czego przykładem są EchoLeak i GhostApproval.

Zespoły zakupowe mogą wspierać tę pracę, pytając o programy ujawniania luk, terminy reakcji i opublikowane działania naprawcze. Reakcja produktu na badania mówi o nim tyle samo, co jego marketing dotyczący bezpieczeństwa.

Google News będzie nadal pokazywać alarmujące incydenty związane z AI, ponieważ agenci uzyskują dostęp do coraz bardziej wrażliwych systemów. Użyteczną odpowiedzią nie jest panika ani całkowity zakaz. Jest nią zmiana sposobu, w jaki przedsiębiorstwa definiują bezpieczne wdrożenie.

Traktuj model jako niezaufany. Daj agentowi mniej dostępu niż osobie, która nim kieruje. Dopilnuj, by ekrany zatwierdzania ujawniały niezależnie zweryfikowane fakty, zanim cokolwiek zostanie zmienione.

Liderzy ds. bezpieczeństwa powinni teraz wybrać jeden połączony przepływ pracy AI i prześledzić go od danych wejściowych do końcowego działania. Która kontrola nadal działa, jeśli model wykona wrogą instrukcję? Odpowiedź pokaże, czy przedsiębiorstwo ma architekturę bezpieczeństwa AI, czy jedynie obietnicę bezpieczeństwa AI.