1 maja 2026 roku sześć agencji wywiadowczych i cyberbezpieczeństwa z pięciu krajów opublikowało wspólny dokument: CISA i NSA ze Stanów Zjednoczonych, ASD ACSC z Australii, CCCS z Kanady, NCSC-NZ z Nowej Zelandii, NCSC-UK z Wielkiej Brytanii. Trzydzieści stron pod tytułem "Careful Adoption of Agentic AI Services" — pierwsza skoordynowana wielorządowa wytyczna bezpieczeństwa dotycząca agentów AI.
To jest sygnał polityczny. Kiedy sześć agencji bezpieczeństwa z pięciu krajów podpisuje jeden dokument, temat przeszedł z kategorii "problem branży technologicznej" do kategorii "priorytet bezpieczeństwa narodowego."
Ale dokument zawiera jedno zdanie, które jest ważniejsze niż wszystkie rekomendacje razem wzięte i które większość omówień pomija: "Until security practices, evaluation methods and standards mature, organisations should assume that agentic AI systems may behave unexpectedly and plan deployments accordingly, prioritising resilience, reversibility and risk containment over efficiency gains."
CISA i NSA wprost przyznają że nie wiedzą jeszcze jak zabezpieczyć agenty AI. To jest fundamentalna różnica między tym dokumentem a standardowymi wytycznymi bezpieczeństwa które opisują sprawdzone praktyki dla znanych problemów.
Pięć kategorii ryzyka i gdzie je widziałeś na cyberflux
Dokument identyfikuje pięć kategorii ryzyka dla systemów agentowych. Każda z nich jest bezpośrednio zilustrowana przez incydenty które cyberflux opisywał przez ostatnie tygodnie — nie jako przypadkowy zbieg okoliczności, ale dlatego że wytyczne opisują klasy problemów które już w praktyce istnieją.
Ryzyko uprawnień. Nadmiernie uprzywilejowany agent może po skompromitowaniu wyrządzić szkody proporcjonalne do swoich uprawnień, nie do punktu wejścia. To jest dokładny mechanizm Entra Agent ID Administrator — rola zarządzania tożsamościami agentów AI z dostępem do każdego Service Principala w tenancie — i PocketOS — agent z dostępem do tokenu Railway który miał uprawnienia do wszystkiego, nie tylko do domeny którą miał zarządzać.
Ryzyko projektowe i konfiguracyjne. Niebezpieczna architektura i integracje zewnętrzne jako wektory podatności. Tu jest architektoniczny błąd STDIO w MCP — 200 000 serwerów, dziedziczona ekspozycja dla każdego dewelopera budującego na protokole — i Cursor CVE-2026-26268 — agent autonomicznie wykonujący Git hooks z niezaufanego repozytorium bo architektura nie separowała operacji agenta od niezaufanych danych wejściowych.
Ryzyko behawioralne. Niedomiar specyfikacji, niezgodność celów, zachowanie deceptywne, emergentne możliwości prowadzące do nieoczekiwanych wyników. PocketOS to podręcznikowy przypadek niezgodności celów: agent otrzymał zadanie "napraw problem z danymi uwierzytelniającymi" i wykonał je w sposób technicznie zgodny z celem — znalazł token API w bazie kodu i użył go do usunięcia problematycznego zasobu. Z raportu Anthropic o Mythos Preview: agent który bez polecenia opublikował szczegóły exploita na publicznych stronach bo "dokumentowanie sukcesu" mieściło się w jego interpretacji zadania. W obu przypadkach: agent działał dokładnie jak zaprojektowany, produkując skutki których nikt nie przewidział.
Ryzyko strukturalne. Wzajemne powiązania między komponentami systemów agentowych zwiększają powierzchnię ataku i prawdopodobieństwo kaskadowych awarii. Comment and Control — agent w GitHub Actions przetwarza tytuły zgłoszeń jako kontekst zadania, ma dostęp do sekretów środowiskowych, wyniki jednej operacji trafiają do następnej. Jedna złośliwa instrukcja w tytule zgłoszenia kaskadowo przepływa przez cały łańcuch narzędzi.
Ryzyko odpowiedzialności. Nieprzejrzystość systemów agentowych utrudnia audyt i atrybucję. Kiedy coś pójdzie nie tak — kto odpowiada i jak to udowodnić? Ten wymiar jest najtrudniejszy do zmierzenia ale najważniejszy gdy dojdzie do incydentu. Shai-Hulud przez Dependabot — automatyczna aktualizacja zależności wykonała złośliwy kod bez żadnej decyzji człowieka. Kto ponosi odpowiedzialność: deweloper który skonfigurował Dependabot? Maintainer pakietu? Platforma?
Co wytyczne mówią co robić
Dokument organizuje rekomendacje w pięć obszarów: projektowanie bezpiecznych agentów, rozwijanie bezpiecznych agentów, zarządzanie komponentami zewnętrznymi, bezpieczne wdrożenie, bezpieczna eksploatacja.
Kilka elementów zasługuje na szczególną uwagę.
Każdy agent powinien mieć zweryfikowaną tożsamość. Kryptograficznie zabezpieczoną, z krótkotrwałymi poświadczeniami i szyfrowaną komunikacją z innymi agentami i usługami. To jest bezpośrednia odpowiedź na pytanie które cyberflux stawiał przy okazji raportów OX Security o MCP — jak odróżnić legalny serwer MCP od złośliwego? Przy braku weryfikacji tożsamości — nie da się.
Decyzja o tym które operacje wymagają ludzkiej akceptacji należy do projektantów systemu, nie do agenta.CyberScoop cytuje dokument wprost: "deciding which actions require that approval is a job for system designers, not the agent." To bezpośrednio adresuje wzorzec z PocketOS — agent który dostał zasady bezpieczeństwa w konfiguracji i je naruszył. Wytyczne mówią: zasady w konfiguracji to za mało, mechanizm wymuszenia musi być architektoniczny.
"Assume breach" dla agentów. Dokument rekomenduje projektowanie wdrożeń z założeniem że agent może zachować się nieoczekiwanie — priorytetyzacja odwracalności i zawierania ryzyka nad efektywnością. To jest zmiana filozofii: z "zaprojektuj bezpiecznego agenta" na "zaprojektuj system który przetrwa gdy agent zachowa się niebezpiecznie."
Jedno zdanie które jest najważniejsze
Wróćmy do cytatu z początku: "organisations should assume that agentic AI systems may behave unexpectedly."
To jest wytyczna rządowa która przyznaje że problem nie jest w pełni rozwiązany. NSA i CISA nie opisują sprawdzonej metody zabezpieczenia agentów AI — opisują ramy myślenia o problemie który wciąż się rozwija.
CyberScoop odnotowuje to wprost: agencje przyznają że pole bezpieczeństwa nie nadąża za agentami AI. Część ryzyk unikalnych dla tych systemów nie jest jeszcze objęta istniejącymi ramami, a dokument wzywa do dalszych badań i współpracy gdy technologia przejmuje coraz więcej ról operacyjnych.
To jest uczciwa pozycja. I jest ważna dlatego że większość organizacji wdrażających agenty AI dziś zakłada że problem bezpieczeństwa jest rozwiązany — bo skoro narzędzie jest na rynku, producent musiał zadbać o bezpieczeństwo. Wytyczne NSA i CISA mówią wyraźnie że to założenie jest błędne.
Połączenie z tym co wiemy
Kiedy Lyrie Research opisuje znaczenie dokumentu, wskazuje jedno praktyczne zastosowanie którego inne omówienia nie wyciągają: "This guidance — backed by CISA and NSA — gives security teams the regulatory cover to require agent governance before deployment."
To jest argument dla działów IT w organizacjach gdzie poszczególne zespoły wdrażają agenty AI bez przechodzenia przez procesy bezpieczeństwa: GitHub Copilot z szerokimi uprawnieniami, Salesforce Agentforce, narzędzia do kodowania z dostępem do repozytoriów i sekretów. Dokument NSA i CISA to narzędzie które pozwala wymagać przeglądów bezpieczeństwa dla tych wdrożeń.
Polskie organizacje które wdrożyły lub planują wdrożyć agenty AI w środowiskach produkcyjnych mają teraz dokument od sześciu rządowych agencji który precyzyjnie opisuje co powinno być zweryfikowane przed wdrożeniem. Nie jest to nowy zestaw wymagań — to nowe formalne potwierdzenie że wymagania które profesjonalne działy bezpieczeństwa już stosowały są właściwe.
Źródła
CISA — pełny dokument "Careful Adoption of Agentic AI Services": https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services
NSA — komunikat prasowy: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4475134/
CyberScoop — omówienie z cytatami z dokumentu: https://cyberscoop.com/cisa-nsa-five-eyes-guidance-secure-deployment-ai-agents/
Cloud Security Alliance — analiza powiązania z innymi ramami: https://labs.cloudsecurityalliance.org/research/csa-research-note-cisa-agentic-ai-guidance-20260503-csa-styl/
Lyrie Research — analiza implikacji dla CISO: https://lyrie.ai/research/research/2026-05-03-five-eyes-agentic-guidance
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł