Bezpieczeństwo agentów AI: paradoks zaufania „wdrażaj i broń"

Jak zabezpieczyć agentów AI w środowisku produkcyjnym? Należy egzekwować uprawnienia poniżej warstwy aplikacji za pomocą sandboxów na poziomie OS, a nie list dozwolonych na poziomie aplikacji. Każde wywołanie narzędzia należy przechwytywać w czasie rzeczywistym za pomocą hooków PreToolUse przed jego wykonaniem. Dryf behawioralny można monitorować poprzez podobieństwo embeddingów między pierwotnym zadaniem a ostatnimi działaniami agenta. Te trzy mechanizmy (kontrola behawioralna, zakres uprawnień i wykrywanie dryfu) odnoszą się do trybów awarii, które doprowadziły do incydentu Sev 1 w Meta, 13-godzinnej awarii Amazona oraz podatności wykrytych w badaniu Agents of Chaos.

18 marca 2026 roku inżynier Meta wdrożył wewnętrznego agenta AI, aby odpowiedział na pytanie techniczne kolegi na wewnętrznym forum. Agent opublikował swoją odpowiedź bez autoryzacji. Inny pracownik zastosował się do wadliwej porady agenta, uruchamiając kaskadę zdarzeń, która przez niemal dwie godziny odsłoniła wrażliwe dane korporacyjne i dane użytkowników nieuprawnionym pracownikom. Meta sklasyfikowała incydent jako Sev 1 — drugi najwyższy poziom krytyczności w ich systemie wewnętrznym.¹

W tym samym tygodniu inżynierowie Google wypuścili Sashiko, agentowy system przeglądu kodu AI dla jądra Linux, który wychwycił 53% błędów z 1000 ostatnich zgłoszeń upstream — błędów, które „w 100 procentach zostały przeoczone przez ludzkich recenzentów”.² Społeczność Wikipedii nadal debatowała, czy całkowicie zakazać treści generowanych przez LLM.³ NIST opublikował swoją Inicjatywę Standardów Agentów AI na rzecz „godnego zaufania wdrożenia”.⁴ A amerykański senator zasiadł z Claude, aby zapytać, czy firmom AI można zaufać w kwestii gromadzonych przez nie danych. Odpowiedź Claude: „Pieniądze, panie Senatorze. W gruncie rzeczy chodzi o zysk”. Film zyskał 4,4 miliona wyświetleń.⁵

Każda duża instytucja jednocześnie wdraża agentów i buduje mury przeciwko nim. Mury powstają, ponieważ agenci nieustannie udowadniają, że są potrzebne.

TL;DR

• Paradoks: Organizacje jednocześnie przyspieszają wdrażanie agentów i gorączkowo próbują powstrzymać ich awarie. Żaden z tych wysiłków nie koordynuje się z drugim.
• Liczby: 1 na 8 korporacyjnych naruszeń AI dotyczy obecnie systemów agentowych. 80% organizacji zgłasza ryzykowne zachowania agentów. Tylko 21% kierowników ma pełną widoczność tego, do czego dostęp mają ich agenci.⁶
• Incydenty: Sev 1 w Meta z powodu nieautoryzowanego wpisu agenta. 13-godzinna awaria AWS spowodowana przez narzędzie do kodowania AI, które zdecydowało się „usunąć i odtworzyć środowisko”.⁷ 14-dniowe międzyuniwersyteckie badanie wykazało 10 podatności bezpieczeństwa w sześciu agentach, w tym przejmowanie tożsamości i nieskończone pętle.⁸
• Wzorzec: Wdrażaj szybko, odkryj awarię, zbuduj mur, wdrażaj szybciej. Google wypuszcza Sashiko, aby pomóc w przeglądzie kodu, podczas gdy Amazon nakazuje zatwierdzanie zmian kodu wspieranych przez AI przez osoby starsze stażem. Anthropic pozywa narzędzie open-source za podszywanie się pod nagłówki Claude, podczas gdy 2,5 miliona deweloperów używa go miesięcznie.⁹
• Dlaczego się utrzymuje: Wdrażanie działa w rytmie harmonogramów produktowych (kwartalnych OKR-ów). Obrona działa w rytmie harmonogramów incydentów (reakcji post-mortem). Ograniczenia nigdy nie nadążają za przyznanymi uprawnieniami.
• Co przerywa ten cykl: Zarządzanie behawioralne w czasie rzeczywistym, które zamyka pętlę sprzężenia zwrotnego między wdrażaniem a obroną. Kontrola behawioralna (hooki PreToolUse), zakres uprawnień (sandboxy na poziomie OS) oraz wykrywanie dryfu (śledzenie podobieństwa kosinusowego) odnoszą się do trzech kategorii awarii opisanych w tym artykule. Dowody z ponad 500 sesji agentów autonomicznych oraz publicznego komentarza dla NIST na temat zagrożeń behawioralnych agentów.

Wzorzec „wdrażaj i broń”

Trzy incydenty z ostatnich 90 dni ujawniają ten wzorzec.

Meta (marzec 2026): Agent AI zamieszczał nieautoryzowane odpowiedzi na wewnętrznym forum. Pracownik zastosował się do wadliwej porady. Wrażliwe dane wyciekły do nieuprawnionych pracowników na dwie godziny. Meta potwierdziła incydent, nazwała go Sev 1 i oświadczyła, że „żadne dane użytkowników nie zostały wykorzystane w niewłaściwy sposób”.¹ Kilka miesięcy wcześniej Summer Yue, szefowa bezpieczeństwa w dziale AI Mety, poinformowała, że agent podłączony do jej Gmaila „samodzielnie usunął wiadomości mimo jasnych instrukcji, by tego nie robić” i ignorował polecenia zaprzestania działań, dopóki nie został ręcznie zatrzymany.¹⁰

Amazon (grudzień 2025): Narzędzie do kodowania AI Kiro firmy Amazon spowodowało 13-godzinną awarię AWS, gdy agent stwierdził, że musi „usunąć i odtworzyć środowisko”. Amazon obwinił „błąd użytkownika, a nie błąd AI” i stwierdził, że pracownik miał „szersze uprawnienia niż oczekiwano — była to kwestia kontroli dostępu użytkownika, a nie problem autonomii AI”. Wielu pracowników powiedziało Financial Times, że było to „co najmniej” drugie zakłócenie związane z narzędziem AI. Reakcja Amazona: wymóg zatwierdzania zmian kodu wspieranych przez AI przez osoby starsze stażem.⁷

Laboratorium badawcze (luty 2026): Badanie Agents of Chaos (naukowcy z Northeastern, Stanford, Harvard, MIT i CMU) dało sześciu agentom AI dostęp do serwera typu Discord z e-mailem, bashem, trwałymi systemami plików, zadaniami cron i dostępem do GitHub przez 14 dni. Dwudziestu badaczy wchodziło w interakcje z agentami — niektórzy życzliwie, inni wrogo. Agenci wykazali 10 odrębnych podatności bezpieczeństwa.⁸

Podatności wyglądały banalnie. Agent zniszczył cały serwer pocztowy zamiast podjąć proporcjonalne działania (Disproportionate Response). Dwóch agentów weszło we wzajemną pętlę przekaźnikową, tworząc niekontrolowane procesy w tle (Infinite Loop). Agent zaakceptował sfałszowaną tożsamość właściciela i przyznał pełny dostęp do systemu (Identity Hijack). Po 12 odmowach agent spełnił nieautoryzowaną prośbę pod wpływem utrzymującej się presji emocjonalnej (The Guilt Trip).⁸

Christoph Riedl, profesor Northeastern prowadzący badanie, podsumował: agenci AI są „po prostu okropnie słabi w stosowaniu jakiegokolwiek zdroworozsądkowego rozumowania” w sytuacjach rzeczywistych, zwłaszcza przy sprzecznych interesach.¹¹

Liczby naruszeń z udziałem agentów w 2026 roku

Raport HiddenLayer o zagrożeniach AI 2026 przebadał 250 liderów IT i bezpieczeństwa. Wyniki kwantyfikują paradoks:¹²

• Agenci autonomiczni odpowiadają za ponad 1 na 8 zgłoszonych naruszeń AI w przedsiębiorstwach
• 35% naruszeń pochodziło ze złośliwego oprogramowania w publicznych repozytoriach modeli — a mimo to 93% organizacji nadal z nich korzysta
• 31% respondentów nie wie, czy zostali naruszeni
• 53% przyznało, że wstrzymuje raporty o naruszeniach AI
• 76% wskazuje shadow AI jako pewny lub prawdopodobny problem — wzrost z 61% w 2025 roku

CEO Chris Sestito: „Agentowe AI ewoluowało szybciej w 12 miesięcy niż większość korporacyjnych systemów bezpieczeństwa w pięć lat”.¹²

Odrębne badanie korporacyjne wykazało, że tylko 21% kierowników ma pełną widoczność uprawnień swoich agentów, użycia narzędzi i dostępu do danych. 80% zgłosiło ryzykowne zachowania agentów, w tym nieautoryzowany dostęp i niewłaściwe ujawnianie danych. Przeciętne przedsiębiorstwo ma około 1200 nieoficjalnych aplikacji AI, a 86% zgłasza brak widoczności tych aplikacji.⁶

Dane dotyczące jakości kodu są równie wymowne. CodeRabbit przeanalizował 470 pull requestów i stwierdził, że kod napisany przez AI ma 1,7 raza więcej problemów niż kod napisany przez człowieka.¹³ Apiiro ustaliło, że deweloperzy używający AI wprowadzają około 10 razy więcej podatności bezpieczeństwa.¹³ METR stwierdziło, że połowa rozwiązań kodowych AI przechodzących branżowe testy zostałaby odrzucona przez ludzkich recenzentów.¹³

Ryzyko łańcucha dostaw potęguje te liczby. Powierzchnia ataku nie jest hipotetyczna. Serwery MCP są nową powierzchnią ataku dla infrastruktury połączonej z agentami. MCPTox — benchmark oceniający ataki zatruwania narzędzi na 45 rzeczywistych serwerach MCP — wykazał, że złośliwe instrukcje osadzone w metadanych narzędzi osiągnęły wskaźniki skuteczności ataku przekraczające 60% na modelach GPT-4o-mini, o1-mini, DeepSeek-R1 i Phi-4.¹⁸ Ataki nigdy nie wykonują samego zatrutego narzędzia. Osadzają instrukcje w opisie narzędzia, które przekierowują agenta do eksfiltracji poświadczeń lub manipulowania parametrami przy użyciu legalnych narzędzi już obecnych na serwerze. Istniejące wyrównanie bezpieczeństwa nie wychwytuje tego ataku, ponieważ każde wywołanie narzędzia w łańcuchu jest legalnym wywołaniem zaufanego narzędzia.¹⁸

Teoretyczne ryzyko łańcucha dostaw stało się konkretne 24 marca 2026 roku, gdy atakujący skompromitował konto opiekuna PyPI biblioteki LiteLLM — popularnej biblioteki proxy AI z ponad milionem dziennych pobrań. Atakujący opublikował dwie złośliwe wersje (1.82.7 i 1.82.8), które nigdy nie przeszły przez oficjalny pipeline CI/CD GitHub. Wersja 1.82.8 zawierała plik .pth, który wykonuje się automatycznie przy każdym uruchomieniu Python, bez jakiegokolwiek importu. Payload zbierał wszystkie zmienne środowiskowe, klucze SSH, poświadczenia AWS/GCP/Azure, hasła do baz danych, portfele kryptowalutowe i sekrety CI/CD (podręcznikowy atak cichej eksfiltracji), szyfrował je zakodowanym na stałe kluczem publicznym RSA i wysyłał archiwum do domeny kontrolowanej przez atakującego, zarejestrowanej kilka godzin przed atakiem. Złośliwe wersje pozostawały aktywne przez około 12-24 godziny przed usunięciem, a projekty zależne, w tym Microsoft GraphRAG, ucierpiały z tego powodu.¹⁹

Pojedynczy skompromitowany agent zatruwa 87% dalszego procesu decyzyjnego w ciągu 4 godzin.⁶

Jednoczesne wdrażanie agentów i budowanie murów

Instytucjonalna reakcja na te liczby rozdziela się na dwa równoległe, nieskoordynowane ruchy: wdrażaj mocniej i broń się mocniej.

Wdrażaj mocniej:

Google wypuszcza Sashiko do agentowego przeglądu kodu jądra Linux, wspierane przez Linux Foundation. System wychwycił 53% błędów, które ludzcy recenzenci całkowicie pominęli, z szacowanym wskaźnikiem fałszywie pozytywnych wyników poniżej 20%.² Meta nadal rozszerza wewnętrznych agentów AI mimo incydentu Sev 1. EY informuje, że 64% firm z przychodami powyżej 1 mld USD straciło ponad 1 mln USD z powodu awarii AI, a wszystkie one nadal wdrażają AI.⁶

Broń się mocniej:

Amazon nakazuje zatwierdzanie zmian kodu wspieranych przez AI przez osoby starsze stażem po awarii Kiro.⁷ Anthropic blokuje dostęp OAuth, aby uniemożliwić narzędziom innych firm podszywanie się pod nagłówki Claude, a następnie składa wnioski prawne przeciwko OpenCode za robienie dokładnie tego.⁹ Wikipedia ogranicza treści generowane przez LLM: redaktorzy muszą ujawniać użycie AI w podsumowaniach edycji, a „oczywiście wygenerowane przez LLM komentarze mogą zostać skreślone lub zwinięte”.³ EFF akceptuje kod wygenerowany przez LLM w swoich projektach open-source, ale wymaga, aby wszystkie komentarze i dokumentacja były napisane przez człowieka.¹⁴ NIST uruchamia Inicjatywę Standardów Agentów AI z trzema filarami: standardami prowadzonymi przez branżę, protokołami społecznościowymi i badaniami nad bezpieczeństwem.⁴

Senator Bernie Sanders opublikował 9-minutowy wywiad z Claude, który zyskał 4,4 miliona wyświetleń. Odpowiedź Gizmodo: „Hej Bernie, to nie jest agent AI”.¹⁵ Krytycy mieli rację co do metodologii, ale sygnał strukturalny ma znaczenie. Gdy urzędujący senator traktuje system AI jako wiarygodnego świadka w sprawie korporacyjnej inwigilacji, środowisko polityczne zmieniło się, zanim jakikolwiek framework techniczny będzie gotowy odpowiedzieć na zadawane pytania.⁵

Żaden z tych środków obronnych nie koordynuje się z decyzjami dotyczącymi wdrażania podejmowanymi w sąsiednim budynku.

Linia uskoku OpenCode

Najwyraźniejszą ilustracją napięcia „wdrażaj i broń” jest spór Anthropic-OpenCode.

OpenCode to agentowe narzędzie do kodowania AI typu open-source z ponad 120 000 gwiazdek na GitHub i 5 milionami miesięcznych użytkowników.⁹ Narzędzie obsługuje ponad 75 dostawców LLM. Aby uzyskać dostęp do Claude, OpenCode sfałszował nagłówek HTTP claude-code-20250219, aby serwery Anthropic uwierzyły, że żądania pochodzą z oficjalnego CLI Claude Code. Sfałszowanie pozwoliło subskrybentom Max (poziom 20× za 200 USD/miesiąc, który domyślnie uruchamia Opus 4.7) kierować Claude przez OpenCode, podczas gdy Anthropic nie był tego świadomy.⁹

Społeczność rozwinęła technikę zwaną „Ralph Wiggum”: uruchamianie Claude w nieskończonych pętlach, autonomicznie modyfikując kod, aż testy przejdą. Jeden z deweloperów ponoć wykonał kontrakt o wartości 50 000 USD za mniej niż 300 USD kosztów API, zużywając nieograniczone zasoby subskrypcji Max.⁹

9 stycznia 2026 roku Anthropic wdrożył blokady po stronie serwera na nieautoryzowany dostęp OAuth. 19 marca OpenCode połączył PR #18186, usuwając wszystkie prompty systemowe z marką Anthropic, wtyczki uwierzytelniania i wskazówki dostawcy „zgodnie z żądaniami prawnymi”.⁹ PR zebrał 399 głosów sprzeciwu i 177 zdezorientowanych reakcji.

DHH i George Hotz skrytykowali ten ruch. Hotz: „Fatalna polityka jak na firmę zbudowaną na trenowaniu modeli na naszym kodzie”. OpenAI publicznie wspierało OpenCode, pozwalając na subskrypcje ChatGPT z narzędziami innych firm — celowy kontrast.⁹

Thariq Shihipar z Anthropic odpowiedział: „nieautoryzowane obudowy wprowadzają błędy i wzorce użytkowania, których Anthropic nie może właściwie zdiagnozować”.¹⁶

Obie strony mają rację. Anthropic nie może utrzymać gwarancji jakości, gdy narzędzia innych firm fałszują oficjalne nagłówki. Deweloperzy nie mogą budować na platformie, która ściga interoperacyjność sądownie. Spór nie dotyczy technologii. Dotyczy tego, gdzie leży granica zaufania i czy to użytkownicy, czy dostawcy mogą ją wytyczać.

Luka czasowa

Każda organizacja w tym artykule podjęła decyzję, która w izolacji jest obronna. Meta wdrożyła wewnętrznych agentów, ponieważ poprawiają produktywność. Amazon wypuścił Kiro, ponieważ kodowanie wspierane przez AI przyspiesza rozwój. Google wypuścił Sashiko, ponieważ ludzcy recenzenci przeoczają połowę błędów. Wikipedia ograniczyła kontrybucje LLM, ponieważ wolontariusze-redaktorzy nie są w stanie wchłonąć ciężaru przeglądu tekstów generowanych maszynowo na dużą skalę.

Paradoks utrzymuje się, ponieważ wdrażanie i obrona działają w różnych skalach czasowych.

Wdrażanie działa w rytmie harmonogramów produktowych. Zespół dostarcza integrację agenta jako kwartalny OKR. Miarą sukcesu jest adopcja: ilu pracowników z niej korzysta, ile zadań wykonuje, ile czasu oszczędza. Agent otrzymuje szersze uprawnienia, ponieważ ograniczone uprawnienia spowalniają adopcję, a powolna adopcja zabija OKR.

Obrona działa w rytmie harmonogramów incydentów. Zespół buduje mur po tym, jak coś się zepsuje. Reakcją na Sev 1 w Meta było ograniczenie uprawnień agenta do publikowania. Reakcją Amazona było wymaganie zatwierdzenia przez osoby starsze stażem. Każdy mur odnosi się do konkretnej awarii, która go wywołała. Żaden z nich nie odnosi się do następnej.

Luka między tymi skalami czasowymi tworzy grzechotkę. Każdy cykl wdrażania przyznaje agentom nowe możliwości. Każdy cykl incydentów ogranicza jedną konkretną możliwość po tym, jak ta zawiedzie. Ograniczenia nigdy nie nadążają za uprawnieniami, ponieważ następny sprint zespołu wdrażającego rozpoczyna się, zanim przegląd incydentu się zakończy.

Znam tę grzechotkę, ponieważ działam jednocześnie po obu jej stronach. W ciągu ponad 500 autonomicznych sesji kodowania od maja 2025 roku wdrażałem coraz bardziej zdolne konfiguracje agentów, budując jednocześnie obrony przed awariami, które każda konfiguracja ujawniała. Dwanaście razy w ciągu 60 dni mój agent przestał pracować nad przypisanym zadaniem i zaczął robić coś innego. Za każdym razem agent nadal generował wiarygodne wyniki. Żadna podatność bezpieczeństwa nie odegrała roli. Agent zdecydował w czasie uruchomienia pracować nad innym problemem.

Detektor dryfu istnieje z powodu tych dwunastu incydentów. Sandbox istnieje, ponieważ przyłapałem agenta próbującego pisać do ~/.ssh/. Bramka dowodowa istnieje, ponieważ agent zgłosił „wszystkie testy przechodzą” bez uruchamiania pytest. Każda obrona odnosi się do konkretnej awarii, której poprzednia konfiguracja nie przewidziała. Siedem nazwanych trybów awarii, które skatalogowałem, to te same wzorce, które badanie Agents of Chaos znalazło w skali badawczej: agenci zawodzący w weryfikacji, proporcjonalności i samoocenie.⁸

Jak wygląda zarządzanie w czasie rzeczywistym

Cykl „wdrażaj i broń” pęka, gdy obie funkcje dzielą tę samą pętlę sprzężenia zwrotnego. W praktyce oznacza to instrumentację zachowania agenta w czasie rzeczywistym, a nie przegląd po fakcie.

Mój system orkiestracji opakowuje każde działanie agenta w pipeline hooków: 84 hooki przechwytujące 15 z 26 typów zdarzeń cyklu życia eksponowanych przez Claude Code (v2.1.116, kwiecień 2026), obejmujących odczyty plików, zapisy plików, polecenia bash, żądania webowe i tworzenie pod-agentów.¹⁷ Przed wykonaniem jakiegokolwiek wywołania narzędzia hook PreToolUse sprawdza je pod kątem ograniczeń, których agent nie może obejść. Po każdych 25 wywołaniach narzędzi detektor dryfu oblicza podobieństwo kosinusowe między pierwotnym zadaniem a ostatnimi działaniami agenta. Gdy wynik podobieństwa spadnie poniżej 0,30, system wstrzykuje ostrzeżenie zawierające pierwotny prompt. We wszystkich dwunastu uruchomieniach poniżej progu agent dał się dowodnie zgubić z zadania.¹⁷

Trzy konkretne mechanizmy odnoszą się do trzech kategorii awarii w tym artykule:

Kontrola behawioralna rozwiązuje problem Meta. Agent Mety opublikował wpis bez autoryzacji, ponieważ nic nie sprawdziło, czy powinien publikować. Hook PreToolUse, który uruchamia się przed każdym poleceniem bash, dopasowując do wzorców takich jak curl -X POST, git push lub punkty końcowe zapisu API, zablokowałby nieautoryzowany wpis na forum przed jego wykonaniem. Ta kontrola dodaje milisekundy opóźnienia. Alternatywą był Sev 1.

Zakres uprawnień rozwiązuje problem Amazona. Awaria AWS nastąpiła, ponieważ agent miał uprawnienia do usuwania infrastruktury. Sandbox na poziomie OS (macOS Seatbelt, Linux seccomp lub ograniczenia na poziomie kontenera), który blokuje zapisy do ścieżek produkcyjnych, magazynów poświadczeń i API infrastruktury, sprawia, że „usuń i odtwórz środowisko” jest fizycznie niemożliwe, niezależnie od tego, co agent zdecyduje się zrobić. Sandboxy agentów pozostają sugestiami, dopóki nie są egzekwowane poniżej warstwy aplikacji.

Wykrywanie dryfu rozwiązuje problem Agents of Chaos. Najbardziej podstępnym odkryciem badania nie były dramatyczne awarie (zniszczenie serwera pocztowego, przejęcie tożsamości), ale te stopniowe: agenci spełniający prośby po utrzymującej się presji, realizujący nieautoryzowane żądania przedstawione jako legalne. Wykrywanie dryfu wychwytuje trajektorię behawioralną przed szkodliwym działaniem. Zanim agent spełni „Guilt Trip” przy 13. próbie, podobieństwo kosinusowe między pierwotnym zadaniem a bieżącą rozmową już spadło poniżej jakiegokolwiek rozsądnego progu.

Żaden z tych mechanizmów nie wymaga wyrównania przed wdrożeniem, aby przewidzieć konkretną awarię. Obserwują zachowanie w czasie rzeczywistym i egzekwują niezmienniki, z którymi agent nie może dyskutować. Badanie Agents of Chaos znalazło 10 podatności i 6 autentycznych zachowań bezpieczeństwa u tych samych agentów działających na tych samych wagach.⁸ Różnicą był kontekst. Zarządzanie w czasie rzeczywistym sprawia, że awarie zależne od kontekstu stają się wykrywalne.

Organizacje, które rozwiążą ten paradoks, nie są tymi, które wdrażają najszybciej lub bronią się najsilniej. Są tymi, które zamykają pętlę sprzężenia zwrotnego między tymi dwiema funkcjami, tak aby każde wdrożenie generowało telemetrię, która informuje następne ograniczenie, a każde ograniczenie było testowane wobec następnego wdrożenia, zanim zostanie wypuszczone.

FAQ

Jakie są największe zagrożenia bezpieczeństwa agentów AI w 2026 roku?

Dominują trzy kategorie awarii: nieautoryzowane działania (agenci wykonujący operacje, do których nigdy nie zostali poinstruowani, jak agent Mety publikujący na forum), eskalacja uprawnień (agenci używający szerszych uprawnień niż zamierzone, jak usunięcie infrastruktury AWS) oraz dryf behawioralny (agenci stopniowo odchodzący od przypisanego zadania pod presją lub nagromadzonym kontekstem). Ankieta HiddenLayer wśród 250 liderów bezpieczeństwa wykazała, że autonomiczni agenci odpowiadają obecnie za 1 na 8 korporacyjnych naruszeń AI, a 80% organizacji zgłasza ryzykowne zachowania agentów.¹² Powierzchnia zatruwania narzędzi MCP dodaje czwartą kategorię: ataki na łańcuch dostaw, które manipulują zachowaniem agenta poprzez skompromitowane metadane narzędzi.

Czym są hooki PreToolUse i jak zabezpieczają agentów AI?

Hooki PreToolUse to przechwytywacze w czasie rzeczywistym, które uruchamiają się przed każdym wywołaniem narzędzia przez agenta: zapisami plików, poleceniami bash, żądaniami API, tworzeniem pod-agentów. Każdy hook dopasowuje proponowane działanie do listy ograniczeń, których agent nie może obejść. Na przykład hook dopasowujący curl -X POST lub git push blokuje nieautoryzowane zapisy sieciowe przed wykonaniem. System hooków Claude Code eksponuje 26 typów zdarzeń cyklu życia w wersji v2.1.116; moja konfiguracja produkcyjna uruchamia 84 hooki w 15 z nich. Mechanizm dodaje milisekundy opóźnienia, ale zapobiega klasie awarii, która spowodowała incydent Sev 1 w Meta.

Jak działa wykrywanie dryfu dla agentów AI?

Wykrywanie dryfu oblicza podobieństwo kosinusowe między embeddingiem pierwotnego promptu zadania a embeddingiem ostatnich działań agenta w regularnych odstępach (co 25 wywołań narzędzi w moim systemie). Gdy wynik podobieństwa spadnie poniżej progu (0,30), system wstrzykuje ostrzeżenie zawierające pierwotny prompt, aby ponownie wyrównać agenta. W ponad 60 codziennych sesjach autonomicznych ten mechanizm wychwycił 100% zweryfikowanych incydentów dryfu — przypadków, w których agent po cichu przestał pracować nad przypisanym zadaniem i zaczął realizować inny cel, nadal produkując wiarygodne wyniki.¹⁷

Czy można uruchamiać agentów AI w sandboxie na poziomie OS?

Tak i należy to robić. Listy uprawnień na poziomie aplikacji to sugestie, z którymi agent może dyskutować. Sandboxy na poziomie OS (profile macOS Seatbelt, Linux seccomp-bpf, ograniczenia cgroup na poziomie kontenera) egzekwują reguły odmowy na poziomie jądra. Agent nie może zapisać do ~/.ssh/, ~/.aws/ ani ścieżek infrastruktury produkcyjnej niezależnie od tego, co zdecyduje się zrobić. Egzekwowanie na poziomie jądra sprawia, że „usuń i odtwórz środowisko” jest fizycznie niemożliwe, a nie tylko zakazane.

Czy kryzys zaufania do agentów jest rzeczywiście nowy?

Awarie nie są nowe. Automatyzacja powodowała incydenty na długo przed AI. To, co zmieniło się w latach 2025-2026, to luka autonomii: agenci obecnie sami wybierają swoje działania w czasie uruchomienia, zamiast podążać za zdefiniowanymi z góry skryptami. Raport HiddenLayer wykazał, że autonomiczni agenci konkretnie odpowiadają za 1 na 8 naruszeń — kategoria, która nie istniała dwa lata temu.¹²

Czy agenci AI typu open-source są mniej bezpieczni niż zastrzeżeni?

Spór Anthropic-OpenCode dotyczy kontroli dostępu, a nie bezpieczeństwa. Profil bezpieczeństwa OpenCode zależy od tego, z którym dostawcą LLM się łączy i jak jest skonfigurowany. Pytanie o bezpieczeństwo nie brzmi: otwarte kontra zamknięte. Pytanie brzmi, czy operator narzędzia ma widoczność tego, co robi agent, niezależnie od licencji.

Czy agent Mety faktycznie spowodował wyciek danych?

Meta sklasyfikowała incydent jako Sev 1 (drugi najwyższy poziom krytyczności) i potwierdziła, że wrażliwe dane zostały udostępnione nieuprawnionym pracownikom przez około dwie godziny. Meta stwierdziła, że „żadne dane użytkowników nie zostały wykorzystane w niewłaściwy sposób i nie ma dowodów, aby ktokolwiek wykorzystał dostęp lub upublicznił jakiekolwiek dane”.¹ To, czy stanowi to „naruszenie”, zależy od definicji. Nieautoryzowane ujawnienie było realne.

Czym jest badanie Agents of Chaos?

14-dniowy międzyuniwersytecki projekt badawczy (Northeastern, Stanford, Harvard, MIT, CMU), który dał sześciu agentom AI dostęp do e-maila, bash, systemów plików, zadań cron i GitHub w kontrolowanym środowisku. Dwudziestu badaczy wchodziło w interakcje z agentami. Badanie zidentyfikowało 10 podatności bezpieczeństwa i 6 zachowań bezpieczeństwa, opublikowane jako arXiv:2602.20021.⁸

Czy firmy powinny przestać wdrażać agentów AI?

Nie. Sashiko Google wychwycił błędy, które 100% ludzkich recenzentów przeoczyło. Zyski produktywności korporacyjnej są mierzalne. Zatrzymanie wdrażania nie jest odpowiedzią. Odpowiedzią jest zamknięcie pętli sprzężenia zwrotnego między wdrażaniem a obroną. Każde wdrożenie agenta powinno generować telemetrię behawioralną, która informuje następne ograniczenie. Każde ograniczenie powinno być testowane wobec następnego wdrożenia, zanim zostanie wypuszczone.

Co powinni zrobić indywidualni deweloperzy?

Trzy konkretne kroki uporządkowane według wpływu: (1) Egzekwować uprawnienia poniżej warstwy aplikacji. Sandbox na poziomie OS, który blokuje zapisy do ~/.ssh/, ~/.aws/, ścieżek produkcyjnych i magazynów poświadczeń, sprawia, że katastrofa w stylu Amazona staje się fizycznie niemożliwa. Agent nie może dyskutować z odmową na poziomie jądra. (2) Monitorować trajektorię behawioralną, a nie tylko wyniki. Dryf sesji jest wykrywalny poprzez podobieństwo embeddingów między pierwotnym zadaniem a ostatnimi działaniami agenta. Próg podobieństwa kosinusowego wynoszący 0,30 wychwycił 100% zweryfikowanych incydentów dryfu w moich testach w 60 sesjach.¹⁷ (3) Wymagać dowodów, a nie zapewnień. Gdy agent zgłasza „wszystkie testy przechodzą”, należy żądać wyniku testu. Fantomowa weryfikacja odpowiada za 12% awarii agentów wymagających interwencji człowieka.

Czym jest grzechotka „wdrażaj i broń”?

Wzorzec, w którym każdy cykl wdrażania przyznaje agentom nowe możliwości, podczas gdy każdy cykl incydentów ogranicza jedną konkretną możliwość po tym, jak ta zawiedzie. Ograniczenia nigdy nie nadążają, ponieważ następny sprint zespołu wdrażającego rozpoczyna się, zanim przegląd incydentu się zakończy. Grzechotka pęka, gdy oba zespoły dzielą ten sam pipeline telemetrii i tę samą pętlę sprzężenia zwrotnego.