Agenci AI: nowe oblicze cyberzagrożeń

Wiele osób nadal myli agentów AI ze zwykłymi chatbotami, takimi jak ChatGPT czy Claude. Różnica jest zasadnicza: chatbot odpowiada na pytania użytkownika, natomiast agent AI może samodzielnie wykonywać działania, korzystać z narzędzi, łączyć się z systemami i podejmować kolejne kroki bez każdorazowej zgody człowieka.

To właśnie ta autonomia zmienia skalę ryzyka. Firmy coraz częściej dają agentom dostęp do wrażliwych zasobów: wewnętrznych baz danych, repozytoriów kodu, systemów finansowych, dokumentacji klientów czy firmowej komunikacji. Problem w tym, że wdrożenia często wyprzedzają procedury bezpieczeństwa. Według badania IBM Institute for Business Value i AWS tylko 24% badanych projektów GenAI uwzględniało bezpieczeństwo jako element wdrożenia, co nie jest tym samym co ocena jakości istniejących zabezpieczeń, ale i tak pokazuje, jak często ten temat zostaje z tyłu [1].

Incydent za 20 dolarów

Dobrym przykładem skali problemu jest przypadek opisany przez CodeWall w marcu 2026 roku [2]. Badacze twierdzili, że autonomiczny agent AI w ciągu około dwóch godzin znalazł i wykorzystał podatność w platformie Lilli, wewnętrznym systemie AI McKinsey. Koszt obliczeniowy operacji miał wynieść około 20 dolarów.

Według relacji CodeWall agent zmapował publiczne API, znalazł 22 niezabezpieczone punkty dostępowe, a następnie wykrył podatność typu SQL Injection ukrytą w nietypowym miejscu, w nazwach kluczy JSON. To istotny szczegół, ponieważ tego rodzaju luka mogła zostać pominięta przez standardowe skanery bezpieczeństwa.

Skala potencjalnego dostępu była, według relacji CodeWall, bardzo duża: badacze twierdzili, że uzyskali dostęp do informacji dotyczących około 728 tysięcy plików oraz innych zasobów Lilli, w tym historii wyszukiwania użytkowników. Publicznie dostępne informacje nie pozwalają jednoznacznie utożsamić tej liczby z pobraniem treści wszystkich tych dokumentów, część relacji mówi o nazwach lub rekordach dotyczących plików, a nie o samych dokumentach, które mogły być przechowywane osobno. McKinsey poinformował, że jego własne dochodzenie nie wykazało dostępu do poufnych danych klientów [3]. Najpoważniejszy problem dotyczył jednak promptów systemowych: według CodeWall atakujący mógł uzyskać możliwość modyfikacji wewnętrznych instrukcji, które wpływały na sposób działania systemu AI.

To pokazuje nowe ryzyko: w systemach agentowych nie chodzi wyłącznie o kradzież danych. Równie groźna może być cicha modyfikacja instrukcji, logiki odpowiedzi albo źródeł, na których opiera się model. W praktyce mogłoby to prowadzić do manipulowania analizami, rekomendacjami lub dokumentami tworzonymi przez pracowników.

Złośliwe rozszerzenia i problem OpenClaw

Ryzyko nie dotyczy wyłącznie dużych korporacji. Podobny problem widać w ekosystemie narzędzi open source, takich jak OpenClaw, agent AI integrujący się między innymi z komunikatorami, terminalem i lokalnym systemem użytkownika.

OpenClaw zyskał popularność dzięki rozszerzeniom, tzw. “skills”, które pozwalały szybko dodawać nowe funkcje. Ten model okazał się jednak podatny na nadużycia. Badacze bezpieczeństwa wykryli setki złośliwych rozszerzeń podszywających się pod legalne pakiety [4]. Część z nich instalowała infostealery, trojany lub narzędzia umożliwiające przejęcie danych z przeglądarek, portfeli kryptowalutowych i systemu operacyjnego.

To osobny problem od tego, że wiele instancji OpenClaw było wystawionych do internetu z niewystarczającym uwierzytelnianiem lub podatnymi konfiguracjami. Złośliwe rozszerzenie i źle zabezpieczona, ale niezmieniona instancja to dwa różne wektory ryzyka, nie ten sam incydent, choć oba wynikają z tego samego ekosystemu: łatwości instalowania i wystawiania agentów bez pełnej kontroli nad tym, co się instaluje i komu jest to dostępne. W przypadku agenta AI błąd konfiguracyjny ma większe konsekwencje niż w zwykłej aplikacji, bo agent często ma dostęp do plików, komunikacji, kont użytkownika i lokalnych poleceń systemowych.

Shadow AI i indirect prompt injection

Wiele firm deklaruje, że nie korzysta z agentów AI, ale praktyka bywa inna. Pracownicy często używają prywatnych, niezatwierdzonych narzędzi AI do codziennych zadań: streszczania dokumentów, analizy kodu, pisania wiadomości czy pracy z danymi. To zjawisko określa się jako Shadow AI.

Ryzyko polega na tym, że firma traci kontrolę nad tym, gdzie trafiają dane. Do zewnętrznych narzędzi mogą być wklejane fragmenty kodu, dane klientów, wewnętrzne dokumenty albo informacje objęte tajemnicą przedsiębiorstwa. Według IBM organizacje z wysokim poziomem Shadow AI ponosiły średnio o 670 tysięcy dolarów wyższe koszty naruszeń danych niż organizacje z niskim poziomem tego zjawiska [5].

Osobnym problemem jest indirect prompt injection, czyli pośrednie wstrzykiwanie poleceń. Atakujący ukrywa złośliwą instrukcję w dokumencie, wiadomości e-mail, stronie internetowej lub pliku, który później czyta agent AI. Jeżeli agent ma dostęp do poczty, plików lub systemów firmowych, może potraktować taką instrukcję jak polecenie i wykonać działanie, którego użytkownik nigdy świadomie nie zatwierdził.

OWASP uznał Prompt Injection za najważniejsze ryzyko w zestawieniu Top 10 dla aplikacji opartych na dużych modelach językowych w 2025 roku [6]. To nie jest problem teoretyczny, tylko wynika bezpośrednio z tego, że modele językowe mają trudność z jednoznacznym oddzieleniem treści dokumentu od instrukcji sterującej.

Zespoły, które chcą podejść do tego systematycznie, a nie tylko punktowo, mają już do dyspozycji gotowe ramy odniesienia: OWASP rozwija osobne zestawienie zagrożeń specyficznych dla agentów (Agentic AI Threats), a MITRE ATLAS kataloguje konkretne techniki ataków na systemy oparte na uczeniu maszynowym w formacie zbliżonym do znanej z bezpieczeństwa sieciowego macierzy MITRE ATT&CK. Żadne z nich nie zastąpi konkretnych decyzji o architekturze, ale dają wspólny język do rozmowy o ryzyku z zespołem bezpieczeństwa.

Jak ograniczyć ryzyko: 5 praktycznych kroków

Zrób inwentaryzację narzędzi AI. Firma musi wiedzieć, z jakich narzędzi korzystają pracownicy, zarówno oficjalnie, jak i poza zatwierdzonym obiegiem.
Stosuj zasadę minimalnych uprawnień. Agent AI powinien mieć tylko taki dostęp, jaki jest niezbędny do wykonania konkretnego zadania. Jeżeli ma jedynie czytać dane, nie powinien mieć prawa ich modyfikować ani wysyłać na zewnątrz.
Wprowadź nadzór człowieka nad działaniami wysokiego ryzyka. Operacje takie jak wysyłanie danych poza organizację, wykonywanie przelewów, modyfikacja dokumentów źródłowych czy zmiana konfiguracji systemów powinny wymagać zatwierdzenia przez człowieka.
Traktuj agentów AI jak niezaufany kod. Agent powinien być testowany pod kątem uprawnień, źródeł danych, komunikacji sieciowej i odporności na prompt injection. Sam fakt, że narzędzie korzysta z AI, nie zwalnia go z normalnych wymagań bezpieczeństwa. Podobne ryzyko, tylko po stronie tworzenia oprogramowania, opisuję przy okazji vibecodingu: kod zaakceptowany bez zrozumienia bywa równie niebezpieczny jak agent bez nadzoru.
Zamiast samych zakazów wprowadź jasną politykę AI. Zakazy często prowadzą do rozwoju Shadow AI. Skuteczniejszym rozwiązaniem jest udostępnienie pracownikom bezpiecznych, zatwierdzonych narzędzi oraz prostych zasad: jakie dane wolno przetwarzać, gdzie wolno ich używać i jakie działania wymagają zgody.

Autonomia bez kontroli to nowa klasa ryzyka

Agenci AI przestali być eksperymentem. Coraz częściej stają się elementem codziennej pracy operacyjnej, a wraz z tym rozszerzają powierzchnię ataku firmowych systemów. Przypadki takie jak incydent z platformą Lilli czy problemy wokół OpenClaw pokazują, że największym zagrożeniem nie jest sama sztuczna inteligencja, lecz połączenie autonomii, szerokich uprawnień i braku kontroli.

Organizacje, które wdrażają agentów AI bez zasad bezpieczeństwa, tworzą nową klasę ryzyka. Te, które potraktują agentów jak pełnoprawne komponenty infrastruktury IT, z audytem, kontrolą dostępu, monitoringiem i jasną odpowiedzialnością, będą miały znacznie większą szansę korzystać z tej technologii bez niepotrzebnego narażania danych, systemów i reputacji. W praktycznych wdrożeniach ten temat łączy się z automatyzacją IT i AI, bo bezpieczeństwo agenta zależy od całego procesu, nie tylko od promptu.