Autonomiczni agenci AI, nadużycia zaufania, ciche awarie i mit bezpieczeństwa chmury zmieniają sposób, w jaki firmy powinny dziś myśleć o cyberodporności. O bezpieczeństwie nie decyduje już samo posiadanie backupu, lecz realna kontrola nad danymi – ciągła weryfikacja ich integralności i zdolność do skutecznego odtworzenia.
Łukasz Jesis
CEO, Xopero Software
Klasyczny atak wymagał włamania. Co się zmienia, gdy zagrożeniem nie jest już człowiek, tylko autonomiczny agent AI działający z uprawnieniami?
Wektor ataku przesuwa się z luk w zabezpieczeniach na nadużycie zaufania. Agent nie wgrywa trojana ani nie odpala skryptów powłoki. Wykonuje poprawne zapytania API, czyli robi dokładnie to, do czego został stworzony, lecz z wypaczonym celem biznesowym. Gdy dostajemy alert, atak już się skończył.
Jeśli agent AI usunie branch albo nadpisze konfigurację – czy w ogóle powinniśmy nazywać to atakiem? Co to oznacza dla odpowiedzialności prawnej pod NIS2 i DORA?
Jeśli akcja wynikała z zewnętrznej manipulacji, możemy mówić o ataku. Jeśli z halucynacji lub błędnego kontekstu – to incydent operacyjny. Dla NIS2 i DORA to rozróżnienie nie ma żadnego znaczenia. Liczy się skutek, nie powód. Prawo patrzy na zarządzanie ryzykiem cyberbezpieczeństwa, a nie na to, czy zawinił haker, czy algorytm. Krótko mówiąc: AI może podjąć decyzję, ale odpowiedzialność za to, jakie decyzje AI może podejmować, nadal pozostaje po stronie człowieka.
Ransomware atakuje punktowo, agent AI psuje dane tygodniami. Jak odtworzyć system, gdy nie ma jasnego „przed” i „po”?
Klasyczny backup bezmyślnie archiwizuje nawet uszkodzone dane. Kiedy nie ma jasnej granicy „przed” i „po”, szukanie punktu odtworzenia na osi czasu mija się z celem. Tutaj potrzebujemy ciągłej oceny integralności danych – odtwarzamy stan spójności, a nie znacznik czasu. W świecie agentów AI backup musi stać się nie tylko kopią danych, ale również mechanizmem weryfikacji ich historii i integralności. Na to wyzwanie odpowiada technologia SphereCyberX 360 opracowana przez Xopero Software. Wprowadzając model Zero Trust do magazynu danych i niezmienność kopii, zamienia zwykły backup w aktywny system ochrony.
Jakie błędy najczęściej popełniają firmy, projektując swoją strategię backupu, myśląc, że są już zabezpieczone?
Główny błąd to mylenie posiadania backupu z realną możliwością odtworzenia danych. Zabezpieczeniem nie jest sam zapis, lecz regularne testowanie procesów odzyskiwania. Tymczasem, jak pokazuje nasz raport Cyberbezpieczeństwo – Trendy 2026, co druga firma testuje ten proces jedynie sporadycznie, a 11 proc. nie zrobiło tego nigdy.
Ilu klientów odkrywa dopiero po incydencie, że GitHub, GitLab czy Atlassian nie odpowiadają za ich dane, tylko za infrastrukturę? To wciąż najdroższe nieporozumienie w branży?
Shared Responsibility Model to najdroższa iluzja w IT. Dostawcy gwarantują wyłącznie ciągłość działania platformy, ale za utracony kod, projekty czy metadane odpowiadasz wyłącznie Ty. Z myślą o załataniu tej luki powstał GitProtect.io, backup dedykowany dla DevOps. Tym bardziej, że sami dostawcy mają rosnący problem z ciągłością działania. W raporcie The DevOps Threats Unwrapped 2026 pokazujemy twarde dane za 2025 rok: 9 255 godzin łącznego czasu przestojów na platformach DevOps, 225 proc. wzrostu awarii krytycznych r/r oraz 43-procentowy skok liczby usuniętych podatności w drugim półroczu względem pierwszego.
Kto realnie jest dziś bardziej narażony: 30-osobowy software house czy korporacja z zespołem SOC? I dlaczego intuicja podpowiada tu złą odpowiedź?
Patrząc z perspektywy dzisiejszych zagrożeń – rozmiar firmy nie ma żadnego znaczenia. Boty i agenci AI atakują masowo. Już 1 na 5 organizacji przyznaje, że padła ofiarą cyberincydentu w ciągu ostatnich 12 miesięcy. Dla skryptu nie jesteś „dużą korporacją” ani „małym software housem” – jesteś po prostu otwartym portem lub systemem z podatnością. Różnicę obserwujemy tylko w typach katastrofy.
