Pięciowarstwowy przewodnik bezpieczeństwa Mend celuje w produkcyjne zagrożenia AI wykraczające poza zabezpieczenia promptów
Mend.io opublikował pięciowarstwowe podejście do bezpieczeństwa, które trafiło do Google News, lecz jego główne przesłanie podważa sposób, w jaki wiele zespołów chroni produkcyjne systemy AI. Same zabezpieczenia promptów nie są w stanie ochronić agentów, którzy przechowują poświadczenia, wywołują narzędzia, zachowują pamięć i zmieniają systemy zewnętrzne.
Przewodnik, opisany przez MarkTechPost 3 sierpnia, porządkuje powierzchnię ataku w warstwach interakcji, agenta, integracji, modelu i kodu. Jego praktyczna wartość polega na traktowaniu aplikacji AI jako systemu wykonawczego, a nie jedynie chatbota o nietypowych zagrożeniach związanych z danymi wejściowymi.
To rozróżnienie tworzy rzeczywisty konflikt. Deweloperzy chcą, aby agenci wykonywali więcej pracy przy mniejszej liczbie przerw. Zespoły bezpieczeństwa potrzebują deterministycznych ograniczeń, gdy agenci napotykają wrogie dokumenty, zatrute narzędzia, nadmierne uprawnienia lub nieoczekiwane ścieżki wykonania.
MCP, skrót od Model Context Protocol, zapewnia aplikacjom AI standardowy interfejs do wykrywania i wywoływania zewnętrznych narzędzi. Może łączyć model z bazami danych, systemami plików, API, aplikacjami biznesowymi i środowiskami deweloperskimi.
Protokół poprawia interoperacyjność, lecz ta wygoda zwiększa liczbę granic zaufania wewnątrz każdego przepływu pracy. Agent może teraz w ciągu kilku sekund przekształcić niezaufany tekst w istotne działanie.
Pytanie nie brzmi już, czy model generuje niewłaściwą odpowiedź. Chodzi o to, czy zmanipulowany model może użyć autoryzowanego narzędzia do nieautoryzowanego celu.
Google News skupia uwagę na bezpieczeństwie produkcyjnych systemów AI
Ważnym wydarzeniem jest przejście od dyskusji o zachowaniu modelu do zabezpieczania całej ścieżki między danymi wejściowymi a wykonaniem.
Przewodnik bezpieczeństwa produkcyjnego wyróżniony przez Google News przedstawia bezpieczeństwo agentów jako pięciowarstwowy problem inżynieryjny. Warstwa interakcji obejmuje prompty, pobrane dokumenty, pliki użytkowników i inne informacje wchodzące do aplikacji.
Warstwa agenta obejmuje planowanie, pamięć, wybór narzędzi i delegowane zadania. Warstwa integracji obejmuje serwery MCP, API, bazy danych, wtyczki i inne połączenia przenoszące decyzje agenta do systemów zewnętrznych.
Warstwa modelu obejmuje model językowy, jego konfigurację i ograniczenia behawioralne. Warstwa kodu obejmuje logikę aplikacji, zależności, infrastrukturę, poświadczenia i potoki wdrożeniowe.
To ujęcie ma znaczenie, ponieważ awarie często przekraczają kilka warstw. Złośliwa instrukcja może wejść przez dokument, wpłynąć na rozumowanie modelu, uruchomić dozwolone narzędzie MCP i ujawnić dane przez zwykłe żądanie API.
Każdy komponent może pozornie działać zgodnie z założeniami. Awaria bezpieczeństwa wynika z ich połączenia.
Tradycyjne bezpieczeństwo aplikacji nadal ma znaczenie w tym stosie. Zespoły muszą łatać zależności, chronić sekrety, walidować dane wejściowe, izolować obciążenia i przeglądać kod. Kontrole te nie wyjaśniają jednak w pełni, dlaczego agent wybrał prawidłowe narzędzie w niewłaściwym momencie.
Model działa na instrukcjach i danych wyrażonych w tym samym podstawowym medium. Pobrana strona może zawierać informacje odpowiadające na pytanie użytkownika, instrukcje przekierowujące agenta albo oba te elementy.
Powoduje to pośrednie wstrzyknięcie promptu, w którym złośliwe wskazówki docierają przez treści zewnętrzne zamiast widocznego promptu użytkownika. Agent czytający e-maile, strony internetowe, zgłoszenia wsparcia lub dokumenty wewnętrzne może napotkać takie treści podczas zwykłej pracy.
Atak może pozostać niewidoczny dla osoby, która zainicjowała zadanie. Agent może streścić oczekiwany dokument, jednocześnie po cichu wywołując inne narzędzie lub zapisując zatrute informacje w pamięci.
Pięciowarstwowe ujęcie Mend.io służy więc jako metoda inwentaryzacji. Nakłania zespoły do identyfikacji każdego miejsca, w którym instrukcje, uprawnienia, kod, dane i stan mogą wejść do systemu lub go opuścić.
Ta inwentaryzacja powinna obejmować więcej niż wdrożone modele. Powinna rejestrować konfiguracje agentów, prompty systemowe, serwery MCP, dostępne narzędzia, zakresy uprawnień, magazyny pamięci, dostawców modeli, zależności i odpowiedzialnych właścicieli.
Bez takiej mapy zespoły nie mogą ustalić, czy jeden przejęty komponent może dotrzeć do innego. Nie mogą też z przekonaniem cofnąć dostępu, gdy integracja zmienia zachowanie.
Wydarzeniem nie jest nowe wydanie protokołu ani pojedyncza ujawniona podatność. Jest nim wyraźniejsza granica produkcyjna: bezpieczeństwo agentów musi obejmować pełny łańcuch wykonania.
Ta granica jednocześnie wywiera presję na deweloperów, zespoły platformowe, inżynierów bezpieczeństwa i dostawców AI. Każda grupa kontroluje tylko część systemu, podczas gdy najpoważniejsze awarie przemieszczają się między tymi podziałami organizacyjnymi.
Agenci AI przekształcają język w uprzywilejowane działania
LLM staje się istotnie innym problemem bezpieczeństwa, gdy jego wynik steruje oprogramowaniem mającym rzeczywiste uprawnienia.
Tradycyjny chatbot generuje tekst do sprawdzenia przez człowieka. Agent może zinterpretować cel, wybrać narzędzie, skonstruować argumenty, sprawdzić wynik i kontynuować działanie bez kolejnej decyzji człowieka.
Ta pętla zmienia konsekwencje błędnej odpowiedzi modelu. Zmyślone zdanie jest niedogodnością, ale zmyślona instrukcja przekazana do bazy danych lub narzędzia wdrożeniowego może stać się incydentem operacyjnym.
Rozważmy wewnętrznego agenta badawczego, którego poproszono o porównanie propozycji dostawców. Czyta przesłane dokumenty, przeszukuje współdzieloną pamięć masową, odpytuje rejestry zakupowe i przygotowuje rekomendację.
Złośliwa propozycja może ukrywać instrukcje nakazujące agentowi pobranie poufnych cen z innego folderu. Jeśli narzędzie pamięci masowej ma szerokie uprawnienia, błędna decyzja modelu staje się rzeczywistą ścieżką ujawnienia danych.
Agent programistyczny stwarza podobny problem. Może czytać repozytoria, instalować zależności, wykonywać testy, modyfikować pliki i otwierać pull requesty. Niezaufany tekst zgłoszeń lub dokumentacja pakietów mogą wpływać na ten sam model, który dysponuje tymi możliwościami.
MCP ułatwia spójne budowanie tych połączeń. Korzystają na tym deweloperzy, ale oznacza to również, że opis narzędzia, odpowiedź narzędzia lub zdalny serwer mogą wpływać na późniejsze wybory agenta.
Wytyczne OWASP dotyczące bezpieczeństwa agentów wskazują wstrzykiwanie promptów, nadużywanie narzędzi, eksfiltrację danych, zatruwanie pamięci, nadmierną autonomię i kaskadowe awarie jako główne zagrożenia. Kategorie te są ze sobą powiązane, a nie odizolowane.
Pamięć jest szczególnie ważna. Trwała pamięć agenta przechowuje informacje na potrzeby przyszłych sesji, umożliwiając aplikacji zapamiętywanie preferencji, wcześniejszej pracy lub zgromadzonej wiedzy.
Jeśli niezaufana treść trafi do tego magazynu bez walidacji, jeden atak może przetrwać po zakończeniu pierwotnej rozmowy. Późniejsi użytkownicy mogą otrzymywać zatrute fakty lub uruchamiać zachowanie pod wpływem wcześniejszego dokumentu.
Systemy wieloagentowe zwiększają możliwy zasięg szkód. Jeden agent może przekazywać instrukcje, podsumowania, poświadczenia lub wyniki narzędzi innemu agentowi z innymi uprawnieniami.
Przejęty agent badawczy może nie mieć dostępu do zapisu w bazie danych. Może jednak przekazać zmanipulowane ustalenia agentowi operacyjnemu, który taki dostęp ma.
Zespoły nie rozwiążą tego problemu, mówiąc każdemu modelowi, by ignorował złośliwe instrukcje. Modele muszą przetwarzać język naturalny, aby wykonywać swoją pracę, a atakujący mogą zmieniać sformułowania, kontekst, kodowanie i kanały dostarczania.
Celem bezpieczeństwa musi więc być granica działania. Zanim narzędzie zostanie uruchomione, deterministyczne oprogramowanie powinno zdecydować, czy agent, użytkownik, zasób, operacja i parametry tworzą dozwoloną kombinację.
Operacja odczytu nie powinna po cichu przekształcać się w zapis. Dostęp do jednego repozytorium nie powinien zapewniać dostępu do wszystkich repozytoriów. Uprawnienie do przygotowania wersji roboczej e-maila nie powinno automatycznie zezwalać na jego wysłanie.
Operacje o dużym wpływie wymagają silniejszego traktowania. Transfery finansowe, zmiany produkcyjne, administracja kontami, usuwanie danych, publikacja zewnętrzna i dostęp do poświadczeń powinny wymagać wyraźnej autoryzacji lub zgody człowieka.
Zgoda musi być powiązana z rzeczywistym działaniem. Ogólne potwierdzenie, takie jak „kontynuuj”, jest słabsze niż zatwierdzenie wyświetlające miejsce docelowe, operację, zasób, którego dotyczy, oraz istotne parametry.
Poświadczenia krótkotrwałe również ograniczają ekspozycję. Agent powinien otrzymać minimalne uprawnienia wymagane do bieżącego zadania i utracić je po jego zakończeniu.
Takie podejście może wprowadzać tarcia, zwłaszcza gdy deweloperzy mierzą sukces ukończeniem zadania i szybkością. Alternatywą jest jednak pozwolenie, by probabilistyczne rozumowanie działało jako system kontroli dostępu.
Modele językowe mogą proponować działania. Nie powinny jednostronnie definiować własnych uprawnień.
MCP standaryzuje połączenia, a nie pełne zarządzanie
MCP rozwiązuje problem kompatybilności, podczas gdy zespoły produkcyjne nadal muszą zbudować wokół niego warstwę polityk i odpowiedzialności.
Klient MCP może pobrać dostępne definicje narzędzi serwera i przedstawić je modelowi. Model wykorzystuje te opisy i schematy parametrów do wyboru oraz wywołania narzędzia.
Ta struktura ogranicza pracę nad niestandardowymi integracjami. Kompatybilny klient może łączyć się z wieloma serwerami za pośrednictwem wspólnego protokołu, zamiast uczyć się osobnego interfejsu dla każdej usługi.
Jednak standardowe wykrywanie nie czyni każdego wykrytego narzędzia godnym zaufania. Serwer może zostać przejęty, podszyty, błędnie skonfigurowany lub zaktualizowany po początkowym przeglądzie bezpieczeństwa.
Zatruwanie narzędzi wykorzystuje to zaufanie. Złośliwe instrukcje umieszczone w opisie narzędzia mogą wpływać na model, pozostając jednocześnie ukryte przed zwykłą interakcją użytkownika.
Odpowiedź narzędzia może zawierać podobne instrukcje. Agent może traktować odpowiedź jako dane, ale model językowy może interpretować osadzony tekst jako wskazówkę wpływającą na późniejsze działania.
Najnowsze zasady autoryzacji MCP obejmują wymagania dotyczące walidacji tokenów, wiązania odbiorcy, kradzieży tokenów, bezpieczeństwa komunikacji, zagrożeń związanych z przekierowaniami i ataków typu confused deputy.
Wymagania te wzmacniają mechanizmy uwierzytelniania i autoryzacji. Nie rozstrzygają jednak, czy określone działanie biznesowe jest odpowiednie dla bieżącego celu użytkownika.
Ważny token dostępu ustanawia rozpoznane uprawnienia w ramach swojego zakresu. Nie dowodzi, że model podjął właściwą decyzję po przeczytaniu niezaufanej treści.
Systemy produkcyjne potrzebują punktu kontrolnego między intencją modelu a wykonaniem narzędzia. Warstwa ta może oceniać tożsamość, żądaną operację, zasób, parametry, ryzyko sesji, klasyfikację danych i wcześniejsze działania.
Microsoft opisał tę lukę, prezentując otwartoźródłowe podejście do zarządzania środowiskiem wykonawczym. Jego wewnętrzny benchmark zarządzania przetestował 60 promptów, w tym 45 przypadków adwersarialnych i 15 prawidłowych.
Microsoft zgłosił wskaźnik naruszeń polityk na poziomie 26,67 procent, gdy system opierał się na samych instrukcjach bezpieczeństwa w promptach. Firma udostępniła metodologię i materiały do odtworzenia, lecz wynik pozostaje jej własną oceną.
Ustalenie to nadal ilustruje ważną zasadę projektową. Wydajność w wykonywaniu instrukcji nie powinna być traktowana jako deterministyczna granica bezpieczeństwa.
Kontrolna płaszczyzna środowiska wykonawczego może zezwalać na każde żądanie narzędzia, odrzucać je lub eskalować. Może również sprawdzać definicje narzędzi przed udostępnieniem ich modelowi oraz analizować odpowiedzi przed zwróceniem ich agentowi.
Taka warstwa powinna egzekwować schematy, ograniczenia parametrów, listy dozwolonych zasobów, limity szybkości, limity kosztów oraz maksymalną głębokość łańcucha. Powinna zatrzymywać powtarzające się błędy, zamiast pozwalać agentowi wejść w niekontrolowaną pętlę ponowień.
Na przykład agent obsługi klienta może potrzebować odczytać dane konta i przygotować rekomendację zwrotu środków. Nie potrzebuje nieograniczonego dostępu do bazy danych ani natychmiastowego uprawnienia do realizacji każdego proponowanego zwrotu.
Warstwa polityk może ograniczyć odczyty do bieżącego klienta, ukryć wrażliwe pola, ustalić maksymalną kwotę zwrotu i wymagać zatwierdzenia przez człowieka przed płatnością. Model pozostaje użyteczny bez otrzymywania szerokich uprawnień operacyjnych.
Istotna jest również izolacja. Narzędzia o wysokich uprawnieniach nie powinny współdzielić tego samego kontekstu agenta z dowolnymi zewnętrznymi serwerami MCP.
Agent, który odczytuje publiczne treści z sieci, nie powinien automatycznie uzyskiwać ścieżki do wewnętrznych narzędzi administracyjnych. Rozdzielenie tych możliwości zmniejsza prawdopodobieństwo, że wrogie treści zewnętrzne dotrą do wrażliwych powierzchni wykonawczych.
Zespoły bezpieczeństwa powinny również utrzymywać rejestr zatwierdzonych serwerów. Każdy wpis powinien określać właściciela serwera, źródło kodu, lokalizację wdrożenia, metodę uwierzytelniania, dostępne narzędzia, dostęp do danych, wersję i status przeglądu.
Aktualizacje muszą uruchamiać przegląd, gdy zmieniają opisy narzędzi, schematy, zależności, uprawnienia lub docelowe adresy sieciowe. Serwer, który przeszedł przegląd kilka miesięcy wcześniej, nie powinien otrzymywać trwałego zaufania.
Serwery MCP wymagają również konwencjonalnej ochrony usług. Zespoły potrzebują bezpiecznego transportu, uwierzytelniania, łatania, zarządzania zależnościami, walidacji danych wejściowych, izolacji sekretów, rejestrowania i reagowania na incydenty.
Protokół nie zastępuje tych mechanizmów kontroli. Tworzy kolejne miejsce, w którym muszą być stosowane konsekwentnie.
Rzeczywistym kompromisem jest autonomia kontra ograniczenie
Każda dodatkowa funkcja zwiększa użyteczność agenta, jednocześnie zwiększając skalę szkód możliwych po skutecznej manipulacji.
Ten kompromis wyjaśnia, dlaczego bezpieczeństwo agentów nie może stać się listą kontrolną dołączaną tuż przed wdrożeniem. Projekt produktu określa maksymalny zakres uprawnień systemu na długo przed tym, zanim skaner bezpieczeństwa go zbada.
Agent bez narzędzi może tworzyć szkodliwe lub niedokładne teksty. Agent z dostępem do plików może ujawniać dokumenty. Agent z dostępem do powłoki może wykonywać polecenia, natomiast agent połączony z systemami produkcyjnymi może modyfikować działającą infrastrukturę.
Szerokie uprawnienia często trafiają do prototypów dla wygody. Deweloperzy chcą sprawdzić, czy agent potrafi ukończyć pełny przepływ pracy, zanim zainwestują w szczegółową autoryzację.
Takie prototypy mogą trafić do produkcji szybciej, niż się spodziewano. Tymczasowe poświadczenia pozostają w konfiguracji, eksperymentalne serwery MCP stają się współdzieloną infrastrukturą, a liberalne schematy narzędzi przekształcają się w nieudokumentowane zależności.
Model pięciu warstw pomaga ujawnić te skróty. Sam spis zasobów jednak ich nie ogranicza.
Każdy agent potrzebuje zdefiniowanej granicy zaufania. Granica ta powinna określać, kto może go wywoływać, jakie dane może otrzymywać, których narzędzi może używać, do jakich zasobów może docierać oraz które rezultaty wymagają zatwierdzenia.
Zespoły powinny rozróżniać tryby odczytu, tworzenia wersji roboczych, rekomendowania i wykonywania. Etykiety te muszą odpowiadać egzekwowalnym uprawnieniom, a nie jedynie sformułowaniom w promptach.
Agent badawczy może odczytywać zatwierdzone źródła i przygotowywać ustalenia w formie roboczej. Agent operacyjny może przygotować plan wdrożenia. Oddzielny, kontrolowany proces może zweryfikować i wykonać ten plan.
To rozdzielenie zmniejsza autonomię, ale tworzy również przejścia możliwe do przeanalizowania. Osoby prowadzące dochodzenie mogą zobaczyć, kiedy informacja stała się rekomendacją, a kiedy rekomendacja stała się działaniem.
Obserwowalność wspiera ten sam cel. Dzienniki powinny rejestrować użytkownika inicjującego, tożsamość agenta, wersję modelu, wersję promptu lub polityki, serwer MCP, nazwę narzędzia, argumenty, klasyfikację odpowiedzi, zapis zatwierdzenia i końcowy wynik.
Wrażliwe dane nie powinny być beztrosko kopiowane do tych dzienników. Telemetria bezpieczeństwa potrzebuje wystarczającego kontekstu do prowadzenia dochodzenia, nie tworząc przy tym kolejnego repozytorium ujawnionych sekretów.
Tożsamość agenta zasługuje na szczególną uwagę. Współdzielenie konta usługi przez wielu agentów utrudnia przypisanie odpowiedzialności lub odebranie dostępu jednemu przejętemu przepływowi pracy.
Oddzielne tożsamości umożliwiają uprawnienia per agent i wyraźniejsze ścieżki audytowe. Pomagają też zespołom bezpieczeństwa wykrywać nietypowe zachowania, takie jak nagłe żądanie dostępu do zapisu przez agenta badawczego.
Wytyczne rządowe traktują obecnie MCP jako infrastrukturę wymagającą świadomego projektu bezpieczeństwa. Majowe wytyczne NSA z 2026 r. dotyczące bezpieczeństwa MCP omawiają uwierzytelnianie, autoryzację, izolację, walidację serwerów, zarządzanie cyklem życia oraz ryzyka obejmujące komponenty protokołu.
Ta uwaga sygnalizuje zmianę poziomu dojrzałości. MCP nie jest już wyłącznie wygodą dla deweloperów omawianą podczas lokalnych demonstracji. Organizacje oceniają go pod kątem środowisk, w których przejęte narzędzia mogą wpływać na wrażliwe dane i operacje.
Mechanizmy bezpieczeństwa agentów Google Cloud podkreślają podobną kwestię. Wytyczne zalecają odrębną tożsamość agenta, role o minimalnych uprawnieniach oraz ograniczenia uniemożliwiające narzędziom odczytu i zapisu dostęp do zasobów produkcyjnych.
Są to znane zasady bezpieczeństwa. Ich zastosowanie staje się trudniejsze, ponieważ agenci dynamicznie wybierają działania i łączą indywidualnie prawidłowe narzędzia w przepływy pracy, których deweloperzy nie wyliczyli.
Niebezpieczne łączenie narzędzi występuje, gdy wynik jednej dozwolonej operacji umożliwia szkodliwą sekwencję. Narzędzie wyszukiwania, czytnik plików i narzędzie do wysyłania wiadomości na zewnątrz mogą każde z osobna wydawać się mało ryzykowne podczas niezależnego przeglądu.
Razem mogą stworzyć ścieżkę eksfiltracji danych. Agent wyszukuje wrażliwe informacje, odczytuje je i przesyła poza organizację.
Polityka musi zatem badać sekwencje, a także pojedyncze wywołania. Żądanie może być prawidłowe samo w sobie, lecz podejrzane po innym zdarzeniu w tej samej sesji.
Mechanizmy kontroli uwzględniające kontekst mogą blokować kombinacje obejmujące niezaufane dane wejściowe i uprzywilejowane dane wyjściowe. Mogą również wymagać ponownej autoryzacji, gdy agent przechodzi od gromadzenia informacji do działania zewnętrznego.
Ten projekt jest bardziej wymagający niż dodanie filtra wokół promptu użytkownika. Wymaga koordynacji między zespołami produktu, platformy, tożsamości, bezpieczeństwa aplikacji i operacji.
Ten koszt organizacyjny jest częścią kompromisu. Firmy nie mogą deklarować szerokich autonomicznych możliwości, jednocześnie przypisując odpowiedzialność za bezpieczeństwo wyłącznie dostawcy modelu.
Czego bezpieczeństwo produkcyjne nadal nie może zagwarantować
Kontrole warstwowe ograniczają ekspozycję, lecz żadne obecne ramy nie dowodzą, że agent pozostanie bezpieczny w każdej kombinacji modelu, narzędzia i kontekstu.
Pierwszą niewiadomą jest jakość oceny. Testy bezpieczeństwa mogą mierzyć znane ataki, ale dane wejściowe w środowisku produkcyjnym stale się zmieniają, a przeciwnicy dostosowują się do opublikowanych mechanizmów obrony.
Zestaw testów red team powinien obejmować bezpośrednie i pośrednie wstrzykiwanie promptów, nieautoryzowane użycie narzędzi, eskalację uprawnień, zatruwanie pamięci, eksfiltrację danych, obchodzenie zatwierdzeń, rekurencyjne wykonywanie oraz propagację między agentami.
Zespoły powinny przeprowadzać te testy przed wdrożeniem i po istotnych zmianach. Nowy model, prompt systemowy, projekt pamięci, serwer MCP, schemat narzędzia, źródło pobierania lub polityka mogą zmienić powierzchnię ataku.
Pomyślne przejście testu nie ustanawia trwałego bezpieczeństwa. Pokazuje, że zdefiniowane mechanizmy kontroli oparły się zdefiniowanym atakom w określonych warunkach.
Fałszywie pozytywne wyniki tworzą kolejny problem. Jeśli mechanizmy kontroli przerywają zbyt wiele uzasadnionych zadań, użytkownicy szukają obejść lub żądają szerszych uprawnień.
Fałszywie negatywne wyniki są bardziej niebezpieczne, ale trudniejsze do zaobserwowania. Agent może ukończyć żądane zadanie, jednocześnie wyciekając dane, zapisując zatrutą pamięć lub wykonując niepotrzebne działanie.
Zatwierdzenie przez człowieka nie jest pełnym rozwiązaniem. Użytkownicy mogą przyzwyczaić się do potwierdzeń, zwłaszcza gdy aplikacja wyświetla częste lub niejasne komunikaty.
Atakujący mogą również manipulować informacjami pokazywanymi osobie zatwierdzającej. Interfejsy zatwierdzania muszą pobierać szczegóły działania z zaufanych danych wykonawczych, a nie wyłącznie z wyjaśnienia modelu.
Ryzyko łańcucha dostaw również pozostaje nierozwiązane. Wdrożenia MCP mogą obejmować serwery, SDK, rejestry, pakiety, modele, kontenery i usługi hostowane utrzymywane przez różne strony.
Podpisany pakiet może potwierdzać pochodzenie i integralność. Nie może zagwarantować, że podpisane zachowanie jest bezpieczne ani że zdalna usługa pozostanie niezmieniona.
Organizacje powinny preferować powtarzalne wdrożenia, przypięte wersje, sprawdzony kod źródłowy, kontrolowane rejestry i udokumentowane procesy aktualizacji. Zdalne serwery potrzebują ciągłej walidacji, a nie jednorazowego zatwierdzenia.
Awaryjne cofnięcie dostępu musi być praktyczne. Zespoły powinny móc wyłączyć agenta, serwer, narzędzie, poświadczenie lub uprawnienie bez czekania na wydanie aplikacji.
Systemy pamięci potrzebują równoważnych mechanizmów kontroli. Operatorzy wymagają metod sprawdzania, kwarantannowania, wygaszania i usuwania podejrzanych wpisów przy jednoczesnym zachowaniu dowodów do dochodzenia.
Sceptycyzm dotyczy również deklaracji dostawców. Produkty bezpieczeństwa coraz częściej obiecują ochronę promptów, zautomatyzowane red teaming, wykrywanie agentów, zarządzanie postawą bezpieczeństwa lub egzekwowanie zasad w czasie działania.
Te możliwości mogą wspierać obronę, ale kupujący powinni pytać, gdzie znajduje się każdy mechanizm kontroli i co dzieje się, gdy zawiedzie. Detektor, który jedynie oznacza podejrzany tekst, nie może zastąpić autoryzacji wynikającego z niego działania.
Zespoły powinny żądać mierzalnych dowodów. Przydatne pytania obejmują klasy przetestowanych ataków, dostępność danych ewaluacyjnych, sposób obsługi obejść oraz to, czy egzekwowanie zasad zawodzi w trybie zamkniętym.
Powinny również analizować opóźnienia i dostępność. Usługa polityk umieszczona przed każdym wywołaniem narzędzia staje się infrastrukturą krytyczną.
Jeśli taka usługa zawiedzie w trybie otwartym, agenci mogą działać bez mechanizmów kontroli. Jeśli zawiedzie w trybie zamkniętym, zależne przepływy pracy zatrzymują się. Projekt produkcyjny musi wyraźnie uwzględniać oba rezultaty.
Podejście pięciu warstw jest zatem fundamentem, a nie gwarancją. Pomaga zespołom zlokalizować ryzyka, które przegląd skoncentrowany wyłącznie na modelu mógłby pominąć.
Jego powodzenie zależy od przełożenia warstw na odpowiedzialność, egzekwowalną politykę, powtarzalne testowanie i reakcję operacyjną. Bez tych kroków ramy stają się kolejnym diagramem dokumentującym ekspozycję bez jej ograniczania.
Trzy sygnały pokażą, czy bezpieczeństwo agentów dojrzewa
Kolejna faza będzie mierzona egzekwowalnymi ustawieniami domyślnymi, niezależnym testowaniem i dowodami z rzeczywistych wdrożeń.
Pierwszym sygnałem będzie to, czy klienci i serwery MCP przyjmą domyślnie węższą autoryzację. Obsługa nowoczesnych standardów autoryzacji ma znaczenie, lecz bezpieczne wdrożenia wymagają także zakresów specyficznych dla zasobów oraz wyraźnego rozdzielenia operacji odczytu i zapisu.
Silniejszy ekosystem sprawiłby, że szerokie uprawnienia byłyby wyraźnie wyjątkowe. Klienci pokazywaliby użytkownikom, do czego każdy serwer ma dostęp, a serwery odrzucałyby tokeny przeznaczone dla innego zasobu.
Domyślne ograniczenia wzmocniłyby argument, że standaryzowana łączność może współistnieć z ograniczeniem uprawnień. Dalsze poleganie na domyślnie dostępnych poświadczeniach i nadmiernie szerokich zakresach osłabiłoby go.
Drugim sygnałem będzie niezależna ocena zarządzania w czasie działania. Benchmarki dostawców stanowią użyteczny punkt wyjścia, lecz nabywcy potrzebują powtarzalnych testów obejmujących wiele modeli, narzędzi i stylów ataków.
Ewaluatorzy powinni raportować zarówno skuteczność zapobiegania atakom, jak i ukończenie uzasadnionych zadań. System, który blokuje każde wywołanie narzędzia, jest bezpieczny w wąskim sensie, lecz nie spełnia swojego celu operacyjnego.
Wyniki powinny również oddzielać wykrywanie promptów od egzekwowania działań. Wykrycie podejrzanego języka różni się od zapobieżenia zakazanemu odczytowi pliku, aktualizacji bazy danych lub żądaniu wychodzącemu.
Trzecim sygnałem będzie to, czy przedsiębiorstwa potrafią tworzyć kompletne inwentarze agentów i rejestry incydentów. Organizacje powinny wiedzieć, którzy agenci są wdrożeni, kto jest ich właścicielem, jakich modeli używają i do których serwerów MCP mogą dotrzeć.
Powinni również być w stanie odtworzyć istotne działania na podstawie uwierzytelnionych logów. Brakujące tożsamości, niepełne zapisy użycia narzędzi lub niewyjaśnione zmiany uprawnień wskazują, że wdrożenie postępuje szybciej niż mechanizmy zarządzania.
W tym miejscu zarządzanie wiedzą łączy się z operacjami bezpieczeństwa. Zespoły potrzebują przeszukiwalnych zapisów łączących wymagania, konfiguracje agentów, wyniki testów, zatwierdzenia, incydenty i decyzje dotyczące działań naprawczych.
Kontrolowana techniczna baza wiedzy może pomóc inżynierom w odnajdywaniu tych zapisów, ale musi respektować te same granice dostępu i przetwarzania danych.
Obecność w Google News zapewnia pięciowarstwowemu modelowi bezpieczeństwa większą widoczność. Jego trwałe znaczenie zależy od tego, czy zespoły przełożą tę widoczność na węższe uprawnienia i silniejsze mechanizmy kontroli wykonania.
Programiści powinni zacząć od jednego przepływu pracy produkcyjnej i zmapować każde dane wejściowe, decyzję modelu, zapis w pamięci, integrację, poświadczenie, wywołanie narzędzia i wynik. Następnie powinni określić, gdzie deterministyczna polityka przerywa niebezpieczny przepływ między tymi punktami.
Czy Twoja organizacja potrafi wyjaśnić, co może zrobić każdy agent produkcyjny, która tożsamość go autoryzuje i jak zostałby ograniczony wpływ jednego przejętego dokumentu? Jeśli odpowiedź jest niepełna, kolejnym działaniem nie powinna być kolejna reguła promptu. Powinny nim być węższa granica wykonania, przetestowana ścieżka zatwierdzania i ślad audytowy, który przetrwa rozumowanie agenta.
