AI Blue Teaming wyjaśnione: trzy warstwy, w których kontrola może faktycznie funkcjonować

Zapytaj zespół bezpieczeństwa, gdzie znajdują się jego zabezpieczenia AI, a odpowiedź zwykle wskazuje dokument polityki, prompt systemowy lub funkcję dostawcy. Żadne z nich nie jest mechanizmem kontrolnym. Mechanizm kontrolny to coś, co w momencie działania decyduje, czy działanie nastąpi — a w przypadku agenta AI istnieją tylko trzy miejsca, które mogą decydować: model, brama przed nim i środowisko wokół niego. Wszystko, co zespół blue team może uczciwie obiecać, pochodzi z drugiego i trzeciego z tych miejsc. To pytanie o warstwę i ma ono pierwszeństwo przed każdą inną decyzją zespołu blue team, w tym przed tym, co logować i do kogo dzwonić. Dlatego też znaczenie mają dowody z praktyki: archiwum incydentów AI zawiera 400 incydentów z udziałem agentów od 2024-12 do 2026-10-17, a większość z nich nie jest opowieściami o modelu, który zachowuje się źle. To opowieści o wdrożeniu, w którym nie było warstwy, która mogłaby powiedzieć nie.

Blue teaming w rozumieniu AI to praca polegająca na wdrażaniu tych warstw, dostrajaniu tego, na co zwracają uwagę, oraz na przygotowaniu przećwiczonej odpowiedzi na dzień, w którym któraś z nich zadziała. To zajęcie mało efektowne, nie daje żadnego wyniku punktowego i jest jedyną połową pary red team/blue team, która zmienia liczbowy wskaźnik ryzyka.

Co blue team dziedziczy, a czego nie

Tradycyjne blue teaming opiera się na zestawie założeń, które wdrożenia AI po cichu łamią. Zakładano, że logi są kompletne, ponieważ sieć widziała każdy pakiet. Zakładano, że aktywa można wyliczyć, ponieważ ktoś musiał je przygotować. Zakładano, że zachowanie jest deterministyczne, ponieważ program robi to samo przy tych samych danych wejściowych. Żadne z tych trzech założeń nie przetrwa zetknięcia z agentem.

To, co zamiast tego dziedziczy zespół blue team, to system, w którym najistotniejsze decyzje podejmowane są wewnątrz żądania, które warstwa sieciowa traktuje jako zwykły ruch HTTPS do jednej nazwy hosta. Prompt, pobrany kontekst, wywołania narzędzi, uzupełnienie — wszystko to znajduje się w treści żądania, a jeśli nikt nie przechwytuje i nie analizuje tej treści, wdrożenie jest funkcjonalnie niemonitorowane, niezależnie od tego, jak dobry jest obwód ochronny. Pierwszym zadaniem zespołu blue team nie jest więc wykrywanie; jest nim ustanowienie czujnika. Bez widoczności na poziomie żądań i narzędzi nie ma na czym wykrywać, a każda kolejna kontrola jest wyłącznie dekoracją.

Kto faktycznie może wyegzekwować tę kontrolę

Gdy istnieje czujnik, pojawia się pytanie, gdzie każdy mechanizm kontrolny może się znajdować. Użytecznym sposobem przedstawienia tego jest podział według własności, a nie według technologii, ponieważ to własność decyduje o tym, czy dany mechanizm kontrolny przetrwa kolejne wydanie.

Warstwa modelu należy do tego, kto go wytrenował. Nie konfigurujesz jej, nie możesz zajrzeć do jej wnętrza, a jej zachowanie zmienia się, gdy dostawca wydaje nową wersję — a może to być dowolny wtorek. Możesz przypiąć wersję i traktować zmianę wersji jako zmianę swojego profilu ryzyka wymagającą ponownego testu. Nie możesz natomiast twierdzić, że sprawujesz tu kontrolę. „Model odrzuca szkodliwe żądania” to właściwość, na której polegasz, a nie mechanizm, którym zarządzasz.

Warstwa bramy to miejsce, przez które każde polecenie i każde ukończenie przechodzi przez komponent należący do Ciebie. To tutaj funkcjonują limity budżetu i szybkości, tutaj egzekwowane są listy dozwolonych i uprawnienia narzędzi, tutaj rejestrowanie żądań i odpowiedzi jest kompletne z samej konstrukcji, a także tutaj żądanie można przepisać, zablokować lub przekierować, zanim zostanie rozliczony jakikolwiek token. Mechanizmy kontroli bramy są też jedynymi, które pozostają przypięte, gdy zmieniasz modele, co ma większe znaczenie, niż to brzmi: zespoły, które umieszczają swoje mechanizmy kontroli w poleceniach, tracą je całkowicie w dniu migracji.

Warstwa środowiska jest tą, która należy w całości do ciebie: poświadczenia i ich zakresy, ruch wychodzący sieci, dostęp do plików, limity piaskownicy dotyczące czasu zegarowego i wydatków. To także miejsce, w którym przejęte uruchomienie wyrządza szkody. Agent, którego namówiono do złośliwego działania, jest niebezpieczny dokładnie w takim stopniu, w jakim środowisko pozwoliło temu działaniu dotrzeć — a środowisko to jedyne miejsce, gdzie „najmniejsze uprawnienia” są zmianą konfiguracji, a nie problemem badawczym.

Praktyczny test każdej proponowanej kontroli nad AI sprowadza się do jednego pytania: która z tych trzech warstw ją egzekwuje? Jeśli odpowiedź brzmi „warstwa modelu”, to kontrola jest jedynie nadzieją. Jeśli odpowiedź brzmi „prompt systemowy”, to jest to sugestia wewnątrz warstwy modelu — gorsza niż nadzieja, bo wiąże się z dokumentacją twierdzącą inaczej.

Wykrywanie: co faktycznie emituje agent

Wykrywanie dla agentów opiera się na innym zestawie sygnałów niż wykrywanie dla ludzi. Nie ma anomalii logowania, którą można by skorelować. Zamiast tego jest strumień żądań o niezwykle bogatej strukturze oraz cztery rodziny sygnałów, na które warto wywoływać alerty.

• Liczba i kształt wywołań narzędzi. Agent, który nagle wywołuje narzędzie do czytania plików czterdzieści razy w jednym zadaniu lub którego sekwencja narzędzi zmienia się z trzech kroków na trzydzieści, zasługuje na bliższe spojrzenie — nie dlatego, że jest złośliwy, ale dlatego, że rozkład się przesunął.

• Pochodzenie treści na granicy.Który tekst w prompcie pochodził od użytkownika, który z wyszukiwania, który z wyniku narzędzia, a który z pamięci. Większość wykrywania wstrzyknięć do promptu sprowadza się do stwierdzenia „tekst instrukcyjny pojawił się w kanale, który powinien przenosić tylko dane”, a nie można tego obliczyć, jeśli brama nie oznacza pochodzenia na wejściu.

• Granice ruchu wychodzącego i zakresu. Żądania dotyczące miejsc docelowych spoza listy dozwolonych, odczyty ścieżek spoza zakresu, próby użycia poświadczeń poza usługą, dla której są przeznaczone. To sygnały o wysokiej precyzji i są tanie, ponieważ środowisko już wie, co było dozwolone.

• Wydatki i opóźnienia jako wskaźnik zastępczy. Wymykająca się spod kontroli pętla i naruszenie bezpieczeństwa wyglądają identycznie — jak zmiana nachylenia krzywej kosztów. Alerty budżetowe to najmniej efektowna metoda wykrywania w całym stosie i jedna z tych, które najszybciej się zwracają.

Tym, czego celowo brakuje na tej liście, jest klasyfikator, którego zadaniem byłoby ocenianie, czy dana odpowiedź modelu była szkodliwa. To pomysł na detekcję, po który zespoły sięgają najpierw, a który najgorzej się starzeje: dryfuje wraz z modelem, ma odsetek fałszywych alarmów, który przyzwyczaja twoich analityków do ignorowania go, i nie daje ci niczego, co można wpisać do runbooka.

Ograniczanie: trzy pokrętła, które zatrzymują nieudany przebieg

Ograniczanie agenta jest prostsze, niż się wydaje, ponieważ trzy pokrętła obejmują niemal wszystko. Budżet ogranicza to, ile może wydać jedno uruchomienie, co ogranicza zarówno szkody finansowe, jak i zasięg rażenia pętli. Zakres ogranicza to, czego może dotknąć uruchomienie — narzędzia włączone dla tego zadania, ścieżki, dzierżawcy. Piaskownica ogranicza, jak długo może działać i do czego może dotrzeć podczas działania. Wszystkie trzy to ustawienia bramy lub środowiska, co oznacza, że można je wyegzekwować.

Zasada projektowa, która ma znaczenie, to zakres na poziomie zadania, a nie na poziomie agenta. Agent z zestawem stałych uprawnień to agent, którego uprawnienia będą się kumulować, dopóki ktoś ich nie przeaudytuje; agent, który otrzymuje poświadczenie o zakresie ograniczonym do zadania na czas jego trwania, ma granicę, która wygasa sama. To drugie wymaga więcej pracy przy budowie, ale znacznie taniej jest go bronić.

To także miejsce, w którym gateway zasługuje na swoją nazwę. Mechanizmy kontroli działające przed każdym wywołaniem modelu — wywołania narzędzi i MCP oceniane, zanim zostaną uruchomione, polityka treści i maskowanie danych osobowych stosowane, zanim żądanie zostanie rozliczone — są tymi samymi mechanizmami niezależnie od tego, czy model za nimi to ten, którego używałeś w poprzednim kwartale, czy ten, który ukazał się w zeszłym tygodniu. To ciągłość jest właściwym produktem: nie lepszy filtr, lecz miejsce, w którym filtr może mieszkać i które nie przemieszcza się wraz z modelem.

Odzyskiwanie: odtworzenie, poprawka, ponowny test

Odzyskiwanie po incydentach AI ma jedną przewagę nad odzyskiwaniem po incydentach sieciowych: cały przebieg jest zwykle rejestrowany. Prompt, kontekst, wywołania narzędzi, uzupełnienia, czasy — jeśli brama je zarejestrowała, incydent można odtworzyć, co stanowi silniejszy punkt wyjścia niż ten, od którego zaczyna większość analiz śledczych.

Replay służy kolejno trzem celom. Ustala, co faktycznie się wydarzyło, a nie to, co sugeruje transkrypt po tym, jak kilka osób go streściło. Wskazuje mechanizm kontrolny, który powinien był zadziałać, co stanowi różnicę między naprawianiem objawu a naprawianiem granicy. I tworzy przypadek regresyjny: zapisane dane wejściowe, które teraz muszą zostać zablokowane, uruchamiane na nowej konfiguracji, aby to udowodnić.

Etap wdrażania poprawek to miejsce, w którym zespoły niebieskie najczęściej chybiają celu. Jeśli ustalenie dotyczyło zachowania modelu, wszystkie dostępne środki zaradcze znajdują się poza modelem — ograniczenie zakresu, filtr na bramie, uprawnienie odebrane ze środowiska. Jeśli ustalenie dotyczyło zachowania systemu, poprawka leży w konfiguracji, a test regresyjny jest tani. W obu przypadkach ponowne przetestowanie nie jest opcjonalne, ponieważ i poprawka, i wersja modelu ulegają zmianie, a kontrola zweryfikowana względem zeszłomiesięcznej kompilacji to twierdzenie o zeszłym miesiącu.

Ćwiczenie na dzień, w którym to odpali

Runbook, którego nikt nigdy nie czytał pod presją, jest dokumentem, a nie zdolnością. Próba, która się opłaca, jest wąska i konkretna: weź jeden prawdopodobny incydent związany z agentem, przejdź przez niego od początku do końca i zmierz czas każdego kroku. Kto zauważa? Ile czasu mija, zanim człowiek spojrzy na właściwą linię logu? Kto może zatrzymać działanie — jedna wskazana osoba czy komitet? Kto może unieważnić poświadczenie i ile trwa propagacja unieważnienia? Kto decyduje, czy powiadomić kogoś spoza firmy?

Dwa z tych pytań regularnie zaskakują zespoły. „Kto może zatrzymać działanie” zawodzi, gdy zatrzymanie wymaga osoby, która śpi, więc odpowiedź musi być mechanizmem, a nie osobą — limitem budżetu lub wyłącznikiem awaryjnym, który inżynier dyżurny może uruchomić samodzielnie. „Ile trwa unieważnienie” zawodzi, ponieważ poświadczenia są często buforowane w komponentach, których nie było na diagramie.

Czytanie archiwum to najtańsza dostępna forma ćwiczenia, ponieważ pozwala odziedziczyć strukturę cudzych incydentów zamiast wymyślać własną. Weź kilka wpisów przypominających twoje wdrożenie i przy każdym z nich zadaj trzy powyższe pytania. Wpisy, w których nie potrafisz na nie odpowiedzieć, to luki w twoim runbooku — znalazłeś je przed incydentem, a nie po nim.

Asymetria warta wyrażenia wprost

Red teaming i blue teaming to nie są symetryczne działania i nie należy ich budżetować tak, jakby były. Przeprowadzenie red teamu jest ograniczone harmonogramem i daje zestaw ustaleń, które tracą aktualność w miarę zmian celu. Mechanizmy kontrolne blue teamu trwają, kumulują się i są jedyną rzeczą, która faktycznie stoi między złym wejściem a złym wynikiem. Jedno zlecenie może znaleźć granicę; tylko drugie może ją utrzymać.

Co sprawia, że uczciwy standard dla niebieskiego zespołu jest pozbawiony blasku i sprawdzalny. Dla każdej kontroli, którą deklarujesz, powinieneś umieć wskazać warstwę, która ją egzekwuje, linię logu, która dowodzi, że zadziałała, alert, który mówi ci, gdy nie zadziałała, oraz osobę, która może zatrzymać ten przebieg. Cztery zdania. Jeśli brakuje jednego z nich, kontrola jest dokumentem polityki, a dokumenty polityki nie czytają ciał żądań.