Bezpieczny agent nie znaczy bezpieczna sieć agentów

Microsoft Research opublikował raport red-teamingowy, który rozbija jeden z wygodnych mitów branży AI: że wystarczy zadbać o bezpieczeństwo każdego agenta z osobna, żeby cały system był bezpieczny.

Sieć agentów to nie suma jej części

Badacze z Microsoftu przetestowali sieci agentów AI działających razem i odkryli kategorie ryzyk, które po prostu nie istnieją na poziomie pojedynczego modelu. Kiedy agent A przekazuje dane do agenta B, który deleguje zadanie do agenta C — każdy z nich może być wzorowo wytrenowany i przechodzić wszystkie standardowe testy bezpieczeństwa. Mimo to na poziomie sieci mogą pojawić się zachowania, których nikt nie projektował i nikt nie przewidział.

To klasyczny problem emergencji, tyle że tym razem z konsekwencjami dla firm wdrażających systemy wieloagentowe w produkcji.

Co konkretnie się psuje?

Raport identyfikuje kilka klas problemów specyficznych dla architektury wieloagentowej:

• Propagacja instrukcji — jeden skompromitowany lub źle skonfigurowany agent może wstrzykiwać polecenia do dalszej części pipeline’u, omijając mechanizmy bezpieczeństwa kolejnych agentów
• Rozmycie odpowiedzialności — gdy żaden pojedynczy agent nie ma pełnego kontekstu operacji, żaden też nie “widzi” że coś idzie nie tak
• Kumulacja małych błędów — każdy agent może działać w granicach normy, ale sekwencja drobnych odchyleń buduje efekt, którego żaden z agentów indywidualnie by nie wygenerował
• Ataki przez zaufanie — agenty domyślnie ufają innym agentom w tej samej sieci, co tworzy wektor ataku nieistniejący w systemach jednoagentowych

Czy branża wdraża agentów zbyt szybko?

Tu robi się interesująco. Firmy takie jak Salesforce, ServiceNow czy SAP już teraz sprzedają klientom enterprise gotowe platformy wieloagentowe. Anthropic pcha Claude’a jako rdzeń ekosystemów agentowych. OpenAI odpalił Responses API i Agents SDK. Nikt z nich nie opublikował niczego zbliżonego do metodologii red-teamingowej dla sieci agentów — przynajmniej nie publicznie.

Microsoft robi tu coś nieoczywistego: przyznaje, że własne narzędzia (Copilot Studio, Azure AI Agent Service) wchodzą w kategorie, które właśnie opisał jako niedostatecznie zbadane pod kątem bezpieczeństwa.

Nowe narzędzia kontra stare frameworki oceny

Standardowe benchmarki bezpieczeństwa — MT-Bench, HarmBench, testy RLHF — mierzą zachowanie modelu w izolacji. Nie mierzą tego, co dzieje się, gdy model operuje jako węzeł w grafie agentów z dostępem do zewnętrznych API, baz danych i innych agentów.

Badacze Microsoftu proponują rozszerzenie metodologii red-teamingowej o testy na poziomie sieci: symulowanie adversarialnych agentów wewnątrz systemu, testowanie propagacji złośliwych promptów przez kolejne warstwy pipeline’u, analizę zachowań emergentnych przy różnych topologiach sieci.

To nie jest propozycja akademicka na przyszłość — raport sugeruje, że firmy wdrażające wieloagentowe systemy już teraz powinny stosować te podejścia.

Kto powinien się tym przejąć?

Przede wszystkim działy IT i security w firmach, które już uruchomiły lub planują uruchomić systemy oparte na orkiestratorach agentów — czy to przez LangChain, CrewAI, AutoGen, czy własne rozwiązania. Architekt, który zaprojektował system złożony z pięciu “bezpiecznych” agentów, nie może założyć że system jako całość jest bezpieczny.

Raport nie podaje konkretnych liczb dotyczących skali zagrożeń — to jakościowe badanie eksploracyjne, nie kwantyfikacja ryzyka. Microsoft Research nie określił też, ile konkretnych podatności wykryto podczas testów ani w jakich środowiskach przeprowadzono eksperymenty.

Pełna metodologia red-teamingowa opisana w raporcie ma trafić do narzędzi open source udostępnianych przez Microsoft — bez podania konkretnej daty.