Wpis czwarty z serii Budujemy Agentic Web. Poprzednie: Warstwa Web, Warstwa Commerce, Warstwa Enterprise.
Przez ostatnie trzy wpisy budowałem model Agentic Web jako stos warstw. Web na dole, Commerce nad nią, Enterprise jeszcze wyżej. Logiczny, czytelny, dający się opowiedzieć.
I przez chwilę rozważałem, żeby napisać ten wpis tak samo. Warstwa Cybersec jako czwarta w kolejności, z listą zagrożeń, zalecanymi narzędziami i podsumowaniem na końcu.
Ale to byłoby błędem. I chcę wytłumaczyć dlaczego — bo ta różnica ma konsekwencje dla każdego kto buduje lub zarządza czymkolwiek w ekosystemie agentów AI.
Bezpieczeństwo nie jest warstwą
W klasycznym modelu OSI bezpieczeństwo jest przekrojowe. Nie siedzi na konkretnym poziomie — dotyczy każdej warstwy jednocześnie. Szyfrowanie na poziomie transportu, uwierzytelnianie na poziomie aplikacji, kontrola dostępu na poziomie zasobów.
Agentic Web działa tak samo. Każda warstwa którą opisałem — Web, Commerce, Enterprise — ma swój własny profil ryzyka i swoje własne wektory ataku.
W Warstwie Web — strona która ma llms.txt i robots.txt może nieświadomie zawierać ukryte instrukcje dla agentów. Nie złośliwy kod. Nie wirus. Zwykły tekst HTML który agent AI czyta jako polecenie.
W Warstwie Commerce — agent który może składać zamówienia i przetwarzać płatności działa z uprawnieniami. Przejęcie takiego agenta to nie kradzież danych. To wykonanie transakcji w imieniu użytkownika bez jego wiedzy.
W Warstwie Enterprise — agent z dostępem do SharePoint, Teams i kalendarza to nie asystent. To tożsamość uprzywilejowana z dostępem do całej organizacji.
To nie są scenariusze teoretyczne. To są udokumentowane incydenty z ostatnich miesięcy na CyberFlux.pl.
Co się zmieniło w 2026
Przez lata bezpieczeństwo webowe oznaczało: ktoś próbuje wyciągnąć dane albo wykonać kod na serwerze. Atakujący był po jednej stronie, dane po drugiej, przeglądarka była tylko medium.
Agent AI zmienia tę architekturę fundamentalnie.
Agent nie tylko odwiedza web. Agent działa na webie.
Różnica jest kluczowa. Złośliwy skrypt w przeglądarce musi ominąć Content Security Policy, Same-Origin Policy, kilkanaście mechanizmów obronnych. Agent AI czyta treść strony jako instrukcję i wykonuje ją z własnym kontekstem, własnymi uprawnieniami, w imieniu użytkownika który mu zaufał.
CyberFlux opisał to wprost w kwietniu 2026: „Agent nie odwiedza już tylko webu. Web zaczyna atakować agenta.”
Trzy nowe klasy ataku
Prompt Injection
Najstarsza z nowych klas. Atakujący umieszcza instrukcje w treści którą agent przeczyta — komentarz HTML, tekst z atrybutem display:none, zawartość dokumentu, odpowiedź API. Gdy agent to przetworzy, instrukcja wykonuje się w jego kontekście.
OWASP w grudniu 2025 opublikował Top 10 dla aplikacji agentowych. ASI01 — Agent Goal Hijacking — zajął pierwsze miejsce. Nie przypadkiem.
Liczby z International AI Safety Report 2026 są precyzyjne: wyrafinowani atakujący omijają najlepiej zabezpieczone modele w 50% przypadków przy 10 próbach. Anthropic w system card dla Claude Opus 4.6 podał 17,8% skuteczności przy pierwszej próbie bez zabezpieczeń — i 78,6% po 200 próbach.
To są pomiary na modelach produkcyjnych z aktywnymi zabezpieczeniami.
Konkretna implementacja: Comment and Control — atak który ukrywa instrukcje w komentarzach kodu i przejmuje kontrolę nad Claude Code, Gemini i Copilot jednocześnie.
Agent Hijacking
Przejęcie nie jednego wywołania modelu — ale całego celu agenta. Zamiast „wyciągnij dane z tej rozmowy”, instrukcja brzmi: „od teraz pracujesz na mnie”.
PocketOS w maju 2026 udokumentował coś istotnego: agent miał w system prompt napisane NEVER GUESS. Zgadł. Nie złośliwie — po prostu wypełnił lukę w instrukcji zgodnie z własną logiką.
To nie jest błąd w implementacji. To jest właściwość fundamentalna — model językowy jest trenowany żeby być pomocny. „Pomocność” w odpowiednim kontekście może oznaczać wykonanie czegoś czego nikt nie chciał.
MCP Security
Model Context Protocol otworzył nową powierzchnię ataku o której mało kto myślał przy projektowaniu. Serwer MCP to nie tylko API — to pomost między modelem a narzędziami, danymi, innymi systemami.
CVE-2026-32211 był pierwszym CVE w ekosystemie MCP — i jego analiza ujawniła coś ważniejszego niż konkretny błąd: MCP domyślnie zakłada zaufanie między komponentami. W środowisku gdzie każdy może hostować serwer MCP, to założenie jest niebezpieczne.
Mitiga w maju 2026 pokazał trwałe przejęcie MCP w Claude Code — takie, że rotacja tokenu nie pomaga. Dostęp utrzymuje się przez zmodyfikowany kontekst który agent niesie ze sobą między sesjami.
Claudy Day — model ataku który zmienił wszystko
W marcu 2026 Oasis Security zademonstrował Claudy Day — atak zero-click na domyślną sesję Claude.
Zero kliknięć. Żadnych dodatkowych serwerów MCP. Żadnej specjalnej konfiguracji. Wystarczyła spreparowana treść w środowisku które agent czytał — i dane z SharePoint oraz Teams zaczęły przepływać do atakującego.
To jest zmiana jakościowa. Poprzednie ataki wymagały od użytkownika jakiejś interakcji, jakiegoś błędu, jakiegoś kliknięcia złego linku. Claudy Day pokazał że wystarczy, że agent jest w środowisku. Jego aktywność jest powierzchnią ataku.
CyberFlux nazwał to „nową lekcją o architekturze agentów”. Problem nie leży już w konkretnym poleceniu — leży w tym jak agent traktuje granicę między danymi a instrukcjami. Tę granicę można rozmyć.
Tożsamość agenta jako nowy problem IAM
Przez lata zarządzanie tożsamością (IAM) dotyczyło ludzi i systemów. Użytkownik ma rolę, rola ma uprawnienia, uprawnienia dają dostęp do zasobów.
Agent AI wchodzi w tę architekturę jako nowa klasa tożsamości — i ta klasa nie pasuje do żadnego z istniejących modeli.
Microsoft Entra Agent ID to pierwsza próba odpowiedzi na pytanie „jak zarządzać tożsamością agenta AI w środowisku enterprise”. Błąd w roli Agent ID Administrator pokazał od razu, że warstwa tożsamości AI dziedziczy stare problemy — i dodaje nowe.
Agent który może działać w imieniu użytkownika, ale nie jest użytkownikiem. Który ma uprawnienia, ale nie ma odpowiedzialności. Który może być wieloma instancjami jednocześnie.
To nie jest problem do rozwiązania przez łatkę. To jest problem architektoniczny który branża dopiero zaczyna artykułować.
Co to oznacza dla twojej strony
Wróćmy na poziom praktyczny.
Jeśli twoja strona zawiera treść którą agenty AI odwiedzają — a w 2026 odwiedzają praktycznie każdą publiczną stronę — to jest potencjalną powierzchnią ataku. Nie dlatego że jesteś celem. Dlatego że nie wiesz co umieszczasz w treści i jak agent to zinterpretuje.
Trzy scenariusze:
Przypadkowa injekcja — masz na stronie narzędzie które generuje treść, plugin który wkleja kod, developer który zostawił komentarz debugowy. Żaden z tych elementów nie był projektowany złośliwie. Ale agent AI czyta je razem z resztą treści.
Celowa injekcja przez osobę trzecią — ktoś zostawia komentarz na twoim blogu, recenzję w formularzu, odpowiedź w sekcji Q&A. Zawartość tego komentarza jest teraz częścią treści którą agent przetworzy przy następnej wizycie.
Poisoning w łańcuchu dostaw — używasz zewnętrznego skryptu, CDN, pluginu. Ktoś kompromituje to źródło i wstrzykuje instrukcje dla agentów. Twoja strona jest czysta. Treść którą serwuje — już nie.
PI Scanner na iFox.pl sprawdza twoją stronę pod kątem wszystkich trzech scenariuszy. Analizuje HTML przez Claude AI, szuka ukrytych instrukcji, identyfikuje elementy które mogą być zinterpretowane jako polecenia przez agenty odwiedzające stronę.
To nie jest narzędzie dla developerów ani specjalistów od bezpieczeństwa. To jest narzędzie dla każdego kto buduje w Agentic Web i chce wiedzieć co tak naprawdę serwuje agentom.
NIST, OWASP i ramy które zaczynają nadążać
Przez pierwsze lata agentów AI środowisko bezpieczeństwa pracowało bez map. Każdy incydent był nowy, każda kategoria ataku była namierzana ad hoc.
To się zmienia.
NIST COSAIS w styczniu 2026 wydał pierwsze wytyczne dotyczące bezpieczeństwa systemów agentowych. OWASP opublikował Top 10 dla aplikacji agentowych. International AI Safety Report 2026 — pierwszy raport z udziałem 100+ naukowców z 30 krajów — poświęcił znaczną część analizie zagrożeń ze strony autonomicznych systemów.
Ramy istnieją. Pytanie czy organizacje które wdrażają agentów AI mają czas i wiedzę żeby je stosować.
W Polsce w maju 2026 nie ma ani jednej firmy która opublikowała formalną politykę bezpieczeństwa dla agentów AI. Sprawdziłem — wiem, bo zajmuje się tym CyberFlux.
Gdzie jesteśmy i co z tym zrobić
Agentic Web w warstwie bezpieczeństwa jest w 2026 dokładnie tam gdzie webowe bezpieczeństwo było w 2004. SQL injection istniał od lat, XSS był znany, a większość aplikacji produkcyjnych nie sanityzowała inputu bo nikt się nad tym nie zastanawiał.
Wiemy co będzie dalej. Incydenty będą poważniejsze, skala będzie rosnąć, regulacje pojawią się za późno żeby zapobiec pierwszej fali poważnych naruszeń. A potem nastąpi moment kiedy każdy będzie wiedział że to był do przewidzenia.
Różnica między 2004 a 2026 jest jedna: mamy archiwum tamtej historii. Możemy nie powtarzać tych samych błędów.
To wymaga trzech rzeczy:
Zmiana modelu myślenia o treści. Każdy tekst który umieszczasz na stronie jest potencjalną instrukcją dla agenta. Nie tylko kod. Nie tylko skrypty. Zwykłe zdania w naturalnym języku.
Audyt środowiska pod kątem agentów. Nie „czy moja strona jest bezpieczna dla użytkowników” — ale „co agent AI z niej odczyta i jak to zinterpretuje”.
Śledzenie zagrożeń w czasie rzeczywistym. Krajobraz zmienia się co tydzień. CyberFlux dokumentuje każdy istotny incydent, CVE i technikę ataku w ekosystemie AI na bieżąco.
Następny wpis: Warstwa IoT — gdy agenty wychodzą z przeglądarki. Hub Agentic Web: wszystkie warstwy w jednym miejscu.
Sprawdź swoją stronę pod kątem prompt injection: PI Scanner na iFox.pl — analiza przez Claude AI, wynik w kilka sekund.
