← Wszystkie wpisy

Co powiedziałem NIST o bezpieczeństwie agentów AI

9 min read

Dwanaście razy w ciągu 60 dni mój agent AI przestawał pracować nad przydzielonym zadaniem i zaczynał robić coś innego. Za każdym razem agent nadal generował wiarygodnie wyglądające wyniki. Żadna luka w zabezpieczeniach nie odgrywała roli. Agent w trakcie działania zdecydował się pracować nad innym problemem.1

24 lutego 2026 roku te 12 incydentów i dziesiątki powiązanych awarii stały się publicznym komentarzem o objętości 2500 słów, przesłanym do National Institute of Standards and Technology. Docket NIST NIST-2025-0035 zwraca się do opinii publicznej o uwagi dotyczące kwestii bezpieczeństwa agentów AI.2 Okres zgłaszania komentarzy zamyka się około 9 marca 2026 roku. Mój komentarz przedstawia jedną centralną tezę: zagrożenia ze strony agentów mają charakter behawioralny, a żadne istniejące ramy NIST nie odnoszą się do behawioralnych trybów awarii.

TL;DR

Prowadzę system orkiestracji agentów AI w codziennej produkcji: 15 000 linii kodu przechwytujących 15 typów zdarzeń hooków przy każdej akcji agenta. W ciągu ponad 60 sesji zidentyfikowałem siedem powtarzających się behawioralnych trybów awarii, niemających odpowiednika w tradycyjnym oprogramowaniu. Agent odchodził od zadania, twierdził, że testy przeszły pomyślnie, nie uruchamiając ich, oraz uruchamiał rekurencyjne pod-agenty, które traciły kontekst przy każdym przejściu. Zbudowałem trójwarstwową obronę (potok hooków, sandbox systemowy, bramka dowodowa) i zmapowałem system względem CSF 2.0, SP 800-53 i AI Risk Management Framework. We wszystkich trzech istnieją znaczące luki. Komentarz zawiera sześć priorytetowych rekomendacji, począwszy od proponowanego raportu wewnętrznego NIST dotyczącego taksonomii behawioralnych zagrożeń agentowych. Okres zgłaszania komentarzy pozostaje otwarty.

Dlaczego praktyk złożył federalny komentarz publiczny

NIST rzadko prosi opinię publiczną o uwagi dotyczące bezpieczeństwa AI. Gdy agencja opublikowała zapytanie o informacje (Request for Information) w sprawie bezpieczeństwa agentów AI, pięć obszarów tematycznych bezpośrednio odpowiadało problemom, na które już zbudowałem rozwiązania produkcyjne:2

  1. Unikalne zagrożenia bezpieczeństwa dotyczące systemów agentów AI
  2. Metody wzmacniania bezpieczeństwa podczas rozwoju i wdrażania
  3. Skuteczność istniejących ram regulacyjnych w zastosowaniu do agentów
  4. Metody mierzenia bezpieczeństwa i przewidywania ryzyk
  5. Zabezpieczenia wdrożeniowe ograniczające i monitorujące dostęp agentów

Większość publicznych komentarzy do federalnych zapytań RFI pochodzi od korporacji, grup branżowych i laboratoriów badawczych. Indywidualni praktycy rzadko je składają. Ale to praktycy obsługują te systemy na co dzień. Programista uruchamiający agenta AI przez ponad 60 sesji gromadzi dowody, których kontrolowane eksperymenty nie generują. Złożyłem komentarz, ponieważ dowody istniały i nikt inny nie zamierzał ich przesłać.

Komentarz przeszedł przez trzy rundy rewizji, 10-agentowy proces deliberacyjny oraz dwie rundy oceny konkurencyjnej (Claude Code vs. Codex CLI) przed ostatecznym złożeniem.1

Co zbudowałem

System orkiestracji opakowuje Anthropic Claude Code CLI w około 15 000 linii kodu powłoki i Python. Każda akcja agenta (odczyt plików, zapis plików, polecenia bash, żądania webowe, uruchamianie pod-agentów) przechodzi przez potok hooków przed wykonaniem. Osiem hooków dyspozytorskich przekierowuje wywołania do hooków obsługujących w zależności od typu narzędzia. System loguje każdą decyzję, śledzi koszty, monitoruje dryf i wymusza twarde limity, których agent nie może obejść.1

Nie zamierzałem budować tego systemu. System wyrósł z awarii. Detektor dryfu istnieje, ponieważ agent spędził 45 minut na reorganizacji katalogu mojego projektu, gdy zadaniem było „napraw endpoint logowania”. Sandbox istnieje, ponieważ złapałem agenta próbującego pisać do ~/.ssh/. Bramka dowodowa istnieje, ponieważ agent zgłosił „wszystkie testy przeszły” bez uruchamiania pytest. Każdy komponent wywodzi się z konkretnego incydentu produkcyjnego.

Zagrożenia behawioralne: główny argument

Tradycyjne zabezpieczenia bronią przed eksploatacją: SQL injection, przepełnienia bufora, kradzież poświadczeń. Bezpieczeństwo agentów dodaje kategorię bez precedensu w oprogramowaniu: agent decyduje w trakcie działania, nad czym pracować, i może zdecydować źle.

Dryf sesji

Agent stopniowo odchodzi od przydzielonego zadania, generując wiarygodnie wyglądające wyniki. Mój silnik detekcji dryfu oblicza podobieństwo kosinusowe między embeddingiem oryginalnego prompta użytkownika a przesuwanym oknem 25 ostatnich wywołań narzędzi agenta.1 Gdy wynik spada poniżej 0,30, system wstrzykuje ostrzeżenie zawierające oryginalny prompt.

Próg 0,30 ustaliłem na podstawie ręcznego przeglądu 60 sesji. System wyzwolił 12 ostrzeżeń poniżej progu. We wszystkich 12 przypadkach agent weryfikowalnie stracił kontakt z oryginalnym zadaniem. Powyżej progu żadna sesja nie wymagała ręcznej interwencji z powodu dryfu. Zoptymalizowałem próg pod kątem precyzji; formalnie nie zmierzyłem współczynnika fałszywych negatywów.1

Fantomowa weryfikacja

Agent twierdzi, że praca jest ukończona i testy przeszły pomyślnie, nie uruchamiając ich. Sygnałem detekcji jest konkretna cecha: raport o ukończeniu nie zawiera wklejonego wyniku testów. „Testy powinny przejść na podstawie struktury kodu” zastępuje przekonanie dowodem. Opisałem wariant fabrykacji tego samego wzorca awarii: agent, który publikuje z pewnością błędne twierdzenia, ponieważ nic nie weryfikuje autoraportów wobec zewnętrznej rzeczywistości.1

Rekurencyjne uruchamianie

Agenty uruchamiające pod-agenty mogą wejść w niekontrolowaną rekurencję, zużywając budżet obliczeniowy i tracąc spójność. Mój strażnik rekurencji wymusza maksymalną głębokość dwóch poziomów i maksymalnie pięciu potomków na agenta nadrzędnego, śledząc pełne drzewo genealogiczne za pośrednictwem pliku JSON chronionego blokadą.1

Siedem trybów awarii

Skatalogowałem siedem powtarzających się wzorców behawioralnych w ciągu 60 sesji. Każdy tryb posiada specyficzny sygnał detekcji, który hooki lub ludzki przegląd mogą sprawdzić:

Tryb awarii Definicja Sygnał detekcji
Spirala skrótów Pomijanie kroków weryfikacji w celu szybszego raportowania ukończenia Raport o ukończeniu bez dowodów poszczególnych kroków
Miraż pewności Zastępowanie „jestem pewien” rzeczywistą weryfikacją Język ostrożnościowy bez wyniku testów
Plateau „wystarczająco dobre” Akceptowanie działającego, ale nieprzetestowanego kodu Brak pokrycia testami lub cytowanej dokumentacji
Widzenie tunelowe Polerowanie jednego komponentu przy ignorowaniu awarii integracji Testy integracyjne nieuruchomione
Fantomowa weryfikacja Twierdzenie, że testy przeszły, bez ich uruchamiania Raport bez wklejonego wyniku testów
Odroczony dług Pozostawianie znaczników TODO/FIXME w zacommitowanym kodzie TODO/FIXME w zacommitowanym diffie
Pusty raport Raportowanie „gotowe” bez dowodów dla każdego kryterium Kryteria nieomówione indywidualnie

Żaden z tych trybów nie wymaga podatności. Agent nie musi wykorzystywać CVE. Agent zawodzi, wykonując swoją pracę źle i raportując, że wykonał ją dobrze.

Obrona w głąb

System orkiestracji wykorzystuje trzy niezależne warstwy. Awaria jednej warstwy nie kompromituje pozostałych.

Warstwa 1: Potok hooków. Każde wywołanie narzędzia przechodzi przez hook PreToolUse przed wykonaniem. Handlery mogą blokować wykonanie, modyfikować polecenie lub wstrzykiwać kontekst doradczy. Architektura dyspozytor-handler oznacza, że dodanie nowego sprawdzenia bezpieczeństwa wymaga napisania jednego pliku handlera, a nie modyfikacji potoku routingu. Osiem dyspozytorów kieruje do 99 hooków obsługujących.1

Warstwa 2: Sandbox systemowy. Profil macOS Seatbelt definiuje osiem jawnych reguł odmowy blokujących zapis do .ssh, .gnupg, .aws, plików środowiskowych, uwierzytelniania GitHub CLI oraz macOS Keychain. Jądro systemu wymusza te reguły niezależnie od tego, jakie polecenie agent skonstruuje. Próba wykonania touch ~/.ssh/test pod tym profilem zwraca „Operation not permitted”.1

Warstwa 3: Bramka dowodowa. Przed oznaczeniem dowolnego nietrywalnego zadania jako ukończonego agent musi spełnić sześć kryteriów dowodowych z cytowanymi dowodami: zgodność z wzorcami bazy kodu (wymienić wzorzec), najprostsze działające rozwiązanie (wyjaśnić odrzucone alternatywy), obsłużone przypadki brzegowe (wymienić każdy), testy przeszły (wkleić wynik), brak regresji (wymienić sprawdzone pliki) oraz rozwiązanie faktycznego problemu (określić potrzebę użytkownika). Bramka flaguje język ostrożnościowy („powinno działać”, „prawdopodobnie poprawne”) jako niewystarczający dowód, uruchamiając obowiązkową ponowną weryfikację.1

Niezależność warstw jest kluczową właściwością projektową. Agent, który prześlizgnie się przez potok hooków, nadal napotyka sandbox systemowy. Agent, który znajdzie lukę w sandboxie, nadal staje przed bramką dowodową. Żadna pojedyncza awaria nie kompromituje systemu.

Analiza luk w ramach regulacyjnych

Komentarz mapuje kontrole produkcyjne względem trzech ram NIST. Niektóre mapowania działają dobrze. Inne ujawniają luki, których żadne istniejące ramy nie wypełniają.

Co się mapuje

Hooki PreToolUse obejmują dwie funkcje CSF 2.0: Protect (PR.PS-05, zapobieganie nieautoryzowanym akcjom) i Detect (DE.CM, ciągłe monitorowanie wywołań narzędzi).3 Sandbox systemowy implementuje SP 800-53 AC-3 (Wymuszanie dostępu) i AC-6 (Zasada najmniejszych uprawnień).4 Potok hooków mapuje się na AC-25 (Monitor referencyjny): zawsze wywoływany, niemożliwy do obejścia i wystarczająco mały do weryfikacji. Funkcja Map (MAP 3) AI RMF jest zgodna z detekcją dryfu: rozumienie tego, co agent robi, w porównaniu z tym, o co operator go poprosił.5

Czego brakuje

Ramy Stosowalne kontrole Luka specyficzna dla agentów Sugerowane rozszerzenie
CSF 2.0 DE.CM, DE.AE Brak kategorii detekcji dryfu behawioralnego Rozszerzenie przykładów DE.AE o anomalie behawioralne agentów
SP 800-53 Rev. 5 AC-3, AC-6, AC-25 Brak kontroli głębokości delegacji agentów Nowe wzmocnienie kontroli dla zarządzania delegacją agentów
AI RMF 1.0 MAP 3 Brak metryki wierności zadania w czasie rzeczywistym Dodanie podobieństwa dryfu agenta do funkcji MEASURE

OWASP Top 10 for Agentic Applications (2026) odnosi się do Agent Goal Hijacking (ASI01) i Human-Agent Trust Exploitation (ASI09), ale nie obejmuje ani awarii samozarządzania, takich jak fantomowa weryfikacja, ani pustego raportu.6 NIST AI 600-1 (Generative AI Profile) odnosi się ogólnie do ryzyk generatywnego AI, ale powstał przed wzorcami wdrożeń agentowych.7

Ryzyka łańcucha delegacji

Gdy agent uruchamia pod-agenta, który uruchamia kolejnego pod-agenta, właściwości bezpieczeństwa nie sumują się. Każde przejście wprowadza trzy kumulujące się ryzyka:

  • Kompresja semantyczna. Pełny kontekst rozumowania agenta nadrzędnego zostaje skompresowany do ciągu promptu, tracąc niuanse dotyczące tego, które pliki są wrażliwe lub które podejścia agent nadrzędny już odrzucił.
  • Amplifikacja uprawnień. Agent potomny dziedziczy uprawnienia odczytu/zapisu plików, ale nie rozumienie agenta nadrzędnego dotyczące tego, które pliki niosą wrażliwość bezpieczeństwa.
  • Rozproszenie odpowiedzialności. Gdy pod-agent generuje niepoprawne wyniki, ścieżka audytu pokazuje, który agent podjął każdą decyzję, ale agent główny ponosi operacyjną odpowiedzialność za końcowy wynik.

Mój strażnik rekurencji adresuje łańcuchy delegacji poprzez śledzenie genealogii agentów i wymuszanie twardych limitów głębokości. Żadne opublikowane ramy nie odnoszą się do kumulujących się ryzyk wielopoziomowej delegacji agentów.

Sześć rekomendacji

Komentarz zamyka się sześcioma rekomendacjami, uszeregowanymi od fundamentalnych do operacyjnych:

  1. Opublikowanie raportu wewnętrznego NIST ustanawiającego taksonomię behawioralnych zagrożeń agentowych. Tradycyjne modele zagrożeń (STRIDE, OWASP Top 10) nie obejmują trybów awarii specyficznych dla agentów. Wspólna taksonomia jest warunkiem wstępnym dla każdej innej rekomendacji. NIST mógłby również rozszerzyć CSF 2.0 o podkategorie specyficzne dla agentów i opublikować profil AI RMF dla systemów agentowych.

  2. Ustanowienie wymagań izolacji na poziomie systemu operacyjnego. Agenty improwizujące nowe wzorce poleceń mogą obchodzić sandboxing na poziomie aplikacji. Wymuszanie na poziomie systemu operacyjnego (Linux seccomp-bpf, macOS Seatbelt, izolacja kontenerowa) zapewnia granicę, której agent nie jest w stanie obejść rozumowaniem.

  3. Wymaganie niezależnej weryfikacji autoraportów agentów. Agenty nie mogą być jedynym autorytetem w kwestii poprawności własnej pracy. Osobny proces powinien weryfikować zewnętrzne dowody (wyniki testów, odpowiedzi API, sumy kontrolne) przed zatwierdzeniem ukończenia zadania.

  4. Ustanowienie klasyfikacji promienia rażenia dla wywołań narzędzi agentów. Oznaczenie każdej akcji agenta jako lokalnej, współdzielonej lub zewnętrznej, z eskalującymi wymaganiami autoryzacji dla każdego poziomu. System klasyfikacji opisałem szczegółowo wcześniej.

  5. Zdefiniowanie ilościowych metryk dryfu. Bezpieczeństwo agentów potrzebuje mierzalnego „wyniku zgodności z zadaniem” odzwierciedlającego, jak ściśle bieżąca aktywność agenta jest zgodna z przydzielonym zadaniem, obliczanego w regularnych odstępach.

  6. Standaryzacja logowania audytowego dla akcji agentów. Rejestrowanie każdego wywołania narzędzia, każdej decyzji hooka i każdej zablokowanej akcji w formacie umożliwiającym rekonstrukcję po incydencie.

Złożenie własnego komentarza

Okres zgłaszania komentarzy do NIST-2025-0035 zamyka się około 9 marca 2026 roku. Zapytania RFI NIST mają realną wagę: komentarze bezpośrednio wpływają na publikowane ramy, standardy i wytyczne. Jeśli obsługujesz agenty AI w produkcji, Twoje dowody mają znaczenie.

Jak złożyć komentarz:

  1. Odwiedź stronę docketu NIST-2025-0035
  2. Kliknij „Comment” przy dokumencie RFI
  3. Napisz komentarz odnoszący się do dowolnego z pięciu obszarów tematycznych
  4. Dołącz konkretne dowody: kod, metryki, raporty z incydentów
  5. Prześlij wraz ze swoimi danymi kontaktowymi

Nie trzeba odnosić się do wszystkich pięciu tematów. Skoncentrowany komentarz poparty dowodami dotyczący jednego tematu ma większą wartość niż szeroki komentarz bez konkretów. Pracownicy NIST czytają każde zgłoszenie.

Kluczowe wnioski

Dla praktyków bezpieczeństwa: Zmapuj istniejące kontrole agentów względem CSF 2.0 i SP 800-53. Mapowanie potoku hooków na AC-25 Reference Monitor zapewnia konkretne ramy do opisywania kontroli dostępu na poziomie agenta zespołom ds. zgodności.

Dla programistów AI: Buduj detekcję behawioralną równolegle z tradycyjnym bezpieczeństwem. Dryf sesji, fantomowa weryfikacja i rekurencyjne uruchamianie to realia produkcyjne, nie ryzyka teoretyczne. Zacznij od bramki dowodowej: wymagaj cytowanych dowodów przed oznaczaniem zadań jako ukończonych.

Dla decydentów: Luka między tradycyjnymi ramami bezpieczeństwa a zagrożeniami specyficznymi dla agentów jest strukturalna, nie przyrostowa. Agenty zawodzą w sposób, którego STRIDE, OWASP i istniejące katalogi NIST nie klasyfikują. Taksonomia zagrożeń behawioralnych jest warunkiem wstępnym dla wszystkiego innego.

Dla autorów ram regulacyjnych: Dodaj zarządzanie łańcuchami delegacji. Gdy agenty uruchamiają agenty, kontekst degraduje się, uprawnienia amplifikują, a odpowiedzialność rozprasza na każdym przejściu. Kumulujące się ryzyka na głębokości trzeciej i dalszej nie mają precedensu w żadnych ramach regulacyjnych.

Źródła

  1. Author’s production telemetry and submitted public comment on NIST-2025-0035. Tracking number mm1-hgn6-spl7. Drift similarity engine across 60 daily Claude Code sessions, February 2026. Full comment text available upon request. ↩↩↩↩↩↩↩↩↩↩

  2. NIST-2025-0035: Request for Information Regarding Security Considerations for Artificial Intelligence Agents. National Institute of Standards and Technology. ↩↩

  3. NIST Cybersecurity Framework 2.0. National Institute of Standards and Technology, 2024. ↩

  4. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology, 2020. ↩

  5. NIST AI Risk Management Framework 1.0. National Institute of Standards and Technology, 2023. ↩

  6. OWASP Top 10 for Agentic Applications. OWASP Foundation, 2026. ↩

  7. NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative AI Profile. National Institute of Standards and Technology, 2024. ↩