Thales Google Cloud AI Security dodaje mechanizmy kontroli, ale autonomia podnosi stawkę

28 września Thales rozszerzył partnerstwo z Google Cloud, dodając mechanizmy bezpieczeństwa dla agentów AI, mimo że wciąż pozostają nierozstrzygnięte pytania o to, jak niezawodnie zabezpieczenia mogą ograniczać autonomiczne systemy. Integracja Thales Google Cloud AI Security łączy Thales AI Security Fabric z Gemini Enterprise. Jest ukierunkowana na interakcje między użytkownikami, agentami, modelami, danymi przedsiębiorstwa i zewnętrznymi narzędziami.

Ogłoszenie odzwierciedla szerszą zmianę w korporacyjnym wykorzystaniu AI. Asystenci przede wszystkim generowali odpowiedzi do przeglądu przez ludzi. Agenci mogą teraz wybierać narzędzia, pobierać wrażliwe dane, wywoływać API i zmieniać systemy biznesowe. Złośliwa instrukcja lub nadmierne uprawnienia mogą zatem wywołać incydent operacyjny, a nie tylko błędną odpowiedź.

Google Cloud już przedstawia Agent Gateway jako punkt kontroli połączeń między agentami a narzędziami. Thales dodaje wokół tych połączeń inspekcję, egzekwowanie polityk i wykrywanie zagrożeń. To stawia partnerstwo na tym samym strategicznym polu rywalizacji co Microsoft, Zscaler, Palo Alto Networks i inni dostawcy próbujący zdefiniować warstwę bezpieczeństwa dla agentów korporacyjnych.

Kluczowe pytanie nie dotyczy już tego, czy agenci AI wymagają dodatkowej ochrony. Wytyczne rządowe i niezależne badania bezpieczeństwa rozstrzygnęły tę kwestię. Prawdziwe pytanie brzmi, czy zintegrowana warstwa działająca w czasie rzeczywistym może konsekwentnie ograniczać agentów, nie czyniąc ich przy tym zbyt wolnymi, kosztownymi lub ograniczonymi, by wdrożenie było uzasadnione.

Co zmienia integracja Thales Google Cloud AI Security

Partnerstwo przybliża bezpieczeństwo agentów do momentu, w którym system AI odczytuje dane, wybiera narzędzie lub próbuje wykonać działanie.

Według ogłoszenia dotyczącego bezpieczeństwa, Thales AI Security Fabric zostanie zintegrowany z Google Cloud Gemini Enterprise. Thales twierdzi, że połączony system może stosować mechanizmy widoczności, nadzoru i polityki bezpieczeństwa do komunikacji obejmującej użytkowników, agentów, modele, narzędzia i informacje przedsiębiorstwa.

Zakładany zakres obejmuje kilka etapów agentowego przepływu pracy. System może kontrolować ruch trafiający do agenta, obserwować wymianę między agentem a jego modelem oraz monitorować wywołania zewnętrznych narzędzi. Ma również egzekwować ograniczenia dotyczące informacji, do których agent może uzyskać dostęp, oraz działań, które może wykonywać.

Rozróżnienia te są istotne, ponieważ agent nie jest pojedynczą, odizolowaną sesją modelu. To łańcuch decyzji, poświadczeń, źródeł danych i interfejsów oprogramowania. Każde przekazanie tworzy kolejne miejsce, w którym atakujący, błąd konfiguracji lub niewiarygodna decyzja modelu może zmienić rezultat.

Thales wskazuje wstrzykiwanie instrukcji, wyciek danych, niebezpieczne wyniki, nieautoryzowane działania i komunikację agent–agent jako kluczowe zagrożenia. Wstrzykiwanie instrukcji występuje, gdy wrogie polecenia osadzone w treści manipulują zachowaniem modelu. E-mail, dokument, strona internetowa lub odpowiedź narzędzia mogą zawierać takie instrukcje, nie zwracając uwagi użytkownika.

Proponowaną odpowiedzią partnerstwa jest ujednolicona warstwa egzekwowania zasad. Thales twierdzi, że jego platforma może wykrywać zagrożenia specyficzne dla AI, utrzymywać widoczność zachowania agentów i blokować działania naruszające politykę organizacji. Firma przedstawia również scentralizowane rejestry jako wsparcie dla przeglądów zgodności i dochodzeń dotyczących incydentów.

Rozważmy przykład ubezpieczeniowy przedstawiony przez Thales. Agent upoważniony do pomocy w rozpatrywaniu roszczeń może korzystać z danych osobowych pochodzących ze źródeł spoza zatwierdzonego zakresu. Nawet jeśli wyliczenie wypłaty wydaje się rozsądne, przepływ pracy może powodować problemy związane z prywatnością, uczciwością i zgodnością z przepisami.

Mechanizm kontroli działający w czasie rzeczywistym mógłby przeanalizować żądane źródło danych, przypisaną agentowi rolę i proponowane działanie przed zezwoleniem na kontynuowanie przepływu pracy. Mógłby odrzucić żądanie, zarejestrować próbę dostępu lub wymagać zatwierdzenia przez człowieka. Jest to inny model bezpieczeństwa niż filtrowanie wyłącznie polecenia przesłanego przez użytkownika.

Integracja opiera się również na szerszej architekturze agentowej Google Cloud. Jej ekosystem Agent Gateway oferuje nadzorowaną łączność dla ruchu użytkownik–agent, agent–agent i agent–narzędzie. Google opisał bramę jako otwarty punkt kontroli, który może współpracować z kilkoma dostawcami zabezpieczeń.

Thales nie zastępuje więc natywnych mechanizmów kontroli Google Cloud. Dostarcza wyspecjalizowaną warstwę inspekcji i egzekwowania zasad w ramach szerszej architektury. Wartość zależy od tego, jak wiele dodatkowego kontekstu może analizować oraz jak niezawodnie może interweniować, zanim ryzykowne działanie dotrze do systemu biznesowego.

Dlaczego agenci AI potrzebują mechanizmów kontroli wykraczających poza zabezpieczenia modelu

Bezpieczna odpowiedź modelu nie gwarantuje bezpiecznego przepływu pracy, gdy system może dysponować poświadczeniami i działać bez natychmiastowego nadzoru człowieka.

Tradycyjne bezpieczeństwo generatywnej AI często koncentruje się na treści. Organizacje próbują zapobiegać szkodliwym odpowiedziom, ujawnianiu poufnych danych lub nieodpowiednim poleceniom. Te obawy pozostają ważne, lecz agenci wprowadzają inną kategorię ryzyka: działania oprogramowania o rzeczywistych konsekwencjach.

Agent może otrzymać instrukcję, utworzyć plan, wybrać narzędzie i wykonać transakcję. Może wysłać wiadomość, edytować rekord klienta, zatwierdzić zwrot pieniędzy, zmodyfikować kod źródłowy lub zainicjować zmianę infrastruktury. Błąd może się rozprzestrzenić, zanim człowiek zobaczy pośrednie rozumowanie.

Ta różnica wyjaśnia, dlaczego autoryzacja w czasie rzeczywistym staje się kluczowa. Polityka powinna oceniać nie tylko to, co agent mówi, lecz także jakiej tożsamości używa, o jaki zasób wnioskuje i czy działanie odpowiada przypisanemu mu zadaniu. Decyzja może wymagać ponownego podjęcia za każdym razem, gdy przepływ pracy zmienia kierunek.

Problem staje się trudniejszy, gdy agenci współpracują. Jeden agent może zbierać informacje, podczas gdy drugi formułuje rekomendację, a trzeci wykonuje działanie. Naruszony komponent może przekazywać zmanipulowany kontekst lub żądania pozostałej części łańcucha.

Thales twierdzi, że jego mechanizmy kontroli obejmą te interakcje agent–agent. Obietnica ta odpowiada na istotną lukę, lecz o jej wartości zdecydują szczegóły wdrożenia. Zespoły bezpieczeństwa muszą wiedzieć, jak weryfikowane są tożsamości, jak reprezentowane są delegowane uprawnienia oraz jak polityki towarzyszą zadaniu w wielu agentach.

NIST zidentyfikował ten sam problem. Jego analiza bezpieczeństwa agentów z maja 2026 roku wykazała szeroką zgodę, że agenci wprowadzają nowe zagrożenia. Respondenci stwierdzili również, że znane praktyki cyberbezpieczeństwa pozostają użyteczne, ale wymagają dostosowania do systemów agentowych.

Tożsamość dobrze ilustruje tę adaptację. Konwencjonalna aplikacja często działa za pośrednictwem stabilnego konta usługi o przewidywalnych funkcjach. Agent może dynamicznie tworzyć plan i wybierać spośród kilku narzędzi w zależności od zmieniającego się kontekstu.

Przyznanie temu agentowi szerokich poświadczeń czyni go użytecznym, ale zwiększa skalę szkód wynikających z manipulacji. Ograniczenie z góry każdego uprawnienia zmniejsza ryzyko, ale może uniemożliwić agentowi wykonanie uzasadnionej pracy. Zespoły bezpieczeństwa muszą równoważyć użyteczną autonomię z ściśle ograniczonym promieniem rażenia.

Rejestry audytowe stanowią kolejne wyzwanie. Rejestrowanie wywołania narzędzia nie wystarcza, jeśli śledczy nie mogą ustalić, który użytkownik zainicjował zadanie, jakie informacje wpłynęły na agenta ani dlaczego działanie otrzymało autoryzację. Użyteczne rejestry muszą łączyć intencję człowieka, tożsamość agenta, dostęp do danych i wynikającą z tego zmianę systemu.

Podejście Thales Google Cloud AI Security rozwiązuje ten problem poprzez widoczność w całym przepływie pracy. Teoretycznie wspólna warstwa może korelować aktywność, która w przeciwnym razie pojawiałaby się w osobnych logach modelu, tożsamości, API i aplikacji.

Taka widoczność może pomóc zespołom operacji bezpieczeństwa rozpoznać nietypowe zachowanie. Agent, który zwykle odczytuje regionalne dane sprzedażowe, powinien wzbudzić uwagę, jeśli nagle zażąda danych pracowników lub nieznanego zewnętrznego punktu końcowego. Kontekst behawioralny jest wartościowy, gdy statyczne reguły nie potrafią przewidzieć każdej prawidłowej sekwencji.

Widoczność nie jest jednak ograniczaniem zagrożeń. Panel może wyjaśnić incydent po wystąpieniu szkody. Silniejsze twierdzenie zakłada, że polityki mogą zatrzymać niebezpieczne działanie w czasie rzeczywistym, nie blokując uzasadnionych wariantów, które czynią agentów użytecznymi.

Egzekwowanie zasad w czasie rzeczywistym staje się głównym polem rywalizacji

Strategiczna rywalizacja toczy się między bezpieczeństwem wbudowanym w platformę chmurową a niezależnymi mechanizmami kontroli, które obiecują spójne polityki dla modeli, agentów i narzędzi.

Google Cloud buduje ekosystem partnerów wokół Agent Gateway zamiast polegać na jednym dostawcy zabezpieczeń. Wśród opublikowanych uczestników znajdują się Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks i inni. Każdy dostawca zajmuje się inną częścią przepływu pracy agenta.

Thales wnosi do tej struktury bezpieczeństwo aplikacji i API Imperva. Deklarowany zakres obejmuje ruch klient–agent, wymianę agent–model oraz interakcje z narzędziami wykorzystującymi interfejsy takie jak Model Context Protocol. MCP to protokół umożliwiający aplikacjom AI łączenie się z zewnętrznymi danymi i możliwościami oprogramowania.

To podejście zapewnia nabywcom korporacyjnym elastyczność. Firma może korzystać z infrastruktury Google i wybrać dodatkowe mechanizmy kontroli pasujące do jej istniejących operacji bezpieczeństwa. Może również ograniczyć presję, by całkowicie polegać na zabezpieczeniach dostarczanych przez dostawcę modelu.

Kompromisem jest złożoność. Kilka produktów może kontrolować ten sam przepływ pracy z różnych perspektyw. Zespoły bezpieczeństwa muszą zdecydować, który komponent odpowiada za tożsamość, ochronę danych, analizę behawioralną, autoryzację i reagowanie na incydenty.

Nakładające się mechanizmy kontroli mogą równie łatwo tworzyć luki, jak zapewniać większą głębię ochrony. Jeden produkt może zatwierdzić żądanie na podstawie tożsamości agenta, podczas gdy inny nie ma kontekstu zadania potrzebnego do rozpoznania nadużycia. Trzeci może zarejestrować wywołanie narzędzia bez zrozumienia zwróconych wrażliwych danych.

Microsoft realizuje bardziej pionowo zintegrowaną ścieżkę. Jego strategia bezpieczeństwa agentów łączy tożsamość, politykę dostępu, nadzór nad danymi i aplikacje zwiększające produktywność. Microsoft Entra może przypisywać tożsamości agentom, podczas gdy polityki Purview regulują wrażliwe informacje w środowisku Microsoft.

Ten model oferuje wyraźniejszą ścieżkę administracyjną organizacjom już skupionym wokół usług Microsoft. Budzi również znane obawy dotyczące zależności od platformy. Mechanizmy kontroli zoptymalizowane dla aplikacji jednego dostawcy mogą zapewniać mniej spójne pokrycie, gdy przepływy pracy przekraczają granice chmur, modeli i narzędzi innych firm.

Architektura Google oparta na partnerach czyni otwartość częścią swojej oferty. Otwartość przenosi jednak pracę integracyjną na platformę i jej klientów. Polityka jest użyteczna tylko wtedy, gdy przetrwa każde przekazanie i zapewni decyzję wystarczająco szybko dla ruchu produkcyjnego.

Niezależni dostawcy stoją przed powiązanym wyzwaniem. Muszą udowodnić, że ich dodatkowa warstwa zapewnia więcej niż kolejny panel monitorowania. Kupujący będą oczekiwać egzekwowalnych polityk, użytecznych dochodzeń oraz dowodów, że mechanizmy kontroli ograniczają ryzyko bez zakłócania rutynowej pracy.

Thales ma wiarygodną pozycję, ponieważ Imperva już działa w obszarze aplikacji internetowych i API. Przepływy pracy agentów korzystają z wielu tych samych interfejsów. Istniejąca inspekcja ruchu, zarządzanie botami i ochrona API mogą stanowić podstawę do rozpoznawania klientów i kontrolowania żądań.

Zachowanie agentów wciąż różni się od konwencjonalnego ruchu aplikacyjnego. Prawidłowy agent może wysłać technicznie poprawne żądanie API w niedopuszczalnym celu. Wykrycie tej różnicy wymaga kontekstu dotyczącego intencji użytkownika, delegowanych uprawnień, wrażliwości danych oraz sekwencji wcześniejszych działań.

To właśnie tutaj presja konkurencyjna wykracza poza ugruntowane rozwiązania bezpieczeństwa webowego. Dostawcy muszą interpretować kontekst operacyjny agenta bez polegania na własnych wyjaśnieniach agenta. Zmanipulowany model może przedstawić przekonujące uzasadnienie niebezpiecznego wywołania.

Dostawcy chmurowi mają także przewagę informacyjną. Obsługują usługę modelową, warstwę tożsamości, sieć i platformę agentową. Partner musi otrzymać wystarczającą telemetrię, aby podejmować trafne decyzje, przy jednoczesnym poszanowaniu prywatności klientów i wydajności systemu.

Najsilniejsza architektura może więc mieć charakter warstwowy. Natywne mechanizmy chmurowe mogą egzekwować podstawowe zasady tożsamości i izolacji, podczas gdy wyspecjalizowane produkty analizują zachowanie aplikacji i przepływ wrażliwych danych. Zatwierdzenie przez człowieka pozostaje właściwe w przypadku decyzji nieodwracalnych lub o dużym wpływie.

O wyniku tej rywalizacji nie zdecyduje najdłuższa lista funkcji. Przedsiębiorstwa ocenią, jak dobrze każda architektura radzi sobie z mieszanymi środowiskami, delegowanymi tożsamościami i niepełnym kontekstem. Sprawdzą również, czy zespoły reagujące na incydenty potrafią odtworzyć przepływ pracy bez łączenia kilku niekompatybilnych dzienników.

Obietnica bezpieczeństwa nadal wymaga dowodów z produkcji

Thales i Google Cloud wskazują właściwe punkty kontroli, lecz ogłoszenie nie dowodzi, jak dokładnie i konsekwentnie mechanizmy te działają pod presją działań adversarialnych.

Firmy nie opublikowały w komunikacie danych dotyczących wdrożeń, pomiarów opóźnień, niezależnych ocen ani szczegółowych wskaźników fałszywych alarmów. Nie wskazują też studiów przypadków klientów pokazujących, że zintegrowana struktura skutecznie zatrzymuje ataki w środowisku produkcyjnym.

Ten brak nie podważa kierunku rozwoju produktu. Ogranicza jednak wnioski, które można wyciągnąć z premiery. Integrację należy traktować jako rozszerzoną architekturę bezpieczeństwa, a nie dowód, że przepływy pracy agentów są już bezpieczne.

Prompt injection pozostaje wymagającym testem. Wyniki red-teamingu NIST z marca 2026 r. opisują pośrednie prompt injection jako przejęcie agenta. Atakujący umieszczają wrogie instrukcje w zewnętrznych treściach, które agent później przetwarza.

Ataki te wykorzystują podstawową niejednoznaczność. Model otrzymuje zarówno prawidłowe instrukcje, jak i niezaufane informacje w podobnej formie tekstowej. Musi odróżnić dane, które powinien analizować, od poleceń, których powinien przestrzegać, nawet gdy złośliwa treść została zaprojektowana tak, aby zacierać tę granicę.

Polityki czasu wykonania mogą ograniczyć szkody. Wstrzyknięta instrukcja może skłonić agenta do zażądania poufnych danych, lecz odrębna warstwa autoryzacji nadal może odmówić realizacji tego żądania. Mechanizm kontroli nie musi dokładnie ustalać, dlaczego model podjął błędną decyzję.

To rozdzielenie jest jedną z najmocniejszych idei partnerstwa. Deterministyczne ograniczenia dostępu do danych i użycia narzędzi mogą powstrzymać awarie, których zabezpieczenia na poziomie modelu nie wychwytują. Poświadczenia o minimalnych uprawnieniach i zatwierdzenia przez ludzi mogą dodatkowo ograniczyć skutki.

Silnik polityk potrzebuje jednak dokładnego kontekstu. Musi wiedzieć, który użytkownik autoryzował zadanie, jaki cel realizuje agent oraz jakie zasoby są niezbędne. Zbyt szerokie lub źle utrzymywane polityki mogą zmienić technicznie zaawansowaną warstwę kontroli w pobłażliwą bramę dostępu.

Fałszywe alarmy powodują przeciwny rodzaj awarii. Jeśli agent wielokrotnie zatrzymuje się, oczekując na zatwierdzenie, lub traci dostęp do rutynowych danych, pracownicy mogą przestać z niego korzystać. Administratorzy mogą poluzować polityki, aż egzekwowanie zasad przestanie zapewniać realną ochronę.

Znaczenie ma również opóźnienie. Każdy etap inspekcji wydłuża czas przetwarzania. Efekt może być niewielki w pojedynczej interakcji, lecz istotny w przepływach pracy zawierających dziesiątki żądań do modelu i wywołań narzędzi. Organizacje potrzebują pomiarów z realistycznych wdrożeń wieloagentowych.

Szyfrowanie i prywatność tworzą dodatkowe napięcie. Narzędzia bezpieczeństwa potrzebują wystarczającej widoczności, aby identyfikować wrażliwe informacje i złośliwe instrukcje. Klienci będą oczekiwać jasnych wyjaśnień, które treści są analizowane, gdzie są przetwarzane, jak długo są przechowywane i kto może uzyskać do nich dostęp.

Problem wykracza poza jeden produkt. Ryzyka agentowe OWASP obejmują przejęcie celu, niewłaściwe użycie narzędzi, nadużycia tożsamości, zatruwanie pamięci, niezabezpieczoną komunikację między agentami oraz kaskadowe awarie. Żaden pojedynczy filtr ruchu nie rozwiązuje wszystkich tych kategorii.

Zatruwanie pamięci jest użytecznym przykładem. Atakujący może umieścić fałszywe lub złośliwe informacje, które agent zapisze do późniejszego wykorzystania. Mechanizm kontroli czasu wykonania może przeanalizować pierwotne dane wejściowe, lecz szkodliwy efekt może pojawić się kilka dni później w innym przepływie pracy.

Równie trudne są awarie kaskadowe. Jeden agent może wygenerować nieprawidłowy wynik, który dla innego wygląda wiarygodnie. Każde indywidualne wywołanie narzędzia może spełniać wymagania polityki, podczas gdy cały przepływ pracy zmierza ku szkodliwemu rezultatowi.

Organizacje potrzebują zatem obrony warstwowej. Powinny łączyć ograniczone uprawnienia, sandboxing, podpisane tożsamości, chronioną pamięć, zweryfikowane narzędzia, ciągłe monitorowanie i kontrolę człowieka. Testy bezpieczeństwa muszą obejmować kompletne przepływy pracy, a nie tylko odizolowane odpowiedzi modeli.

Wskazówki rządowe wzmacniają to stanowisko. Australijskie wytyczne dotyczące wdrażania agentów zalecają punkty kontroli człowieka, ciągłe monitorowanie, minimalne uprawnienia oraz wiele nakładających się warstw obrony. Zalecają także stopniowe zwiększanie autonomii.

Thales AI Security Fabric może stać się jedną z tych warstw obrony. Ogłoszenie nie uzasadnia traktowania go jako całego programu bezpieczeństwa. Kupujący powinni pytać, jak współdziała on z istniejącymi systemami tożsamości, mechanizmami kontroli rozwoju, reagowaniem na incydenty oraz procedurami zatwierdzania.

Kto odczuwa presję, gdy bezpieczeństwo agentów wchodzi do przepływu pracy

Dostawcy zabezpieczeń, platformy chmurowe i nabywcy korporacyjni stoją dziś pod presją, by przekształcić zarządzanie agentami z zapisanej polityki w egzekwowalne oprogramowanie.

Dostawcy chmurowi mierzą się z najbardziej bezpośrednimi oczekiwaniami. Chcą, aby klienci przenosili agentów z eksperymentów do operacji biznesowych, lecz wdrożenia zatrzymują się, gdy zespoły prawne i bezpieczeństwa nie potrafią określić akceptowalnych granic. Platforma, która nie umie odpowiedzieć na podstawowe pytania o tożsamość, dostęp i audytowalność, będzie mieć trudności z wrażliwymi wdrożeniami.

Odpowiedzią Google Cloud jest budowa Agent Gateway jako wspólnego punktu egzekwowania zasad i otoczenie go wyspecjalizowanymi partnerami. Thales wzmacnia tę strategię, obejmując jedną strukturą bezpieczeństwa interakcje aplikacji, API, modeli i narzędzi.

Thales musi pokazać, że ten szerszy zakres pozostaje możliwy do zarządzania. Jego propozycja wartości zależy od zapewnienia klientom spójnego widoku przez kilka warstw technicznych. Fragmentaryczne polityki lub zduplikowane alerty osłabiłyby korzyści płynące z integracji.

Konkurencyjni dostawcy zabezpieczeń stoją pod presją, by wykazać równie szerokie pokrycie. Sama ochrona promptów już nie wystarcza. Kupujący potrzebują kontroli nad poświadczeniami, wykonywaniem narzędzi, przepływem danych, pamięcią, wiadomościami między agentami i działaniami zewnętrznymi.

Dostawcy tożsamości również czeka nowy zakres pracy. Agenci potrzebują odrębnych tożsamości, ograniczonych uprawnień, możliwej do prześledzenia odpowiedzialności oraz zarządzalnych cykli życia. Tymczasowi agenci nie powinni pozostawiać trwałych poświadczeń po zakończeniu zadań.

Właściciele aplikacji ponoszą kolejne obciążenie. Muszą określić, jakie działania agent może wykonywać i w jakich warunkach. Zespoły bezpieczeństwa nie mogą tworzyć użytecznych polityk bez wkładu operacyjnego osób rozumiejących dany przepływ pracy.

Programiści będą musieli udostępniać więcej ustrukturyzowanego kontekstu. Warstwa bezpieczeństwa może podejmować lepsze decyzje, gdy wywołania narzędzi deklarują zadanie, użytkownika, żądany zasób i zamierzony efekt. Same nieustrukturyzowane prompty stanowią słabą podstawę autoryzacji.

Nabywcy korporacyjni powinni oprzeć się pokusie traktowania zakupu jako końca procesu zarządzania. Zainstalowanie struktury bezpieczeństwa nie określa akceptowalnego poziomu autonomii. Organizacje nadal muszą klasyfikować przypadki użycia, przypisywać właścicieli, definiować punkty eskalacji i testować scenariusze awarii.

Przypadki użycia o niskim ryzyku stanowią rozsądny punkt wyjścia. Agent przygotowujący raport na podstawie zatwierdzonych dokumentów wewnętrznych ma mniejszy promień rażenia niż agent wysyłający wiadomości lub modyfikujący konta klientów. Uprawnienia powinny być rozszerzane dopiero po potwierdzeniu w ocenie, że przepływ pracy pozostaje kontrolowany.

Działania o dużym wpływie zasługują na wyraźne zatwierdzenie. Transfery finansowe, zmiany produkcyjne, komunikacja prawna, decyzje personalne i ujawnianie wrażliwych danych nie powinny zależeć wyłącznie od pewności modelu. Kontrola człowieka może spowolnić przepływ pracy, ale to tarcie odzwierciedla konsekwencje błędu.

Pracownicy umysłowi powinni zwracać na to uwagę, ponieważ te mechanizmy kontroli kształtują zakres danych i działań dostępnych dla agentów w miejscu pracy. Lepsze bezpieczeństwo może pozwolić agentom dotrzeć do użytecznych informacji wewnętrznych. Źle zaprojektowane kontrole mogą natomiast albo ujawnić zbyt wiele danych, albo zablokować kontekst potrzebny do dokładnej pracy.

Pracownicy będą też potrzebować przejrzystości. Powinni wiedzieć, kiedy agent działa pod ich tożsamością, do których rekordów uzyskał dostęp i czy jego wyniki wywołują zewnętrzne zmiany. Ukryta automatyzacja utrudnia rozliczanie odpowiedzialności, gdy dochodzi do incydentu.

Szersza zmiana ma charakter organizacyjny. Bezpieczeństwo AI przechodzi od zadania związanego z oceną modeli do codziennego zarządzania tożsamościami i aplikacjami. Obejmuje to agentów tymi samymi dyscyplinami operacyjnymi, które stosuje się wobec pracowników, usług, dostawców i wdrożeń oprogramowania.

Partnerstwo Thales i Google Cloud w zakresie bezpieczeństwa AI jest ważne, ponieważ czyni tę transformację wyraźną. Jego powodzenie będzie zależeć mniej od samego ogłoszenia, a bardziej od tego, czy przedsiębiorstwa będą mogły stosować te kontrole bez tworzenia kolejnej odłączonej warstwy zarządzania.

Trzy sygnały pokażą, czy mechanizmy kontroli działają

Kolejnym sprawdzianem będą mierzalne dowody z wdrożeń, a następnie interoperacyjna tożsamość i wiarygodna ocena adversarialna.

Pierwszym sygnałem będzie wdrożenie produkcyjne z ujawnionymi wynikami. Thales lub Google Cloud powinny opublikować przykłady klientów wyjaśniające przepływ pracy, uprawnienia, zablokowane zachowania i narzut operacyjny. Przydatne dowody obejmowałyby dokładność wykrywania, częstotliwość zatwierdzeń, opóźnienia oraz wyniki reagowania na incydenty.

Ogólnikowe stwierdzenie, że klient wdrożył bezpiecznych agentów, niewiele ujawni. Najmocniejsze studium przypadku pokazałoby, jak mechanizm kontroli zatrzymał realistyczny atak prompt injection lub nieautoryzowane wywołanie narzędzia. Powinno również wyjaśniać, jak często przerywano prawidłową aktywność.

Jeśli pojawią się takie dowody, wzmocnią one twierdzenie, że egzekwowanie zasad w czasie wykonania może wspierać praktyczne wdrożenia agentów. Jeśli klienci pozostaną anonimowi, a pomiary prywatne, kupujący powinni traktować integrację jako obiecującą, lecz nieudowodnioną.

Drugim sygnałem będzie silniejsza tożsamość i autoryzacja na różnych platformach. NIST wskazał już kwestie związane z identyfikacją agentów, delegowaniem, audytem i niezaprzeczalnością. Rynek potrzebuje spójnych sposobów dowodzenia, który agent działa, w czyim imieniu i z jakim uprawnieniem.

Interoperacyjność będzie mieć znaczenie, ponieważ przepływy pracy przedsiębiorstw rzadko pozostają w środowisku jednego dostawcy. Agent może korzystać z modelu Google, odpytywać bazę danych innej firmy, wywoływać aplikację Microsoft i uruchamiać narzędzie opracowane wewnętrznie.

Polityki muszą podążać za tym przepływem pracy bez przyznawania jednemu wielokrotnie używanemu poświadczeniu szerokiego dostępu. Krótkotrwała autoryzacja powiązana z konkretnym zadaniem zmniejszyłaby ryzyko. Weryfikowalne zapisy powinny łączyć każde istotne działanie zarówno z agentem, jak i odpowiedzialnym człowiekiem lub usługą.

Postępy w zakresie otwartych standardów tożsamości wzmocniłyby strategię partnerską Google Cloud. Utrzymująca się fragmentacja sprzyjałaby ściśle zintegrowanym platformom kontrolującym większą część stosu technologicznego.

Trzecim sygnałem są niezależne testy odpornościowe. Thales i Google Cloud powinny sprawdzić połączony system pod kątem pośredniego prompt injection, złośliwych wyników działania narzędzi, nadużywania poświadczeń, zatruwania pamięci oraz przejętych agentów. Oceny powinny mierzyć skuteczność ograniczania skutków, a nie tylko to, czy atak został wykryty.

Przydatny test zakładałby, że model zawodzi. Następnie sprawdzałby, czy zewnętrzne mechanizmy kontroli zapobiegają eksfiltracji danych lub nieautoryzowanej zmianie systemu. Pozwala to oddzielić deklaracje dotyczące bezpieczeństwa modelu od praktycznej wartości zabezpieczeń zapewnianych przez otaczającą go architekturę.

Niezależni badacze powinni również zbadać obejścia tworzone przez przepływy pracy z wieloma agentami. Polityka może zatrzymać jedno bezpośrednie żądanie, jednocześnie dopuszczając kilka indywidualnie akceptowalnych działań, które prowadzą do tego samego zakazanego rezultatu.

Premiera następuje we właściwym momencie. Przedsiębiorstwa chcą, aby agenci robili więcej niż tylko podsumowywali informacje, podczas gdy regulatorzy i zespoły bezpieczeństwa domagają się większej rozliczalności. Te presje sprawiają, że kontrola w czasie działania staje się wymogiem, a nie opcjonalną funkcją.

Mimo to ciężar dowodu rośnie wraz z autonomią. Im większe uprawnienia otrzymuje agent, tym więcej dowodów potrzebują kupujący, że tożsamości, uprawnienia, polityki i rejestry audytowe współdziałają podczas ataku.

Organizacje oceniające integrację zabezpieczeń AI Thales i Google Cloud powinny zacząć od jednego ograniczonego przepływu pracy i zdefiniowanego budżetu błędów. Należy zmapować każde narzędzie, poświadczenie, źródło danych oraz nieodwracalne działanie. Następnie trzeba sprawdzić, czy mechanizmy kontroli powstrzymują nadużycia, nie przytłaczając użytkowników liczbą wymaganych zatwierdzeń.

Decydujące pytanie ma charakter praktyczny: czy partnerstwo potrafi za każdym razem, gdy zmienia się przepływ pracy, przekształcić szerokie możliwości agenta w ściśle autoryzowane działanie? Odpowiedź zapewnią pomiary w środowisku produkcyjnym, interoperacyjne tożsamości i niezależne testy.