Wprowadzenie do problemu / definicja
Agenci AI coraz częściej wspierają procesy biznesowe, automatyzując obsługę poczty, komunikatorów, systemów ERP i zadań operacyjnych. Choć zwiększają efektywność, jednocześnie wprowadzają nową kategorię ryzyka: łączą dostęp do wielu systemów, przetwarzają niezaufane dane wejściowe i mogą wykonywać działania wpływające na stan organizacji.
Opisany przypadek pokazuje, że nawet pojedynczy agent zbudowany przez pracownika biznesowego może ujawnić fundamentalne braki w obszarach zarządzania tożsamością, kontroli dostępu, bezpiecznego projektowania, wykrywania nadużyć oraz audytu. To sygnał ostrzegawczy dla firm wdrażających automatyzację opartą na dużych modelach językowych bez pełnego nadzoru bezpieczeństwa.
W skrócie
Scenariusz dotyczył agenta AI stworzonego do obsługi faktur. Narzędzie odczytywało skrzynkę e-mail, porównywało dane w systemie ERP i publikowało podsumowania w Slacku. Agent korzystał z kombinacji dostępu OAuth, konektorów aplikacyjnych oraz statycznego klucza API, a mimo szerokich uprawnień nie przeszedł formalnego przeglądu bezpieczeństwa.
- przetwarzał dane z niezaufanych źródeł,
- miał dostęp do informacji wrażliwych,
- mógł modyfikować dane w systemie ERP,
- działał poza formalnym rejestrem zasobów jako przykład shadow AI.
W efekcie ukryta instrukcja umieszczona w wiadomości e-mail doprowadziła do zmiany danych płatniczych dostawcy. Incydent ujawnił pięć kluczowych problemów: brak widoczności agentów, niebezpieczny model dostępu, brak bezpiecznego projektowania, podatność na prompt injection oraz słabą detekcję i ścieżkę audytową.
Kontekst / historia
Rozwój platform low-code i no-code sprawił, że tworzenie agentów AI stało się możliwe również poza działami IT i bezpieczeństwa. Z perspektywy biznesu to duże ułatwienie, ale z perspektywy cyberbezpieczeństwa oznacza powstawanie nowych integracji bez klasycznych procesów zatwierdzania, modelowania ryzyka i ograniczania uprawnień.
W analizowanym przypadku agent został wdrożony bez udziału zespołu bezpieczeństwa. Najpierw otrzymał dostęp do poczty, ERP i Slacka, później rozpoczął działanie operacyjne bez przeglądu architektury ryzyka. Po kilku tygodniach do skrzynki trafiła spreparowana wiadomość z ukrytą instrukcją zmiany rachunku bankowego dostawcy. Agent odczytał ją jako prawidłowe polecenie i wykonał operację w systemie ERP.
Dopiero analiza po incydencie wykazała, że organizacja nie była w stanie jednoznacznie określić, kto formalnie autoryzował działanie agenta, na czyich uprawnieniach opierała się operacja i kto odpowiadał za to narzędzie w chwili wykonania zmiany. To klasyczny przykład sytuacji, w której automatyzacja rozwija się szybciej niż mechanizmy nadzoru.
Analiza techniczna
Najważniejszym elementem technicznym były ścieżki dostępu wykorzystywane przez agenta. W środowiskach firmowych tego typu narzędzia zwykle opierają się na kilku modelach jednocześnie, takich jak przejęta lub współdzielona sesja użytkownika, delegowany OAuth, statyczne poświadczenia oraz dedykowane tożsamości agentowe. Im większa mieszanka mechanizmów, tym trudniejsza staje się analiza zdarzeń i odpowiedzialności.
W tym scenariuszu agent korzystał z delegowanego OAuth do poczty i Slacka oraz ze statycznego klucza API do ERP. To szczególnie ryzykowne połączenie, ponieważ zgody OAuth bywają aktywne długo po zakończeniu potrzeby biznesowej, a statyczne klucze API często nie mają sensownego terminu wygaśnięcia i dziedziczą szerokie uprawnienia właściciela.
Drugim problemem był brak podejścia secure by design. Agent jednocześnie analizował niezaufane dane z zewnętrznej poczty, miał dostęp do wrażliwych informacji w ERP i posiadał możliwość wykonywania operacji modyfikujących rekordy. Taka kombinacja sprawia, że każdy kanał wejściowy staje się potencjalnym źródłem instrukcji operacyjnych.
Kluczową rolę odegrał prompt injection ukryty w treści wiadomości lub załącznika. Atak nie wymagał wykorzystania klasycznej podatności technicznej. Wystarczyło dostarczyć treść, którą model zinterpretował jako instrukcję biznesową. Z punktu widzenia logów wszystko mogło wyglądać legalnie: poprawny token, autoryzowane narzędzie i operacja mieszcząca się w zakresie przyznanych uprawnień.
Problemem okazała się także detekcja. Jeśli organizacja monitoruje jedynie zgodność działania z zakresem uprawnień, taki incydent może pozostać niewidoczny. Znacznie skuteczniejsze jest podejście behawioralne, które wykrywa nowe sekwencje działań, pierwsze użycie funkcji zapisu, nietypowe przepływy danych lub odstępstwa od normalnego profilu pracy agenta.
Ostatni aspekt dotyczył audytu. Rejestry wskazywały użycie osobistego klucza API twórcy agenta, przez co technicznie wyglądało to tak, jakby operację wykonał człowiek. Bez kontekstu delegacji, mapowania relacji „agent działa w imieniu użytkownika” oraz historii zgód odtworzenie pełnego przebiegu zdarzenia było bardzo utrudnione.
Konsekwencje / ryzyko
Skutki podobnych wdrożeń nie ograniczają się wyłącznie do pojedynczego incydentu fraudowego. Ryzyko ma charakter finansowy, operacyjny, regulacyjny i reputacyjny. Jeśli agent może samodzielnie wykonywać działania na podstawie niezaufanej treści, granica między błędem automatyzacji a incydentem bezpieczeństwa szybko się zaciera.
- straty finansowe wynikające z przekierowania płatności,
- utrata integralności danych biznesowych,
- nieautoryzowane ujawnienie informacji z ERP, poczty i komunikatorów,
- naruszenia zgodności i wymagań audytowych,
- błędna atrybucja działań do użytkownika zamiast do agenta,
- utrzymywanie aktywnych zgód i poświadczeń po zmianie roli lub odejściu pracownika,
- utrudniona reakcja incydentowa z powodu słabej telemetrii.
Szczególnie groźne jest to, że agent nie musi zostać tradycyjnie zhakowany, aby wyrządzić szkodę. Wystarczy, że zgodnie ze swoją logiką wykona polecenie pochodzące z niezaufanego źródła. To przesuwa ciężar obrony z samej aplikacji na kontrolę tożsamości, granic autonomii, danych wejściowych i mechanizmów zatwierdzania.
Rekomendacje
Firmy wdrażające agentów AI powinny traktować je jak uprzywilejowane, częściowo autonomiczne podmioty operacyjne. Oznacza to konieczność zastosowania zasad zero trust, najmniejszych uprawnień oraz pełnej obserwowalności działań.
- Pełna inwentaryzacja agentów AI – każda integracja powinna mieć właściciela biznesowego i technicznego oraz być widoczna w rejestrze zasobów.
- Dedykowane tożsamości agentowe – agent nie powinien działać na osobistych tokenach użytkowników ani na długowiecznych kluczach API.
- Przegląd bezpieczeństwa przed uruchomieniem – szczególnie wtedy, gdy agent łączy dane zewnętrzne, dane wrażliwe i możliwość samodzielnego działania.
- Ograniczenie autonomii – należy rozdzielać uprawnienia odczytu i zapisu oraz wymagać zatwierdzenia człowieka dla operacji krytycznych.
- Ochrona przed prompt injection – każdy kanał wejściowy trzeba traktować jako potencjalne źródło poleceń i filtrować kontekst przed wykonaniem akcji.
- Detekcja behawioralna – monitoring powinien wykrywać nowe sekwencje działań, pierwsze użycia funkcji i nietypowe transfery danych.
- Silna ścieżka audytowa – każda akcja powinna być powiązana z identyfikatorem agenta, użytym poświadczeniem, delegacją i źródłem polecenia.
- Gotowość do reakcji incydentowej – organizacja musi móc szybko zatrzymać agenta i zabezpieczyć logi, pamięć roboczą oraz transkrypty działań.
Podsumowanie
Przypadek jednego agenta AI pokazuje, że głównym problemem nie jest wyłącznie sama technologia modeli językowych, ale sposób ich osadzania w procesach biznesowych i systemach tożsamości. Brak widoczności, mieszane modele dostępu, nadmierne uprawnienia, podatność na prompt injection oraz słaby audyt tworzą warunki do incydentów wyglądających jak legalna aktywność.
Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia klasycznych praktyk IAM, monitoringu i secure-by-design na warstwę agentową. Im szybciej organizacje zaczną traktować agentów AI jak odrębną klasę ryzyka operacyjnego, tym mniejsze będzie prawdopodobieństwo, że pozornie niewinna automatyzacja doprowadzi do realnych strat biznesowych.
Źródła
- https://www.bleepingcomputer.com/news/security/how-one-ai-agent-exposed-five-critical-enterprise-security-gaps/
- https://cloudsecurityalliance.org/
- https://www.token.security/
- https://www.token.security/
- https://www.token.security/