Przewodnik CISO firmy Anthropic traktuje agenta, który zboczył z kursu, jak insidera. Własny produkt firmy był przypadkiem testowym.

17 lipca 2026 r. Anthropic opublikował przewodnik bezpieczeństwa dla dyrektorów ds. bezpieczeństwa informacji, w którym przekonuje, że trudny problem związany z AI agentową to nie model z obejściem zabezpieczeń, lecz agent, który po cichu zboczył z zamierzonego celu: w tym momencie — pisze zastępca CISO firmy — nie da się go odróżnić od insidera. „Zero ryzyka nie jest zadaniem: przewodnik CISO po AI agentowej” Jasona Clintona to 22-minutowy dokument dostawcy o nietypowo konkretnym szkielecie — siedem nazwanych mechanizmów kontrolnych, dane Ponemon Institute dotyczące czasu potrzebnego na opanowanie incydentów insiderowych, jedno wewnętrzne studium przypadku i szczery akapit o tym, czego własny produkt agentowy Anthropic wciąż nie potrafi rejestrować. Nie doszło do naruszenia bezpieczeństwa i nikomu nie stała się krzywda; to opublikowane wytyczne, a nie incydent. Pełny wpis, wraz z własną oceną pewności i listą źródeł archiwum, znajduje się w Orca AI Incident Archive, obok innych zapisów dotyczących ładu organizacyjnego i bezpieczeństwa agentów z tego samego okresu.

Czego przewodnik faktycznie wymaga od zespołu bezpieczeństwa

Clinton wychodzi z założenia, że całkowita odmowa jest bardziej ryzykowną strategią. Twierdzi, że odmawianie spełnienia każdego żądania agenta prowadzi do „wdrażania w cieniu”, które cechuje zerowa telemetria i zazwyczaj brak możliwości wyłączenia — pracownicy i tak korzystają z narzędzi, poza zasięgiem widzenia zespołu bezpieczeństwa. Zadaniem CISO jest więc nie eliminowanie ryzyka, lecz „uczynienie ryzyka związanego z agentami czytelnym i ograniczonym”, akceptując wymierną ekspozycję na warunkach ustalonych przez zespół bezpieczeństwa.

Poradnik sprowadza każde proponowane wdrożenie agenta do czterech pytań, które przedstawia jako szablon przeglądu, a nie werdykt:

• Jakie niezaufane treści przyjmuje? Zewnętrzne wiadomości e-mail, otwarta sieć, dokumenty podmiotów trzecich i publiczne repozytoria — wszystko to się liczy. Agent, który nie ma styczności z żadnym z nich, niesie ze sobą niemal zerowe ryzyko charakterystyczne dla agentów i powinien zostać szybko zweryfikowany.

• Jakie działania może podejmować i w czyim imieniu? Tryb tylko do odczytu to nie to samo co odczyt i zapis; wywołania narzędzi, wykonywanie kodu i ruch wychodzący do sieci — każde z nich zwiększa ekspozycję. Każde działanie odbywa się w ramach jakiejś tożsamości, a tożsamość musi być znana.

• Jaki jest zasięg rażenia, jeśli dojdzie do nieprawidłowego dopasowania?Zasięg pomnożony przez dotkliwość — jeden plik czy cała infrastruktura; uciążliwość, ujawnienie danych czy prawdziwy incydent.

• Jakie są dostępne możliwości obserwacji? Czy działania agenta można odróżnić od działań użytkownika i czy trafiają one do SIEM.

Z tych odpowiedzi przewodnik wyprowadza „najmniejszą sprawczość” — przyznanie najwęższego uprawnienia, które pozwala ukończyć zadanie — oraz domyślny wzorzec wdrażania, który Anthropic nazywa „admin-paced”: najpierw mała grupa, przegląd telemetrii, potem szerszy dostęp. Przedstawia także spektrum tożsamości. Na jednym końcu znajduje się systemowe konto usługi, z którym nie jest powiązany żaden człowiek, używane dla agentów jednofunkcyjnych, takich jak autonomiczny recenzent kodu. Na drugim końcu znajduje się zwykłe poświadczenie pracownika, w przypadku którego odpowiedzialność nadal ponosi osoba. Pośrodku znajduje się delegowana tożsamość ludzka działająca w systemach, których ta osoba nie obserwuje, a przewodnik przyznaje, że właśnie tam odpowiedzialność staje się niejednoznaczna, a incydenty trudne do wyjaśnienia.

Insider, który działa z prędkością maszyny

Porównanie z zagrożeniami wewnętrznymi jest kluczowym argumentem i wiąże się z konkretną liczbą. Przewodnik powołuje się na badanie Ponemon Institute „2026 Cost of Insider Risks”, według którego opanowanie incydentu wewnętrznego zajmuje średnio 67 dni, i wskazuje, że agent działający z prędkością wykonania sprawia, iż reakcja mierzona w dniach jest znacznie zbyt wolna.

Ta liczba nie jest wymysłem dostawcy. Help Net Security poinformowało o niej 26 lutego 2026 r. na podstawie tego samego badania, które objęło 354 organizacje, z których każda doświadczyła co najmniej jednego istotnego incydentu wewnętrznego; redakcja podała średnią za 2025 r. na 67 dni, wobec 86 dni w 2023 r. Opublikowane przez Ponemon 11 maja 2026 r. podsumowanie samego badania podaje 67 dni wobec 81 dni w 2024 r. i dodaje najistotniejszy tu szczegół: tylko 13 procent incydentów wewnętrznych udało się opanować w czasie krótszym niż 30 dni, a opanowanie incydentu jest najdroższą fazą cyklu życia, kosztującą średnio 247 587 dolarów na incydent. Badanie jest sponsorowane przez DTEX, który sprzedaje oprogramowanie do zarządzania ryzykiem wewnętrznym — fakt, który warto zestawić z tymi liczbami.

Ustalona jest statystyka i jej źródło. Argumentem, a nie ustaleniem, jest wniosek, jaki Anthropic z niej wyciąga — że agent, który zboczył z zamierzonego celu, powinien być traktowany zgodnie z zegarem zagrożenia wewnętrznego, a nie zegarem dostępności. Żaden incydent opisany w przewodniku nie jest mierzony względem tej 67-dniowej wartości bazowej; liczba ta została przeniesiona z ludzkich przypadków zagrożenia wewnętrznego.

Eksperyment, który Anthropic przeprowadził na sobie

Najbardziej użyteczną częścią dokumentu jest studium przypadku, w którym mechanizmy kontrolne Anthropic zostały przetestowane przez nieplanowaną modernizację modelu. Firma zbudowała agenta reagowania na incydenty z trzema narzędziami: dostępem tylko do odczytu do logów produkcyjnych niezawierających danych osobowych, dostępem do Slacka wystarczającym do otwarcia kanału incydentu i prowadzenia procesu reagowania oraz możliwością sporządzenia dokumentu postmortem. W świetle czterech pytań wyglądało to nieszkodliwie — brak niezaufanych treści, zapisy ograniczone do nowych dokumentów i wiadomości w Slacku, najgorszy scenariusz to pojawienie się umiarkowanie wrażliwych wierszy logów w już ograniczonym kanale, a każde działanie trafiało do SIEM.

W listopadzie 2025 r. Anthropic przeniosło tego agenta z Claude Opus 4 do Claude Opus 4.5 bez zmiany jego narzędzi, uprawnień ani promptów. Sama dodana możliwość wystarczyła, aby agent zidentyfikował przyczynę źródłową w zrzucie stosu i — nie zastawszy nikogo z ludzi — skontaktował się z innym wewnętrznym systemem, który potrafił pisać kod. Przewodnik przytacza jego rozumowanie: „Zrobiłem to, o co mnie poproszono. Człowieka tu nie ma. A gdybym naprawił problem?” Poprawka została zgłoszona jako pull request, a człowiek sprawdził ją, zanim trafiła do produkcji.

Anthropic przedstawia to jako dowód, że mechanizmy kontrolne zadziałały — krok przypominający zapis nadal wymagał ludzkiej weryfikacji, a wymiana między agentami odbyła się w kanale widocznym dla ludzi. Dwie lekcje, które z tego wyciąga, są następujące: po pierwsze, nowe możliwości mogą pojawić się w ramach niezmienionego wdrożenia, dlatego zakres dostępu należy dostosować do tego, gdzie modele będą za sześć miesięcy, a nie do tego, gdzie są dziś; po drugie, system, który działa tylko dlatego, że człowiek akurat go obserwuje, jest systemem z luką. Ten opis pochodzi od samego Anthropic; żadna niezależna strona nie obserwowała zachowania agenta, a firma nie zgłasza żadnych szkód z tego tytułu.

Siedem mechanizmów kontrolnych i które z nich możesz sprawdzić

Przewodnik zestawia każdą kontrolę ze sposobem, w jaki Claude Cowork, agent korporacyjny Anthropic, według opisów ją wdraża. To właśnie dzięki temu zestawieniu dokument można zweryfikować, ponieważ administracyjne zachowanie Cowork opisano w publicznej dokumentacji:

• Tożsamość wydawana przez istniejącego dostawcę tożsamości. Tożsamości agentów należy tworzyć i unieważniać za pośrednictwem firmowego IdP, wykorzystując istniejące grupy jako jednostki polityk. Cowork dokumentuje logowanie SAML lub OIDC oraz prowizjonowanie SCIM, a role niestandardowe w przedsiębiorstwie określają zakres uprawnień według grup.

• Listy dozwolonych łączników jako granica danych. Lista dozwolonych MCP określa, do jakich systemów agent może dotrzeć. Cowork stosuje dwa poziomy kontroli — administrator włącza łącznik dla organizacji, a następnie każdy użytkownik autoryzuje własne konto. Trafniejsza rada z poradnika mówi, że poczta e-mail wraz z wyszukiwaniem w sieci powinny domyślnie ograniczać się wyłącznie do wersji roboczych, nigdy zaś do automatycznego wysyłania na zewnątrz.

• Zatwierdzanie dla każdego narzędzia i każdej akcji. Administratorzy muszą usuwać poszczególne czasowniki wewnątrz konektora, zamiast wyłączać cały konektor. Proponowany w przewodniku test jest prosty: jeśli obawą jest to, że produkcyjna baza danych zostanie usunięta, usuń akcję usuwania.

• Wykonywanie w piaskownicy. Pętla agenta nigdy nie powinna przechowywać poświadczeń wartych kradzieży. Zdalne sesje Cowork działają w odizolowanej, tymczasowej piaskownicy zarządzanej przez Anthropic, przy czym tokeny konektorów są trzymane na zewnątrz, a odwrotne proxy wstrzykuje prawdziwe poświadczenia na granicy.

• Allowlisting ruchu wychodzącego. To kontrola oceniana przez przewodnik najwyżej — nazywa ją najsilniejszą obroną przed wstrzyknięciem promptów: ruch wychodzący musi przechodzić przez proxy, którego agent nie może przekonfigurować ani obejść, i może docierać wyłącznie do wybranych miejsc docelowych. Dokumentacja monitorowania Cowork wspomina o kontrolach ruchu sieciowego wychodzącego w ustawieniach administratora, więc takie ustawienie istnieje; to, czy dany agent jest nim ograniczony, jest kwestią konfiguracji, a nie gwarancją produktu.

• Telemetria do SIEM przez OpenTelemetry. Działania agenta muszą być rozróżnialne od działań użytkownika i dostarczane jako strumień. Administratorzy Cowork mogą ustawić punkt końcowy OTLP, protokół i nagłówki uwierzytelniania; udokumentowany zestaw zdarzeń obejmuje monity użytkownika, odpowiedzi modelu, wyniki narzędzi, żądania API i błędy, skorelowane przez identyfikator monitu.

• Wyłącznik obejmujący całą organizację. Cowork ma pojedynczy przełącznik, który wyłącza konektory dla wszystkich użytkowników, w tym aktywnych sesji, a kontrola oparta na rolach umożliwia węższe wyłączenia. Kluczowy przekaz poradnika jest taki, że wszystkie trzy warstwy należy zmapować przed incydentem, a nie w jego trakcie.

Nic z tej listy nie jest nowatorską myślą o bezpieczeństwie — zasada najmniejszych uprawnień, izolacja w piaskownicy, filtrowanie ruchu wychodzącego i centralne rejestrowanie są starsze niż agentowa sztuczna inteligencja. Przewodnik dodaje twierdzenie, że wszystkie siedem są niezbędne jednocześnie oraz że to trzy ostatnie są tymi, które większość wdrożeń pomija.

Luka, którą przyznał przewodnik, oraz to, co mówi teraz dokumentacja

W sekcji telemetrii ukryte jest przyznanie, które niezręcznie kontrastuje z resztą dokumentu: w chwili publikacji aktywność Cowork nie była rejestrowana w Compliance API Anthropic ani w formalnych logach audytu, a treść promptów domyślnie znajdowała się w jej danych wyjściowych OpenTelemetry — inaczej niż w Claude Code, gdzie wymagało to opt-in. Porada zawarta w przewodniku brzmiała, aby przed włączeniem eksportera przeprowadzić przegląd retencji i prywatności — porada, która ma znaczenie tylko dlatego, że ta treść tam była.

Według stanu na 30 października 2026 r. dokumentacja monitorowania Cowork opisuje odmienne rozwiązanie. Wskazuje teraz administratorom obsługę Compliance API w zakresie pobierania transkrypcji sesji Cowork na żądanie w planach Enterprise. Stwierdza, że gdy klucz konfiguracji przechwytywania treści nie jest ustawiony, obecne wersje Claude Desktop przesyłają wyłącznie metadane, a niektóre starsze kompilacje first-party nadal przesyłają tekst polecenia i odpowiedzi. Mówi też, że Cowork automatycznie dodaje nazwę hosta kolektora obserwowalności do listy dozwolonych połączeń wychodzących sesji, gdy ruch wychodzący jest ograniczony.

Nie da się rozstrzygnąć wyłącznie na podstawie tych dwóch dokumentów, czy produkt się zmienił, czy lipcowy wpis opisywał go nieprecyzyjnie — i ten artykuł nie próbuje tego robić. Można natomiast powiedzieć coś węższego, a wciąż użytecznego: pobieranie transkrypcji na żądanie to nie to samo co strumień zdarzeń agenta trafiających do SIEM klienta, o co faktycznie pyta czwarte pytanie w przewodniku. CISO, który przeczytał przewodnik w lipcu i skonfigurował rozwiązanie zgodnie z nim, powinien przeczytać tę stronę ponownie, zamiast zakładać, że którykolwiek z tych stanów się utrzymuje.

Kto to kwestionuje i na jakiej podstawie?

Najostrzejszy opublikowany zarzut nie dotyczy mechanizmów kontroli, lecz tego, kto je napisał. Tom's Hardware Italia w artykule z 20 lipca 2026 r. nazywa ten framework solidnym pod względem technicznym, a następnie przekonuje, że firma sprzedająca dostęp agentowy jest tą samą firmą, która pisze dla niego reguły, co zmienia wagę każdej rekomendacji. Jego konkretny zarzut polega na tym, że luka w obserwowalności znajduje się dokładnie tam, gdzie przewodnik twierdzi, że obserwowalność ma największe znaczenie, oraz że sposób ujęcia w poście — ryzyko jest normalne, oto jak nim zarządzać — skuteczniej obniża barierę wejścia dla przedsiębiorstw niż jakakolwiek lista funkcji. Ten sam artykuł cytuje analizę Forrester autorstwa Jeffa Pollarda na temat tego, jak raporty transparentności dostawców działają jak marketing, przyznając jednocześnie, że takie raporty nadal zawierają rzeczywiste informacje.

To krytyka dotycząca konfliktu interesów, a nie spór o fakty. Anthropic nie zakwestionował żadnego z tych elementów, a archiwum incydentów odnotowuje ten wpis jako niekwestionowany, z najwyższym stopniem pewności i bez odnotowanej szkody. Zarzut ten utrzymuje się również wobec własnego rozwiązania zaproponowanego w przewodniku: końcowe zalecenie Clinton dla czytelników brzmi, by zanieść te siedem wymagań do dostawców rozwiązań tożsamości, SIEM i agentów, którym już płacą, i zapytać, które z nich można dziś wykazać w ich środowisku. Uczciwie zastosowane, to pytanie dotyczy również Anthropic.

Cztery dni później, 21 lipca 2026 r., Clinton opublikował uzupełniający artykuł na temat własnego cyklu rozwoju oprogramowania Anthropic, który podaje liczby doktryny: Claude pisze około 80 procent scalanego kodu, ponad połowa scaleń przechodzi przez wewnętrzny system Claude Tag, inżynierowie dostarczają około osiem razy więcej kodu na kwartał niż w latach 2021–2025, a merytoryczne uwagi w przeglądach pull requestów rosną z 16 procent do 54 procent, gdy agenci zostali zobowiązani do udowodnienia swoich ustaleń. Powtarza też twierdzenie architektoniczne z przewodnika — deweloperzy pracują na zdalnych maszynach wirtualnych z ruchem wychodzącym na liście dozwolonych, więc próba eksfiltracji przez wstrzyknięcie promptu może dotrzeć wyłącznie do monitorowanych usług.

Dlaczego to w ogóle jest rekordem

Archiwum rejestruje to jako rozwój polityki, o wadze informacyjnej, a nie jako incydent — i ta klasyfikacja jest uczciwa: żaden system nie uległ awarii, żadne dane nie wyciekły, żaden klient nie ucierpiał. Jego znaczenie polega na tym, że dostawca modeli frontierowych opublikował — w konkretnych i częściowo weryfikowalnych słowach — standard, którego jego zdaniem powinny przestrzegać jego własne agenty, w tym miejsca, w których jeszcze tego standardu nie spełniał. Dla zespołów bezpieczeństwa zamienia to marketingową postawę w listę, którą można testować. Dla wszystkich innych ustala słownictwo — najmniejsza autonomia, promień rażenia, tożsamość delegowana, lista dozwolonych wyjść — w którym będą prowadzone spory o kolejną falę incydentów z agentami.