Siedem pozycji tygodnia 31 lipca - 6 sierpnia 2026, z komentarzem, co każda zmienia w Waszych systemach.
W tym tygodniu trzy niezależne środowiska - organizacja standaryzacyjna, firma badawcza i dostawca oprogramowania dla przedsiębiorstw - opisały to samo zjawisko z trzech różnych stron. Nikt się nie umawiał. OWASP przesunął nadmiar samodzielności modelu na trzecie miejsce listy ryzyk. Red Hat policzył, ile firm ma nad tym realny nadzór, i wyszło mu trzydzieści jeden procent. SAP napisał, że decyzje o uprawnieniach agentów należą do zarządu.
Pytanie, które z tego wynika, jest w gruncie rzeczy stare i wcale nie dotyczy sztucznej inteligencji. Brzmi: kto ustalił, co temu narzędziu wolno. Nowe jest tylko to, że narzędzie zaczęło działać samo, a odpowiedź na to pytanie rzadko bywa przypisana konkretnej osobie.
Do tego dwie pozycje o tym, co agenty zaczynają realnie robić w automatyzacji, jeden polski wyciek i jeden atak, na który nie ma dziś dobrej odpowiedzi.
1. OWASP Top 10 dla aplikacji LLM: nowa edycja przestała opisywać obawy
4 sierpnia ukazała się edycja 2026 listy dziesięciu najpoważniejszych ryzyk w aplikacjach opartych na dużych modelach językowych. To pierwsza edycja, w której ranking powstał ze zderzenia dwóch źródeł: głosów praktyków oraz zapisu realnych incydentów. Autorzy nazywają tę różnicę wprost - to luka między tym, czego branża się boi, a tym, na czym już się sparzyła.
Trzy ruchy warto znać na pamięć.
Excessive Agency, czyli nadmiar samodzielności, awansowało na trzecie miejsce. Nie dlatego, że ktoś zmienił zdanie, tylko dlatego, że tam lądują szkody. Model dostał narzędzia i zaczął ich używać szerzej, niż ktokolwiek zaplanował.
Unbounded Consumption poszło w górę o cztery pozycje. Niekontrolowany koszt tokenów przestał być pozycją w budżecie, a stał się ryzykiem bezpieczeństwa. W wielu firmach ta zmiana nie została jeszcze odzwierciedlona w podziale odpowiedzialności - rachunek za model i raport z incydentu trafiają zwykle do dwóch różnych osób.
Improper Output Handling spadło z piątego na dziesiąte, ale z poszerzonym zakresem - obejmuje teraz niebezpieczny kod generowany masowo przez asystentów. Spadek w rankingu nie znaczy, że problem zniknął.
Jest jeszcze jedno rozgraniczenie, ważniejsze od samej kolejności. Ta lista opisuje ryzyko, gdy model jest komponentem wewnątrz aplikacji. W momencie, gdy staje się aktorem - ma narzędzia, które sam wywołuje, pamięć przenoszoną między sesjami i wywołuje skutki dalej w dół procesu - ryzyko przechodzi do osobnej listy, OWASP Top 10 for Agentic Applications. Autorzy piszą wprost, że wiele incydentów siedzi dokładnie na granicy i żadna z list nie pokrywa jej samodzielnie.
Praktyczny wniosek: jeżeli w projekcie agentowym ktoś powołuje się wyłącznie na listę dla LLM, ma połowę obrazu.
Równolegle powstał AISVS 1.0 - pierwszy testowalny standard weryfikacji bezpieczeństwa systemów AI, z poziomami dojrzałości i rozdziałami poświęconymi orkiestracji agentów oraz odporności na atak. Różnica jest zasadnicza. Lista ryzyk mówi, czego się bać. Standard mówi, co sprawdzić i jak udowodnić, że zostało sprawdzone.
Źródła: OWASP GenAI, dokument z 4.08.2026, licencja CC BY-SA 4.0; omówienie w Help Net Security, 6.08.2026.
2. Trzydzieści jeden procent
Red Hat opublikował badanie z trzema liczbami, które warto czytać razem, bo dopiero rozstęp między nimi coś mówi.
92 % organizacji deklaruje, że wie, gdzie przechowywane są dane wykorzystywane przez AI. 49 % ma nad tymi danymi pełną kontrolę. 31 % wdrożyło dojrzałe mechanizmy nadzoru nad agentową AI.
Spadek z dziewięćdziesięciu dwóch do czterdziestu dziewięciu to różnica między „wiemy“ a „możemy coś z tym zrobić“. Spadek z czterdziestu dziewięciu do trzydziestu jeden to coś innego - to różnica między kontrolą techniczną a ładem organizacyjnym. Ta druga luka jest trudniejsza, bo nie kupuje się jej razem z licencją.
Autorzy badania jako sprawdzian dojrzałości wskazują coś, czego nie sposób udawać: zdolność do zmiany dostawcy modeli lub platformy bez zakłócenia działalności. Formalną strategię wyjścia ma 63 % firm, a 30 % nie przygotowało jej wcale. W tej drugiej grupie 14 % zakłada, że migracja byłaby łatwa - co samo w sobie jest ciekawym pomiarem optymizmu.
Do momentu pierwszego wdrożenia agentowego nadzór jest zdaniem w polityce. Nasza obserwacja z projektów jest taka, że prawdziwy sprawdzian przychodzi w dniu, w którym agent dostaje uprawnienia do systemu produkcyjnego i ktoś musi rozstrzygnąć, co wolno mu zrobić bez pytania.
Uczciwie: badanie pochodzi od dostawcy platformy, która ma ten problem rozwiązywać. To nie unieważnia liczb, ale każe je czytać jako pomiar zrobiony przez zainteresowanego.
Badanie ukazało się dzień po pierwszym progu obowiązków AI Act. Zbieg okoliczności, ale wymowny.
Źródło: badanie Red Hat w relacji ITwiz, 3.08.2026. Raportu źródłowego Red Hat nie odnaleźliśmy w otwartym dostępie - liczby cytujemy za relacją.
3. UiPath Maestro Case: liczby, które warto znać
Wcześni użytkownicy modułu Maestro Case raportują skrócenie średniego czasu obsługi sprawy o 60-80 % i trzy do pięciu razy więcej spraw domykanych bez interwencji człowieka.
Jedno zastrzeżenie, zanim te liczby pójdą dalej: dotyczą wczesnych wdrożeń wybranych i opisanych przez producenta. To górna granica tego, co da się osiągnąć w procesie dobrze dobranym do narzędzia. Nie średnia i nie obietnica.
Ciekawsze od procentów jest to, czego dotyczą. Maestro Case zarządza sprawą, nie zadaniem. Różnica ma znaczenie praktyczne. Zadanie ma początek, koniec i robota. Sprawa potrafi żyć tygodniami, przechodzić przez kilka systemów i kilka par rąk, a po drodze zatrzymywać się na każdym etapie, który wymaga czyjegoś potwierdzenia. Klasyczna automatyzacja świetnie radzi sobie z zadaniem i staje dokładnie w tych momentach, w których sprawa czeka.
Procesy, w których takie liczby się powtarzają, mają wspólną cechę: dużo spraw, powtarzalne decyzje, dane rozrzucone po kilku systemach. Obsługa szkód. Helpdesk kadrowy. Zatwierdzenia w przepływach SAP.
I odwrotność, o której trzeba powiedzieć: jeżeli w firmie nie ma jeszcze zautomatyzowanych zadań, warstwa orkiestracji nie ma czym zarządzać. Maestro nie zastępuje pierwszego kroku.
Źródło: komunikat UiPath dla inwestorów.
4. Autopilot przestał podpowiadać, zaczął budować
Autopilot w UiPath Studio Desktop jest przedstawiany jako pełny agent kodujący: ma planować, budować, uruchamiać, diagnozować, wyjaśniać i przebudowywać automatyzacje. Podgląd publiczny, dostępny od linii STS S195 wzwyż. Jakości wyniku na realnym projekcie klienckim jeszcze nie znamy i piszemy o tym wprost.
Lista zapowiadanych możliwości jest dłuższa, ale trzy pozycje pokazują skalę zmiany. Dostaje trzydziestostronicową specyfikację procesu wdrożenia pracownika i buduje z niej kompletną automatyzację razem z krokami interfejsu. Bierze wdrożone zadanie, które o trzeciej w nocy zgłosiło odmowę dostępu, i sprowadza awarię do brakujących uprawnień robota. Dostaje działanie, które przestało działać po zmianie w aplikacji, nazywa przyczynę i naprawia selektor.
To ostatnie jest właśnie tym, co odróżnia go od agenta ogólnego przeznaczenia. Agenty ogólne nie wiedzą, czym jest selektor. Autopilot wie, bo działa wewnątrz Studio, na tych samych umiejętnościach co reszta platformy, z repozytorium obiektów w zasięgu. Automatyzacja interfejsu, czyli rdzeń klasycznego RPA, działa u niego od pierwszego dnia, a u agentów zewnętrznych bywa najsłabszym ogniwem.
Druga różnica dotyczy nadzoru i będzie ważniejsza w rozmowie z Waszym działem bezpieczeństwa niż lista funkcji. W granicach miesięcznego limitu nie jest potrzebna osobna subskrypcja ani rozliczenie za tokeny. Nie trzeba też zakładać konta u zewnętrznego dostawcy ani pilnować dodatkowych kluczy. Działania niszczące są bramkowane, poziom samodzielności ustawia administrator, zdarzenia trafiają do dziennika audytowego. Studio zostaje warstwą wizualną - każdą zmianę da się otworzyć, obejrzeć i zdebugować.
Trzy zastrzeżenia, bez których ta pozycja byłaby materiałem reklamowym. To podgląd publiczny, nie wersja ogólnie dostępna - nie stawia się na tym harmonogramu projektu. Miesięczny limit użycia nie został podany liczbowo, więc zanim padnie zdanie o braku dodatkowych kosztów, trzeba go ustalić dla konkretnej licencji. I rzecz najprostsza: klienci korzystający z linii LTS, czyli wydań z długoterminowym wsparciem, tej funkcji nie zobaczą.
Źródło: forum UiPath, ogłoszenie z 7.07.2026.
5. Żabka: weszli przez dostawcę, wynieśli mapę
4 sierpnia Żabka Polska potwierdziła nieuprawniony dostęp do wybranych zasobów technicznych poprzez konto zewnętrznego dostawcy usług. Incydent wykryto pod koniec poprzedniego tygodnia. Niezależnie na forum przestępczym pojawiła się oferta sprzedaży rzekomo wykradzionego zbioru za 5 000 EUR: zgłoszenia z systemu Jira, repozytoria kodu, informacje o użytkownikach. Zakresu firma nie ujawniła, a opis zbioru pochodzi od napastnika, nie od poszkodowanego.
Najciekawsza w tej historii jest cena wywoławcza. Pięć tysięcy euro to niewiele, co sugeruje, że sam napastnik nie uważa łupu za spektakularny. Jeżeli jego opis jest prawdziwy, sięgnął po materiał z kategorii, którą w większości firm klasyfikuje się jako techniczną, a nie wrażliwą.
Warto się zastanowić, co realnie leży w zgłoszeniach systemu zadań. Zrzuty konfiguracji wklejone w komentarzu, żeby kolega zobaczył błąd. Adresy systemów. Nazwiska i role osób znających poszczególne integracje. Opis tego, co konkretnie się psuje i od kiedy. Razem daje to mapę środowiska napisaną przez ludzi, którzy znają je najlepiej. Repozytoria dokładają szczegóły integracji, a w gorszym wariancie poświadczenia zostawione w historii zmian.
Formalnie mogą tu mieć zastosowanie dwa reżimy: obowiązki wynikające z RODO, w tym termin siedemdziesięciu dwóch godzin na zgłoszenie, oraz - jeżeli podmiot kwalifikuje się jako ważny - obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa.
Dwa pytania warto zadać sobie, zanim zada je ktoś inny. Do których naszych zasobów ma dziś dostęp każdy z dostawców. I co się stanie, jeżeli któryś z nich zadzwoni jutro rano z informacją o swoim incydencie. Umowa powierzenia odpowiada na pierwsze pytanie tylko wtedy, gdy ktoś ją od podpisania czytał.
Źródła: Sekurak, CRN, ITwiz, The Record.
6. SAP nazwał rozrost agentów problemem zarządu
3 sierpnia SAP opublikował artykuł o zjawisku, które nazwał rozrostem agentów: organizacje wdrażają agentów szybciej, niż budują mechanizmy ich nadzoru. Zdanie z materiału: „As adoption of AI agents accelerates, governance is struggling to keep pace“.
Teza idzie dalej niż diagnoza techniczna. Decyzje o uprawnieniach agentów są decyzjami o ryzyku biznesowym, więc należą do zarządu, nie do zespołu utrzymania. Producent pozycjonuje przy okazji własne warstwy jako odpowiedź, co jest naturalne i co warto sobie od razu powiedzieć.
W systemie ERP stawka wygląda inaczej niż w narzędziu marketingowym. Tam błąd agenta kosztuje kampanię. Tu agent działa na danych, na których stoi zamknięcie miesiąca, rozliczenie z dostawcą i deklaracja podatkowa. Zmiana wprowadzona przez agenta może wywołać skutek księgowy - i tym bardziej musi zostawiać ślad w dzienniku audytowym. Pisaliśmy o tym szerzej przy bezpieczeństwie agentów w SAP.
Dochodzi rzecz specyficzna dla tego środowiska. Uprawnienia w SAP buduje się latami, warstwa po warstwie, i rzadko ktoś potrafi z pamięci powiedzieć, co dokładnie może użytkownik techniczny, z którego uprawnieniami działa integracja. Agent, który dostaje uprawnienia „takie jak istniejąca integracja“, dziedziczy cały ten bagaż razem z tym, o czym wszyscy zapomnieli.
Pytanie na najbliższy przegląd: ilu agentów działa dziś w Waszym krajobrazie SAP, kto zatwierdził ich uprawnienia i czy tę listę da się odtworzyć bez odpytywania trzech osób. Jeżeli zebranie odpowiedzi zajmie tydzień, to jest dokładnie ten rozrost, o którym pisze SAP.
Źródło: news.sap.com, 3.08.2026.
7. Strona podsuwa instrukcję, agent ją wykonuje. Czy umiemy się przed tym bronić?
Zostawiliśmy na koniec pozycję, przy której odpowiedź brzmi „nie w sposób, który zamyka temat“.
Niezależne zespoły badawcze pokazują od kilkunastu miesięcy, że przeglądarki z wbudowanym asystentem dają się przejąć bez jednego kliknięcia użytkownika. Mechanizm jest banalny i właśnie dlatego groźny.
Asystent czyta stronę tym samym strumieniem tekstu, którym czyta Wasze polecenie. Napastnikowi wystarczy ukryć w treści kilka zdań sformułowanych jak instrukcja - białym drukiem na białym tle albo w akapicie, który agent i tak ma streścić. Asystent bierze te zdania za polecenie i wykonuje je. Nikt w nic nie klika. Wystarczy wpuścić agenta na przygotowaną stronę.
Skutki opisywane w badaniach idą dalej niż kradzież danych. Jeden ze scenariuszy podsuwa agentowi stronę udającą, że wymaga zalogowania, żeby przechwycić poświadczenia. Inny steruje tym, jakie informacje agent zbiera i do jakiego wniosku dochodzi - to jest atak nie na dane, lecz na rekomendację, którą agent Wam poda. Producenci dokładają zabezpieczenia, badacze obchodzą je po kolei i wprost piszą, że idealnej naprawy nie widać.
Nota o liczbie, która krąży po sieci. W obiegu jest wskaźnik 86 % skuteczności takiego ataku. Sprawdziliśmy go i nie potwierdza się w formie, w jakiej jest powtarzany: pochodzi z wcześniejszego opracowania (zestaw WASP, 2025) i opisuje częściowy sukces wstrzyknięcia polecenia, a nie odsetek udanych fałszywych logowań. Dlatego go tu nie podajemy jako faktu. Mechanizm jest udokumentowany i sam w sobie wystarczy - liczba nie jest tu potrzebna.
Dlaczego nie ma tu łatki
Powody są konstrukcyjne, nie wynikają z niedopatrzenia któregoś dostawcy.
Po pierwsze, agent ma jedne drzwi dla treści i dla poleceń. Jeden kanał wejściowy na tekst do przeczytania i na rozkaz do wykonania, bez pewnego sposobu odróżnienia, bo oba są zwykłym tekstem.
Po drugie, zniknął człowiek z pętli. To człowiek zwykle wyłapywał dziwne polecenie, zanim je wykonał. Agent działający samodzielnie usuwa ten moment. Zostaje sam tekst i sama akcja, a razem z nimi znika chwila, w której ktokolwiek mógł powiedzieć: chwila, tego nie zlecałem.
Stąd wniosek wart zapamiętania: kontrola na wejściu tego nie wyłapie, bo atak wygląda dokładnie jak treść, którą agent miał przeczytać. Widać go dopiero po tym, co agent robi.
Co da się zrobić dzisiaj
Cztery rzeczy. Żadna nie jest rozwiązaniem, wszystkie razem ograniczają zasięg szkody.
Obserwować zachowanie zamiast filtrować wejście. Skoro atak jest nieodróżnialny na wejściu, budżet idzie na warstwę nadzoru i wykrywanie odstępstw od zamierzonej trajektorii, nie na kolejny klasyfikator poleceń. Klasyfikator da się obejść - to już przerabialiśmy przy wcześniejszych podatnościach tej rodziny.
Postawić bramkę na działaniach nieodwracalnych. Płatność, wysyłka, zmiana uprawnień, usunięcie danych - wszystko, czego nie da się cofnąć, wymaga potwierdzenia człowieka. To jest miejsce, w którym wstawia się z powrotem usunięty moment.
Dać agentowi węższe uprawnienia niż użytkownikowi. Jeżeli odpowiedź na pytanie „do czego agent może sięgnąć po przejęciu“ brzmi „do wszystkiego, do czego ma dostęp użytkownik“, to jest zła odpowiedź.
Odizolować środowisko. Agent sterujący przeglądarką pracuje w wydzielonym środowisku, nie na stacji roboczej zalogowanej do systemów produkcyjnych.
Na koniec rzecz, którą wypada powiedzieć o sobie: korzystamy z narzędzi przeglądarkowych sterowanych agentem. Ta sama klasa ryzyka dotyczy nas, nie tylko naszych klientów, i traktujemy ją tak samo.
Co z tego wynika
Siedem pozycji, jeden wspólny mianownik. Lista ryzyk przesuwa nadmiar samodzielności w górę. Badanie pokazuje, że dojrzały nadzór ma mniej niż co trzecia firma. Dostawca ERP mówi, że to sprawa zarządu. Dwie pozycje o automatyzacji pokazują, ile ta samodzielność realnie daje, gdy jest dobrze obudowana. Wyciek przypomina, że granica firmy dawno przestała biec po jej infrastrukturze. A ostatni temat mówi wprost, że w jednym miejscu nie mamy dziś dobrej odpowiedzi.
Jeżeli mielibyśmy zostawić Was z jednym pytaniem na poniedziałek, brzmiałoby ono tak: kto w Waszej firmie podpisuje się pod zakresem uprawnień agenta - imiennie, nie stanowiskiem w polityce. Reszta jest wykonalna, gdy ta odpowiedź istnieje. Bez niej każda kolejna pozycja z tej listy jest tylko wiadomością z branży.
Jeśli któryś z tych tematów dotyczy Was bezpośrednio - nadzór nad agentową AI, bezpieczeństwo SAP, orkiestracja i automatyzacja z agentami - porozmawiajmy.
Przegląd tygodnia to nasz cotygodniowy wybór z kilkuset pozycji radaru i kanałów RSS. Źródła podlinkowane przy każdym punkcie. Materiał informacyjny, nie stanowi porady prawnej.