AWS nakłada twarde ograniczenia na agentów AI, gdy zaostrza się wyścig bezpieczeństwa Amazon i Google
AWS wprowadził egzekwowalne ograniczenia dla agentów AI, mimo ryzyka, że atakujący lub zatrute dane mogą manipulować ich rozumowaniem. Ten ruch zaostrza rywalizację Amazon i Google o to, która chmura potrafi bezpiecznie łączyć agentów z wartościowymi systemami biznesowymi.
Amazon Bedrock AgentCore Policy sprawdza żądane przez agenta działania narzędzi, zanim dotrą one do bazowej usługi. Zmanipulowany agent nadal może wygenerować niebezpieczne żądanie, lecz powinno ono zostać odrzucone, gdy jest sprzeczne z zewnętrzną polityką.
To rozróżnienie ma znaczenie, ponieważ filtry promptów nigdy nie zapewniały pełnej granicy bezpieczeństwa. Modele przetwarzają instrukcje i niezaufane dane za pomocą tych samych probabilistycznych mechanizmów. AWS traktuje teraz model jako niezaufanego decydenta, a nie ostateczny autorytet.
Google Cloud i Microsoft podążają w tym samym ogólnym kierunku, stosując własne mechanizmy kontroli tożsamości, bram i przepływu informacji. Rodząca się konkurencja nie ogranicza się już do jakości modeli. Dostawcy chmury muszą pokazać, że agenci mogą działać bez dziedziczenia nieograniczonego dostępu do każdego połączonego systemu.
AWS przenosi autoryzację poza agenta
AWS rozdziela to, co agent chce zrobić, od tego, na co pozwala infrastruktura.
Polityka w Amazon Bedrock AgentCore tworzy ochronną granicę wokół interakcji między agentami a narzędziami. Usługa przechwytuje żądania kierowane przez AgentCore Gateway, a następnie ocenia każde z nich, zanim zezwoli na wywołanie narzędzia.
AgentCore Gateway łączy agentów z interfejsami API, funkcjami i innymi narzędziami poprzez zarządzany interfejs. Silnik polityk działa obok tego połączenia, a nie wewnątrz promptu agenta ani kodu orkiestracji.
Takie umiejscowienie zmienia model bezpieczeństwa. Prompt systemowy może nakazywać agentowi, by nigdy nie pobierał ograniczonych danych klientów. Jednak prompt injection może skłonić model do zignorowania tej instrukcji lub innej jej interpretacji.
Zewnętrzny silnik autoryzacji nie potrzebuje zgody modelu. Ocenia proponowane działanie na podstawie jawnych reguł, uwierzytelnionej tożsamości, parametrów narzędzia i dostępnego kontekstu żądania.
AWS używa Cedar, swojego otwartoźródłowego języka autoryzacji, do wyrażania tych reguł. Polityka Cedar identyfikuje podmiot składający żądanie, żądane działanie, chroniony zasób oraz wszelkie wymagane warunki.
Usługa działa zgodnie z zasadą domyślnej odmowy dostępu. Działanie nie otrzymuje dostępu, dopóki polityka wyraźnie na niego nie zezwoli. Pasujący zakaz ma również pierwszeństwo przed każdym szerszym uprawnieniem, które w innym przypadku mogłoby dopuścić żądanie.
AWS wyjaśnia te mechanizmy w swoim przewodniku po politykach AgentCore. Przewodnik wskazuje, że każde kierowane żądanie agenta jest oceniane, zanim zostanie przyznany dostęp do narzędzia.
Programiści mogą pisać Cedar bezpośrednio albo opisywać wymagania prostym językiem. Usługa tworzenia w języku naturalnym przekłada te wymagania na proponowane polityki Cedar.
AWS podaje, że usługa sprawdza wygenerowane polityki względem schematu narzędzi bramy. Wykrywa również reguły, które wydają się zbyt permisywne, zbyt restrykcyjne lub niemożliwe do spełnienia.
Ten proces generowania nie sprawia, że nieprecyzyjne wymagania stają się bezpieczne. AWS ostrzega, że polityki w języku naturalnym nadal wymagają dokładnego, jednoznacznego sformułowania. Zespoły bezpieczeństwa muszą sprawdzać wynikowy Cedar, zamiast traktować wygenerowaną politykę jako niepodważalny kod.
Model tworzący politykę jest również oddzielony od mechanizmu, który ją egzekwuje. Po wdrożeniu formalna polityka kontroluje decyzję autoryzacyjną, zamiast pytać inny model o opinię.
Rozważmy wewnętrznego agenta wsparcia z narzędziami do odczytywania kont i wydawania zwrotów. Firma mogłaby zezwolić każdemu przedstawicielowi wsparcia na odczyt przypisanych kont, a jednocześnie pozwalać wyłącznie przełożonym zatwierdzać większe zwroty.
Jeśli wiadomość e-mail zawiera złośliwe instrukcje żądające zwrotu, agent może spróbować wykonać operację. Brama nadal może ją odrzucić, gdy uwierzytelniony pracownik nie ma wymaganej roli lub kwota przekracza politykę.
Odrzucone żądanie nie musi nigdy dotrzeć do systemu płatności. Taki rezultat jest silniejszy niż proszenie agenta o rozpoznawanie każdego wariantu złośliwej instrukcji.
AgentCore Policy jest ogólnie dostępny w 13 regionach AWS, zgodnie z dokumentacją wydań AWS. Scentralizowane polityki mogą być konsekwentnie stosowane do wielu agentów i narzędzi połączonych przez powiązane bramy.
Integracja z CloudWatch rejestruje decyzje autoryzacyjne na potrzeby monitorowania i audytów. Zapisy te dają zespołom bezpieczeństwa jaśniejszy obraz działań, o które agenci wnioskowali, które zostały dozwolone, a które odrzucone.
Bezpośrednia zmiana ma więc charakter architektoniczny, a nie kosmetyczny. AWS umieszcza deterministyczny punkt kontrolny między niepewnym zachowaniem modelu a istotnymi systemami przedsiębiorstwa.
Dlaczego prompt injection zmienia rywalizację Amazon i Google
Rywalizacja chmurowa Amazon i Google zależy teraz od ograniczania skutków przejętych agentów, a nie jedynie od poprawy ich odpowiedzi.
Agenci AI stają się użyteczni, gdy mogą pobierać prywatne informacje, wywoływać API, wysyłać wiadomości lub zmieniać rekordy. Te same uprawnienia określają skalę szkód możliwych po manipulacji.
Prompt injection wprowadza wrogie instrukcje do treści przetwarzanych przez model. Bezpośrednie wstrzyknięcie pochodzi z żądania użytkownika, natomiast pośrednie może być ukryte w witrynach internetowych, dokumentach, wiadomościach e-mail lub odpowiedziach narzędzi.
Agent analizujący dostawcę może natknąć się na instrukcje osadzone na stronie internetowej. Mogłyby one polecić mu pobranie poufnych plików i przesłanie ich przez inne połączone narzędzie.
Filtr treści może wykryć znany wzorzec ataku. Może też pominąć nietypowe sformułowanie, zakodowane polecenie lub sekwencję rozłożoną na kilka interakcji.
Podstawowy problem wykracza poza złośliwe prompty. Model może halucynować działanie, błędnie zrozumieć regułę biznesową lub połączyć indywidualnie akceptowalne narzędzia w niedopuszczalny proces.
OWASP opisuje ten stan jako nadmierną sprawczość. Ryzyko pojawia się, gdy LLM otrzymuje wystarczającą funkcjonalność lub uprawnienia, by wywoływać szkodliwe skutki po nieoczekiwanym wyniku.
Autoryzacja ogranicza wynikający z tego promień rażenia. System zakłada, że agent ostatecznie podejmie złą decyzję, a następnie uniemożliwia jej przekształcenie w nieograniczone działanie.
Podejście to przypomina utrwalone praktyki bezpieczeństwa chmurowego. Aplikacje powinny otrzymywać wyłącznie uprawnienia wymagane do realizacji zadania, natomiast wrażliwe operacje powinny podlegać dodatkowym kontrolom.
Agenci komplikują tę zasadę, ponieważ dynamicznie wybierają narzędzia. Mogą również łączyć wiele wywołań, przenosić kontekst między etapami i działać przez dłuższy czas bez bezpośredniego nadzoru.
Statyczne konto usługi z szerokimi uprawnieniami może więc stać się poważnym obciążeniem. Agent faktycznie zyskuje każdą możliwość przypisaną do tych poświadczeń, niezależnie od użytkownika lub realizowanego zadania.
AWS może łączyć żądania AgentCore z użytkownikami OAuth lub podmiotami AWS Identity and Access Management. Polityki mogą wtedy uwzględniać tożsamość stojącą za żądaniem, zamiast opierać się wyłącznie na wspólnej roli usługi agenta.
Google mierzy się z tym samym problemem, rozwijając agentów opartych na Gemini oraz połączenia Model Context Protocol. MCP to standardowy interfejs umożliwiający modelom odkrywanie i wywoływanie zewnętrznych narzędzi.
Wytyczne Google dotyczące bezpieczeństwa MCP zalecają polityki odmowy dla dostępu produkcyjnego, wąsko określone uprawnienia, oczyszczanie danych wejściowych i monitorowanie. Ostrzegają również, że w przeciwnym razie bezpieczeństwo może całkowicie zależeć od programowania agenta.
Ta konwergencja jest istotna. Konkurencja Amazon i Google często koncentrowała się na dostępności modeli, infrastrukturze, platformach danych i narzędziach dla programistów. Autoryzacja agentów staje się kolejnym ważnym kryterium zakupowym.
Klienci korporacyjni rzadko wdrażają agenta jako odizolowany chatbot. Chcą agentów połączonych z bazami danych, repozytoriami kodu, platformami wsparcia, konsolami chmurowymi i wewnętrznymi magazynami wiedzy.
Każde połączenie tworzy zarówno użyteczność, jak i ryzyko ekspozycji. Dostawca chmury, który ułatwia połączenie, ale zapewnia słabą autoryzację, przenosi ryzyko operacyjne z powrotem na klienta.
AWS pozycjonuje AgentCore Policy jako wielokrotnego użytku warstwę egzekwowania zasad działającą w różnych frameworkach i modelach. Programiści mogą używać AgentCore z agentami zbudowanymi w kilku popularnych frameworkach orkiestracji.
Ta otwartość pozwala AWS argumentować, że polityka bezpieczeństwa powinna pozostać stabilna nawet wtedy, gdy firma zmienia model. Organizacja może zastąpić jeden model bazowy bez przepisywania każdej reguły uprawnień.
Google może przedstawić podobny argument dzięki mechanizmom kontroli tożsamości w chmurze, Model Armor i uprawnieniom na poziomie zasobów. Jego przewagą jest bliskość Google Workspace, Gemini i rozbudowanej platformy danych.
Microsoft zwiększa presję za sprawą tożsamości Entra, Copilot i swojego stosu do tworzenia agentów. Rynek staje się trójstronną rywalizacją o to, kto kontroluje granicę między rozumowaniem AI a wykonywaniem działań w przedsiębiorstwie.
Dla kupujących istotne pytanie dotyczące Amazon i Google nie brzmi: który model zawsze odrzuca złośliwy prompt. Żaden dostawca nie może wiarygodnie obiecać perfekcyjnej odmowy dla każdego wejścia i każdej kombinacji narzędzi.
Lepsze pytanie dotyczy tego, co dzieje się po nieudanej odmowie. Bezpieczna platforma powinna ograniczać narzędzia, rekordy, parametry, cele i sekwencje działań dostępne dla przejętego agenta.
Strategie bezpieczeństwa Amazon i Google spotykają się na granicy narzędzi
AWS, Google i Microsoft zbliżają się do deterministycznego egzekwowania zasad, lecz organizują je w odmienny sposób.
AWS umieszcza AgentCore Policy bezpośrednio na ścieżce bramy. Każde objęte kontrolą żądanie agenta do narzędzia trafia do silnika polityk, zanim nastąpi żądane wywołanie.
Cedar zapewnia AWS formalny język, który zespoły mogą analizować, sprawdzać i walidować. AWS wykorzystywał koncepcje Cedar także poza agentami, co pomaga łączyć autoryzację agentów z utrwalonymi praktykami bezpieczeństwa aplikacji.
Badacze bezpieczeństwa firmy przyjmują bezpośrednie założenie dotyczące samego modelu. Ich analiza bezpieczeństwa Cedar stwierdza, że organizacje powinny traktować LLM jako niezaufanego uczestnika w projekcie obrony warstwowej.
Nie oznacza to, że model jest złośliwy. Oznacza to, że system autoryzacji nie może zależeć od przewidywalnego zachowania modelu, ponieważ model jest probabilistyczny i podatny na zmanipulowany kontekst.
Opublikowane wytyczne Google obecnie podkreślają warstwowe kontrole wokół serwerów MCP i zasobów Google Cloud. Obejmują one polityki odmowy, wąsko określone poświadczenia, oddzielne środowiska testowe, oczyszczone dane wejściowe i ograniczony dostęp produkcyjny.
Google zaleca również blokowanie narzędzi odczytu i zapisu przed dostępem do zasobów produkcyjnych, o ile nie wymaga tego dany proces. Mechanizmy odzyskiwania pozostają ważne, ponieważ nawet autoryzowane działanie może wywołać niepożądany rezultat.
Praktyczna różnica może być widoczna w doświadczeniu programisty. AWS oferuje dedykowany silnik polityk AgentCore z oceną opartą na Cedar w swojej zarządzanej bramie.
Google może korzystać z dojrzałego Cloud IAM i polityk specyficznych dla produktów. Jednak programiści nadal muszą zapewnić, że każda istotna ścieżka narzędzia faktycznie przechodzi przez zamierzoną kontrolę.
To zastrzeżenie dotyczy również AWS. AgentCore Policy zarządza ruchem kierowanym przez powiązaną AgentCore Gateway. Agent korzystający z innej ścieżki wykonania może ominąć ten konkretny punkt kontrolny.
Na przykład polityka może blokować operację S3 realizowaną przez zarządzane narzędzie MCP. Ograniczenie nie obejmie automatycznie osobnego narzędzia powłoki, które może wydać równoważne polecenie.
Przeglądy architektury muszą zatem wyszczególniać możliwości, a nie jedynie nazwy narzędzi. Zespoły bezpieczeństwa powinny pytać, czy agent może dotrzeć do tego samego zasobu przez SDK, wiersz poleceń, przeglądarkę, funkcję lub pomocniczego agenta.
Microsoft rozwija inną odmianę tego podejścia poprzez kontrolę przepływu informacji. Jego oprogramowanie pośredniczące FIDES oznacza treści pod względem integralności i poufności, a następnie przenosi te etykiety przez wywołania narzędzi.
Model bezpieczeństwa FIDES firmy Microsoft może zapobiegać wpływaniu niezaufanych treści na wrażliwą operację. Może również ograniczać przepływ prywatnych danych do publicznego celu.
Podejście to eliminuje słabość autoryzacji pojedynczych działań. Wyszukiwanie w bazie danych może być dozwolone, podobnie jak wysłanie e-maila. Niebezpieczne zachowanie pojawia się, gdy prywatne wyniki zapytania trafiają do zewnętrznej wiadomości e-mail.
AWS rozszerza swoje polityki w kierunku oceny uwzględniającej sesję. Kontrole czasowe mogą analizować ostatnie działania agenta zamiast oceniać każde żądanie jako odizolowane zdarzenie.
Ten kierunek ma znaczenie, ponieważ atakujący mogą podzielić szkodliwy cel na kilka pozornie legalnych kroków. Sekwencja może ujawnić ryzyko, którego nie pokazuje żadne pojedyncze działanie.
Agent może najpierw odczytać poufny portfel, następnie obliczyć podsumowanie, a na końcu podjąć próbę zewnętrznej transmisji. Każde wywołanie narzędzia może wyglądać prawidłowo, jeśli nie połączy się ich w jedną trajektorię.
Dla klientów porównujących modele bezpieczeństwa Amazon i Google ważniejszy od terminologii jest zakres ochrony. Formalny język polityk zapewnia niewielką ochronę, gdy wysokiego ryzyka ścieżki wykonania pozostają poza egzekwowaniem zasad.
Istotne jest również przekazywanie tożsamości. Mechanizm polityk musi wiarygodnie znać użytkownika, obciążenie robocze, zasób, działanie i istotny kontekst biznesowy.
Ogólna tożsamość „agenta” nie wystarcza, gdy agent obsługuje wielu pracowników. Może przyznać każdemu użytkownikowi maksymalny zestaw uprawnień agenta i zniwelować rozliczalność zapewnianą przez zwykłe mechanizmy kontroli dostępu.
Organizacje powinny zachowywać tożsamość człowieka lub obciążenia roboczego stojącą za każdym delegowanym żądaniem. Powinny też przypisać agentowi własną, ograniczoną tożsamość zamiast ukrywać go za współdzielonymi poświadczeniami.
To rozdzielenie pomaga odpowiedzieć na dwa różne pytania. Pierwsze dotyczy tego, czy użytkownik może zażądać danego działania. Drugie — czy ten agent może wykonać to działanie za pośrednictwem tego konkretnego narzędzia.
Centralna polityka zmniejsza również niespójność między zespołami. Bez niej każdy deweloper może implementować autoryzację w promptach, niestandardowym oprogramowaniu pośredniczącym lub indywidualnych procedurach obsługi narzędzi.
Te rozproszone kontrole stają się trudne do audytowania. Z czasem rozchodzą się też, gdy agenci zyskują nowe narzędzia, modele i gałęzie przepływów pracy.
Współdzielona brama nie może zastąpić wszystkich uprawnień na poziomie zasobów. Może jednak zapewnić spójny punkt, w którym organizacje stosują politykę, zanim intencja agenta dotrze do usług docelowych.
Polityka jest tak silna, jak jej zasięg
AgentCore Policy zmniejsza ryzyko, ale nie dowodzi, że agent hostowany w AWS jest bezpieczny.
Usługa kontroluje żądania przechodzące przez skonfigurowaną bramę i mechanizm polityk. Nie może zarządzać narzędziami, poświadczeniami ani trasami sieciowymi, które deweloperzy pozostawiają poza tą granicą.
Tworzy to problem zasięgu. Zespół bezpieczeństwa może sądzić, że zablokował niebezpieczne działanie, podczas gdy alternatywne narzędzie oferuje inną drogę do tego samego zasobu.
Szerokie uprawnienia IAM mogą pogłębiać tę lukę. Jeśli rola środowiska uruchomieniowego agenta może bezpośrednio wywoływać usługi, ograniczenia bramy muszą być połączone z politykami zasobów blokującymi nieautoryzowane ścieżki.
Projektowanie polityk również pozostaje trudne. Tworzenie w języku naturalnym obniża barierę składniową, ale nie rozwiązuje problemu niejasnych wymagań biznesowych ani brakujących założeń bezpieczeństwa.
„Zezwalaj analitykom na przeglądanie odpowiednich raportów” nie jest precyzyjną regułą autoryzacji. Organizacja musi zdefiniować, którzy analitycy, raporty, klasyfikacje, regiony, klienci i warunki operacyjne są uznawane za odpowiednie.
Wygenerowany Cedar wymaga przeglądu, testowania i kontroli zmian. Zespoły powinny testować oczekiwane zgody, oczekiwane odmowy, nieprawidłowo sformułowane żądania, brakujący kontekst oraz celowo adversarialne kombinacje parametrów.
Polityka, która odmawia wszystkiego, powoduje awarię operacyjną. Reguła, która po cichu zezwala na wszystko, tworzy przeciwny problem. Oba rezultaty mogą wyglądać na poprawne składniowo.
Deweloperzy muszą również uwzględniać kontekst autoryzacji dostarczany przez agenta. Atrybuty wrażliwe dla bezpieczeństwa powinny pochodzić z zaufanych tokenów tożsamości, metadanych zasobów lub kontrolowanej infrastruktury.
Model nie powinien mieć możliwości deklarowania, że transakcja jest niskiego ryzyka albo że dokument jest publiczny. Takie twierdzenia wymagają weryfikacji poza procesem rozumowania modelu.
Dzienniki audytu wprowadzają kolejny obowiązek. Rejestrowanie każdej decyzji pomaga w dochodzeniach, ale zespoły muszą aktywnie monitorować zapisy i zachowywać użyteczny kontekst.
Odmówione działanie może wskazywać na skuteczne zabezpieczenie. Powtarzające się odmowy mogą jednak również ujawniać przejęty przepływ pracy, błąd polityki lub agenta, który nieustannie ponawia próbę realizacji zakazanego celu.
Dozwolone działania także zasługują na uwagę. Atakujący może nadużywać uprawnień, które pojedynczo są legalne, zwłaszcza gdy polityki nie uwzględniają historii sesji ani przepływu danych.
Ludzka akceptacja pozostaje przydatna w przypadku nieodwracalnych lub istotnych operacji. Ekran zatwierdzania może jednak zawieść, gdy agent podaje mylący opis żądanego działania.
Interfejs powinien prezentować zaufane szczegóły z rzeczywistego żądania narzędzia. Osoby zatwierdzające potrzebują informacji o celu, zasobie, parametrach, klasyfikacji danych i oczekiwanym skutku.
Zespoły bezpieczeństwa muszą także chronić płaszczyznę administracji politykami. Agent nie powinien móc edytować własnych reguł, powiązać słabszego mechanizmu polityk ani uzyskać poświadczeń o szerszym dostępie.
Pomaga tu rozdzielenie obowiązków. Deweloperzy mogą proponować zmiany w politykach, podczas gdy właściciele bezpieczeństwa przeglądają i wdrażają zmiany za pośrednictwem kontrolowanych przepływów pracy.
Ta sama dyscyplina dotyczy wewnętrznych systemów wiedzy. Zespoły budujące przeszukiwalną bazę wiedzy powinny zachować uprawnienia do dokumentów, zanim udostępnią tę treść agentowi.
Mechanizm wyszukiwania powinien filtrować rekordy zgodnie z uprawnieniami użytkownika składającego żądanie. Model powinien otrzymywać wyłącznie podzbiór informacji, do którego użytkownik mógłby uzyskać bezpośredni dostęp.
Taki projekt zapobiega krytycznemu trybowi awarii. Nawet skutecznie zmanipulowany model nie może ujawnić informacji, które nigdy nie trafiły do jego dostępnego kontekstu.
Organizacje powinny unikać pokładania całej ufności w wykrywaniu prompt injection. Wykrywanie zapewnia użyteczną ochronę, ale nieznane ataki i instrukcje wyglądające niewinnie mogą omijać klasyfikatory.
AWS obsługuje Bedrock Guardrails na warstwie polityk do oceny wejść i wyjść bramy. Ta funkcja uzupełnia egzekwowanie Cedar, zamiast je zastępować.
Różnica jest prosta. Guardrail ocenia, czy treść wygląda na niebezpieczną, podczas gdy autoryzacja rozstrzyga, czy żądana operacja jest dozwolona.
Wykrywanie probabilistyczne i deterministyczne egzekwowanie zasad rozwiązują różne problemy. Łączenie ich zawęża powierzchnię ataku, nie udając, że którakolwiek warstwa wychwytuje każdą awarię.
Wyścig bezpieczeństwa Amazon i Google nagrodzi dostawców, którzy utrudnią omijanie tych warstw. Marketingowe deklaracje dotyczące bezpiecznych agentów znaczą mniej niż możliwy do wykazania zasięg egzekwowania zasad.
Klienci powinni testować te deklaracje za pomocą ćwiczeń red-teamowych obejmujących pośrednie wstrzyknięcie, przejęte narzędzia, alternatywne ścieżki wykonania i wieloetapowy przepływ danych.
Powinni również zweryfikować zachowanie w przypadku awarii. Odmówione wywołanie narzędzia musi zatrzymać chronioną operację bez ujawniania wrażliwych szczegółów przez błędy lub ścieżki awaryjne.
AWS ustanowił silniejszy domyślny wzorzec, umieszczając politykę poza kodem agenta. Pozostaje pytanie, czy klienci skonfigurują otaczające tożsamości i trasy z równie dużą starannością.
Na co powinni zwracać uwagę nabywcy korporacyjni
Kolejna faza sprawdzi zasięg polityk, świadomość sesji i przenośność między konkurującymi platformami agentowymi.
Pierwszym sygnałem będzie tempo, w jakim klienci przyjmują polityki czasowe. Reguły dotyczące pojedynczych żądań dobrze sprawdzają się przy jasnych ograniczeniach, lecz wiele ataków na agentów ujawnia się poprzez sekwencje autoryzowanych działań.
Ocena czasowa może wykryć, że agent odczytał wrażliwe dane przed próbą zewnętrznego transferu. Może również wymagać dodatkowej akceptacji po określonej sekwencji operacji.
Trudność dotyczy stanu i interpretacji. Systemy muszą śledzić wystarczającą historię, aby rozpoznawać niebezpieczne trajektorie bez blokowania zwykłych przepływów pracy i bez dodawania nadmiernych opóźnień.
Nabywcy powinni szukać publicznej dokumentacji technicznej precyzyjnie opisującej, jak duża część historii sesji jest oceniana. Powinni też pytać, jak stan jest izolowany między użytkownikami, agentami i współbieżnymi zadaniami.
Drugim sygnałem będzie to, jak Google i Microsoft udostępniają równoważne kontrole za pośrednictwem swoich zarządzanych platform agentowych. Wszyscy trzej dostawcy uznają, że same instrukcje w promptach nie mogą chronić połączonych systemów.
Reakcja Google będzie istotna, ponieważ agenci Gemini mogą znajdować się blisko treści Workspace, danych chmurowych i infrastruktury deweloperskiej. Silne uprawnienia do zasobów już istnieją, ale kompozycja specyficzna dla agentów pozostaje niezbędna.
Microsoft może łączyć tożsamość Entra z Copilot, Agent Framework i etykietami przepływu informacji. Jego przewaga będzie zależeć od spójnego egzekwowania zasad w narzędziach Microsoft i narzędziach innych firm.
Porównanie Amazon i Google powinno koncentrować się na ścieżkach end-to-end. Nabywcy potrzebują dowodów, że polityka podąża za działaniem od tożsamości użytkownika, przez rozumowanie agenta i wykonanie w bramie, po końcowy dostęp do zasobu.
Trzecim sygnałem będą niezależne testy bezpieczeństwa. Dokumentacja dostawców opisuje zamierzone zachowanie, natomiast zespoły red-teamowe ujawniają brakujące trasy, pomylone tożsamości, niebezpieczne ustawienia domyślne i nieoczekiwane kombinacje narzędzi.
Testy powinny obejmować złośliwą stronę internetową, zatrute zgłoszenie do wsparcia, przejętą odpowiedź MCP oraz wrogi dokument w zatwierdzonym repozytorium. Każde z tych źródeł może przenosić pośrednie instrukcje do kontekstu agenta.
Badacze powinni również testować, czy agenci mogą przekształcać zakazane żądania w technicznie odmienne działania. Zablokowany eksport może stać się przesłaniem przez przeglądarkę, poleceniem powłoki, zakodowaną wiadomością lub żądaniem skierowanym do innego agenta.
Wyniki określą, czy zewnętrzna polityka zapewnia znaczące ograniczenie skutków, czy tylko kolejną warstwę konfiguracji. Najsilniejsze dowody przyniosą ataki, które zmieniają zachowanie modelu, ale mimo to nie przekraczają granic autoryzacji.
Przedsiębiorstwa nie muszą czekać na te wyniki, aby ulepszać swoją architekturę. Mogą zacząć od zinwentaryzowania każdego agenta, narzędzia, poświadczenia, źródła danych i miejsca docelowego ruchu wychodzącego.
Każde narzędzie powinno otrzymać możliwie najwęższy zakres działań. Dostęp tylko do odczytu powinien pozostać oddzielony od modyfikacji, usuwania, udostępniania na zewnątrz lub realizacji transakcji finansowych.
Zespoły powinny usuwać stałe poświadczenia, gdy możliwe jest krótkotrwałe delegowanie. Powinny zachowywać tożsamość użytkownika podczas wywołań narzędzi i rejestrować zarówno próby, jak i zakończone operacje.
Działania o dużym wpływie powinny wymagać wiarygodnego kontekstu akceptacji. Zespoły bezpieczeństwa powinny regularnie testować alternatywne ścieżki do chronionych zasobów, zamiast weryfikować wyłącznie zamierzoną trasę przez bramę.
W przypadku decyzji dotyczących Amazon Google same benchmarki modeli już nie wystarczą. Kupujący powinni porównywać domyślne zachowanie typu „odmowa dostępu”, propagację tożsamości, analizę polityk, szczegółowość audytu, kontrolę sesji i zakres egzekwowania zasad.
Powinni również pytać, jak polityki przetrwają zmiany modeli i frameworków. Autoryzacja ściśle powiązana z jedną implementacją agenta staje się kosztowna w utrzymaniu i łatwiejsza do obejścia podczas migracji.
AWS postawił na wyraźną architekturę. Zakłada, że rozumowanie agentów pozostanie podatne na manipulację, a następnie ogranicza jej skutki za pomocą deterministycznych mechanizmów kontroli działających poza agentem.
To założenie jest bardziej wiarygodne niż obietnica doskonałego posłuszeństwa modelu. Uwzględnia, że błędy i ataki będą się zdarzać, jednocześnie zachowując odrębny mechanizm kontroli nad narzędziami i danymi.
Podejście to nadal zależy od zdyscyplinowanej konfiguracji. Wąska polityka bramy nie zrekompensuje nadmiernych uprawnień środowiska wykonawczego, niezarządzanej powłoki ani danych pobranych przed filtrowaniem autoryzacyjnym.
Zespoły przedsiębiorstw powinny teraz przetestować jeden konkretny przepływ pracy od początku do końca. Należy zmanipulować agenta, obserwować żądane przez niego działania i potwierdzić, że chronione operacje kończą się niepowodzeniem na zewnętrznej granicy.
Ten test wyznacza praktyczny standard dla Amazon Google i każdej innej platformy agentowej: model można oszukać, ale infrastruktura nadal musi powiedzieć „nie”.
