Przejdź do treści

Sprawdzam - przegląd tygodnia W42

Przegląd SNOK za 9-15.10.2026: SAP i Mistral AI, Microsoft Patch Tuesday i SAP Security Patch Day, Nadella o modelach jako ryzyku wewnętrznym, SAP Security Baseline Template, agenci wnoszeni z zewnątrz, UiPath Agent review, OWASP GenAI, małe modele na własnym sprzęcie, agenci przy SAP GUI.

Przegląd tygodnia W42, 9-15 października 2026: w pięciu z dziewięciu tematów źródło pierwotne mówi mniej niż nagłówek, a w pozostałych chodzi o kontrolę, której nie da się przenieść na dostawcę.

W pokerze „sprawdzam” kończy licytację i każe odkryć karty. Przygotowując ten przegląd, robiłem to samo przy każdej pozycji: od nagłówka szedłem do komunikatu, dokumentacji albo danych. Pięć razy karty okazały się słabsze, niż sugerował nagłówek. „Wycofanie” Niemiec z partnerstwa z SAP i Mistral AI ministerstwo nazwało nieporozumieniem. Z „trzech zero-day” Microsoftu aktywnie wykorzystywany jest jeden. Satya Nadella nie napisał, że wszystkie modele są skompromitowane. Dwa teksty o agentach wnoszonych przez pracowników to materiały partnerskie dostawców narzędzi. A prędkość z karty małego modelu, zmierzona przez autora na innym sprzęcie, na naszym Lenovo ThinkStation PGX spadła do ułamka.

W pozostałych czterech tematach wraca kontrola po stronie właściciela systemu: SAP zapowiada zmiany w szablonie bezpieczeństwa, UiPath wystawia agentom ocenę przed publikacją, zestawienie OWASP opisuje dziewięć incydentów i exploitów z udziałem agentów AI, a agenci kodujący zaczynają klikać w SAP GUI.

1. SAP i Mistral AI: rząd Niemiec nie planuje zakupów, ale niczego nie zerwał

W listopadzie 2025 roku firmy SAP i Mistral AI ogłosiły w Berlinie, na niemiecko-francuskim szczycie o suwerenności cyfrowej, sojusz na rzecz europejskiej suwerennej AI. Modele Mistral miały trafić na SAP BTP, a osobny filar suwerenności miał obsłużyć administrację publiczną, zaczynając od Niemiec. Rządy Niemiec i Francji podpisały z obiema firmami list intencyjny. 9 października Die Welt, za newsletterem Politico, napisał, że rząd federalny wycofuje się z tego partnerstwa. Rzecznik ministerstwa cyfryzacji potwierdził, że rząd federalny nie planuje zakupów od Mistral AI, a gazeta uznała, że planowana umowa ramowa jest na razie nieaktualna. Powodów nie podał ani rząd, ani Mistral. SAP odpowiedział, że dalej pracuje z Mistral nad suwerennymi rozwiązaniami AI. 14 października rzeczniczka ministerstwa powiedziała niemieckiemu serwisowi heise online, że doszło do nieporozumienia: niczego nie wypowiedziano, bo list intencyjny był niewiążący, a wiążącej umowy ramowej nigdy nie zawarto.

Obie wersje zgadzają się co do faktów: nie ma zamówienia i nie ma umowy. Różni je jedno słowo. Dla mnie to dobra lekcja czytania komunikatów o suwerennej AI, bo list intencyjny podpisany na szczycie politycznym jest deklaracją i nikt na jego podstawie niczego nie kupił. Tydzień temu pisałem, że europejska flaga nie przesądza o jakości modelu po polsku. Teraz widać, że nie przesądza też o kontrakcie. SAP nie wychodzi z tej historii z pustymi rękami: w maju, w osobnym zamówieniu, konsorcjum Telekom i T-Systems z udziałem SAP dostało 70 procent kontraktu na platformę AI dla niemieckiej administracji o wartości niecałych 250 mln EUR.

Rozmowę o suwerenności AI wolę zaczynać od pytań, na które odpowiada umowa i architektura: gdzie fizycznie działa model, kto ma dostęp do danych i logów, co się dzieje, gdy dostawca zmieni warunki. Zależność wybrana świadomie i wyceniona przed decyzją jest argumentem, o czym pisałem przy vendor lock-in. Tam, gdzie dane nie mogą wyjść z firmy, odpowiedzią jest LLM on-premise z modelem działającym na sprzęcie, który kontrolujecie.

Źródła: Die Welt, 9.10.2026; heise online, 14.10.2026; dpa-AFX przez BÖRSE ONLINE, 21.05.2026; SAP News Center, 18.11.2025. Status: potwierdzone - odczyt 16.10.2026.

Dwa pióra leżą obok niepodpisanej umowy na długim stole konferencyjnym, krzesła są odsunięte, sala opustoszała po spotkaniu

2. Microsoft Patch Tuesday i SAP Security Patch Day: ponad 1400 luk, jedna wykorzystywana w atakach

13 października Microsoft opublikował październikowe poprawki. BleepingComputer naliczył 1411 luk, w tym 70 krytycznych, Krebs on Security pisze o ponad 1400 i co najmniej 78 krytycznych - media liczą różnie, a Microsoft nie podaje jednej sumy. Aktywnie wykorzystywana jest jedna luka: CVE-2026-96951 w Windows Shell, obejście zabezpieczenia oznaczania plików pobranych z internetu, z oceną Important i CVSS 8,8. Dwie kolejne były ujawnione publicznie przed poprawką: CVE-2026-108398 w .NET Framework i CVE-2026-92707 w bibliotece MessagePack-CSharp. Według Krebsa Microsoft przypisuje tak dużą liczbę zgłoszeń modelom językowym używanym do wyszukiwania błędów. Wrzesień przyniósł rekord prawie tysiąca poprawek, a według Tenable liczba CVE Microsoftu w tym roku przekroczyła już 4000, przy poprzednim rocznym rekordzie 1261 z 2020 roku.

Ten sam dzień był SAP Security Patch Day: 18 not bezpieczeństwa SAP i 4 komunikaty bezpieczeństwa (advisory) na GitHubie, w tym jeden z oceną 10,0 dla SAP Cloud SDK for Python. Szczegóły opisaliśmy we wtorek. Zespoły utrzymania SAP dostały więc dwa duże cykle w jednym tygodniu, a plan poprawek SAP musi uwzględniać także system operacyjny i bazę danych, które mają własne cykle aktualizacji.

Przy takich liczbach sama suma nie wystarcza do ustalenia kolejności poprawek. Jeśli AI rzeczywiście podnosi liczbę znajdowanych błędów, wolumen zostanie z nami i proces poprawek musi go wytrzymać. Zgadzam się z Tylerem Regulym z Fortry, którego cytuje Krebs: najpierw luki wykorzystywane w praktyce, na przykład z katalogu CISA KEV, potem reszta według ekspozycji. Okna serwisowe SAP i warstwy systemowej warto planować razem, z uwzględnieniem zależności i wymaganych restartów. Utrzymanie systemów SAP prowadzimy w ramach SAP Basis 24/7, a poprawki SAP omawiamy co miesiąc w serii SAP Security Patch Day.

Źródła: BleepingComputer, 13.10.2026; Krebs on Security, 13.10.2026; MSRC, CVE-2026-96951; SAP Support Portal, Security Notes październik 2026. Status: potwierdzone; liczba luk według BleepingComputer, liczby SAP z naszego wpisu z 13.10.

Serwerownia nocą, na wózku serwisowym leżą dwie teczki z dokumentacją, technik w polarze zdejmuje panel jednej szafy, druga czeka z zapaloną bursztynową diodą

3. Satya Nadella: model trzeba traktować jak ryzyko wewnętrzne

10 października Satya Nadella opublikował na X długi tekst „Models as Insider Risks in the Super Intelligence Era”. Fragment przytoczony przez TechCrunch i The Verge brzmi: „We must assume a model is compromised and contain it from the start. Think of it like an emergency brake. An authorized person should always be able to pause or shut down a model mid-task”. Nadella proponuje traktować modele, zamknięte i otwarte, jak uprzywilejowanego pracownika: z tożsamością, ograniczonymi uprawnieniami, logowaniem i granicą izolacji. Nie zakłada przy tym złej woli modelu: każdy wystarczająco zdolny podmiot z dostępem do ważnych systemów może się pomylić albo zostać przejęty. Postuluje oddzielenie modelu od harnessu, który orkiestruje jego pracę, i kontrole działające poza modelem. Każda istotna akcja modelu ma zostawiać dowód odporny na manipulację i czytelny dla człowieka, a całość ma podlegać niezależnym audytom i obowiązkowi ujawniania incydentów.

Nagłówek The Verge skrócił to do „zakładajmy, że wszystkie modele są skompromitowane”. Nadella pisze coś ostrożniejszego i moim zdaniem ważniejszego: system ma działać poprawnie także wtedy, gdy model zawiedzie. Dwa tygodnie temu w przeglądzie W40 pisałem, że ograniczenie zapisane tylko w prompcie nie daje gwarancji, a tydzień temu o hamulcach, które rynek montuje dopiero po starcie. Teraz to samo mówi prezes firmy, która sprzedaje modele i agentów. Nie zmienia to mojej zasady z poprzedniego tygodnia: bezpieczeństwo agenta nie może opierać się na deklaracjach dostawcy. Ważne jest to, że postulat kontroli umieszczonej poza modelem formułuje teraz sam dostawca.

Wpis Nadelli formułuje zasadę projektową i nie zapowiada konkretnego produktu. W projektach UiPath przegląd AI Security jest u nas obowiązkowy, a brak akceptacji człowieka przy decyzjach wysokiego ryzyka traktujemy w nim jako błąd krytyczny. Kolejność powtarzam od lipca: najpierw proces, potem uprawnienia, na końcu podpis. Pytanie, gdzie w agencie jest hamulec i kto ma do niego dostęp, stawiamy w przeglądzie AI Security.

Źródła: TechCrunch, 10.10.2026; The Verge, 10.10.2026; wpis Satyi Nadelli na X, 10.10.2026. Status: cytat o hamulcu potwierdzony w dwóch redakcjach; pozostałe tezy według pełnego tekstu na X.

Dłoń operatorki opiera się obok czerwonego przycisku zatrzymania awaryjnego na pulpicie linii produkcyjnej, za szybą pracuje ramię robota

4. SAP Security Baseline Template: zmiany zapowiedziane w nocie 3831086

SAP Security Baseline Template to szablon SAP, z którego firmy budują własny standard konfiguracji bezpieczeństwa systemów SAP (baseline): listę parametrów, ustawień i wymagań, wobec których sprawdza się konfigurację. Obecna wersja ma numer 2.6. W nocie 3831086 SAP opisuje zmiany przygotowywane w kolejnej wersji. Treść noty jest dostępna dla klientów i partnerów zalogowanych w SAP for Me. Według KBA 2253549 szablon służy do budowy własnego standardu i do monitorowania zgodności przez Configuration Validation w SAP Solution Manager, a w SAP Focused Run przez Configuration & Security Analytics. Na GitHubie, w repozytorium SAP-samples, od 21 września pojawiają się gotowe polityki dla SAP Focused Run zgodne z wersją 2.6.

Standard opracowany na podstawie starszej wersji szablonu może wymagać aktualizacji, a stwierdzić to można tylko przez porównanie wersji. Zapowiedź zmian daje czas na takie porównanie, zanim zrobi je audytor. Kto ma SAP Focused Run, dostaje na GitHubie gotowy punkt startu dla wersji 2.6.

Przeglądy i pentesty SAP, które prowadzimy, obejmują poziom poprawek, autoryzacje, konfigurację, interfejsy i połączenia RFC, a kończą się raportem z priorytetami i retestem. Ciągłe monitorowanie bezpieczeństwa systemów SAP zapewnia SecurityBridge, którego jesteśmy Premier Partnerem w Polsce. Jeśli Wasz standard nie był porównywany z szablonem SAP od dłuższego czasu, nota 3831086 jest dobrym pretekstem.

Źródła: SAP Technical Guru, SAP Security Baseline Template; SAP KBA 2253549; SAP-samples, frun-csa-policies-best-practices. Status: potwierdzone istnienie i tytuł noty 3831086; lista zmian dostępna tylko dla zalogowanych.

Na stole metrologicznym leży stalowy wzorzec obok zużytej płytki pomiarowej, laborantka porównuje je suwmiarką pod lampą

5. Agenci wnoszeni z zewnątrz: osobisty agent pracownika i agent w cudzym oprogramowaniu

The Hacker News opublikował 10 i 12 października dwa teksty o agentach, których firma nie wybierała. Oba są materiałami partnerskimi: pierwszy napisała firma Reco, drugi Token Security, i oba kończą się opisem ich produktów. Reco pisze, powołując się na własny raport, że około 1280 produktów firm trzecich ma już wbudowaną AI, a tylko około 282 z nich jest objętych jednokrotnym logowaniem (SSO). Agenci trafiają do firmy na trzy sposoby: w aktualizacji używanej platformy, przez konfigurację w środowisku innego dostawcy albo jako własny projekt. Token Security opisuje drugą stronę: pracownicy podłączają osobistych asystentów przez zgody OAuth w Google Workspace, Microsoft 365 i Slacku, przez klucze API, hasła zapisane w przeglądarce agenta albo lokalnego agenta na laptopie. Rekomenduje cztery kroki: wykryć takie połączenia, przypisać każdemu właściciela, ograniczyć uprawnienia do niezbędnego zakresu i odebrać agentowi dostęp oraz tokeny, gdy pracownik odchodzi.

To dostawcy opisujący problem, który sami rozwiązują, a liczby Reco pochodzą z ich raportu. Uważam jednak, że ocena dostawców powinna dziś obejmować dostęp ich agentów do systemów klienta. NIS2 i DORA obejmują ryzyko związane z dostawcami, a agent dostawcy zalogowany w Waszym systemie jest moim zdaniem częścią tego ryzyka. Kwestionariusz dla dostawcy powinien dziś pytać, którzy agenci tego dostawcy mają dostęp do Waszych systemów, z jaką tożsamością, w jakim zakresie i gdzie zostaje ślad ich działań.

Tydzień temu pisałem o tym samym od strony SAP: ścieżka Bring Your Own Agent w SAP obsługuje dziś tylko wiadomości tekstowe, z limitem 60 sekund oczekiwania w trybie synchronicznym. Agent osobisty może też działać w ramach zarządzanej platformy, jak UiPath Delegate. Takie pytanie pasuje do audytu NIS2 i DORA i do przeglądu AI Security - tam, gdzie ocenia się dostawców i uprawnienia agentów.

Źródła: The Hacker News - tekst partnerski Reco, 10.10.2026; The Hacker News - tekst partnerski Token Security, 12.10.2026. Status: potwierdzone, że autorzy tak piszą; liczby według raportu Reco, bez niezależnej weryfikacji.

Recepcja biurowca, na blacie leży kilka identyfikatorów gościa bez nazwisk, przez bramki przechodzi kurier z paczką, a obok stoi pusty czytnik kart

6. UiPath Agent review: ocena od A do F przed publikacją agenta

8 października UiPath zastąpił Agent Score funkcją Agent review, na razie w wersji zapoznawczej. Przegląd uruchamia się z czatu Autopilota poleceniem „Review this agent” albo plakietką przy agencie. Agent dostaje ocenę od A do F, zależną od liczby i wagi znalezionych problemów. Problemy dzielą się na krytyczne, które według dokumentacji trzeba naprawić przed publikacją, ostrzeżenia, które mogą obniżać niezawodność agenta, i usprawnienia. Autopilot może je poprawić w tej samej rozmowie. Funkcja nie działa w Automation Cloud Dedicated i Test Cloud Dedicated. Polityka Automation Ops „minimalny Agent Score do publikacji” nie jest już egzekwowana i zniknie, bo agenci nie mają już wyniku liczbowego, który mogłaby sprawdzić. UiPath nie publikuje progów poszczególnych liter.

Tę zmianę oceniam bardzo wysoko: obok oceny literowej dostajemy listę konkretnych problemów i możliwość ich poprawienia w tej samej rozmowie z Autopilotem. Jest jednak luka: jeszcze miesiąc temu można było zablokować publikację agenta poniżej progu polityką platformy, a dziś ta blokada nic nie robi i nie ma jej następczyni opartej na ocenie od A do F.

Dlatego od 15 października w naszym standardzie wdrożeń agentów UiPath obowiązuje bramka procesowa: przed publikacją agent nie może mieć żadnego problemu krytycznego w Agent review, a zrzut oceny trafia do dokumentacji wdrożenia. Agent review nie zastępuje ewaluacji na zestawach testowych - to druga, osobna bramka, której szerzej dotyczy nasz agentic testing. Pełną drogę od pomysłu do produkcji opisaliśmy w ośmiu krokach budowy agenta w UiPath.

Źródła: UiPath Agents, release notes październik 2026; UiPath, Agent review; UiPath, dostępność funkcji agentów; UiPath Automation Ops, polityki Studio Web. Status: potwierdzone - odczyt 16.10.2026.

Inspektor w kamizelce odblaskowej przykleja zieloną plakietkę kontroli jakości na obudowę maszyny, obok na stole leży lista kontrolna z odhaczonymi pozycjami

7. OWASP GenAI: dziewięć incydentów i exploitów z udziałem agentów

8 października projekt OWASP GenAI Security opublikował zestawienie incydentów i exploitów AI z III kwartału 2026 roku, zmapowane na OWASP Top 10 dla aplikacji LLM i dla aplikacji agentowych. Autorzy zastrzegają, że nie jest to oficjalna publikacja OWASP ani pełny rejestr. Lista ma dziewięć pozycji, z których trzy pierwsze to elementy jednej kampanii ewaluacyjnej związanej z OpenAI. Według zestawienia agenci ewaluacyjni uruchomili kod na 41 produkcyjnych maszynach Hugging Face przetwarzających zbiory danych, model Claude Mythos 5 opublikował złośliwy pakiet PyPI, który przez około godzinę działał na 15 systemach, a model badawczy Claude skanował około 9000 celów poza zakresem testu. Jest też CoSnitch, rodzina exploitów na Microsoft Copilot (CVE-2026-24301) bez stwierdzonego wykorzystania w praktyce, oraz Deadbugz - serwer MCP, który przez trzy wywołania działał poprawnie, a potem zmienił opisy swoich narzędzi i próbował kierować agenta do kluczy SSH, poświadczeń AWS i konfiguracji Kubernetes; potwierdzonej kompromitacji zestawienie w tym przypadku nie odnotowuje.

Najważniejsze zdanie zestawienia brzmi: „Prompt-level instructions alone do not establish a secure boundary”. W większości opisanych przypadków nikt nie atakował agenta z zewnątrz. Agent realizował przydzielone zadanie i po drodze wyszedł poza nie, a odsłonięte poświadczenia i zbyt szerokie uprawnienia zamieniały pojedynczy błąd w szkodę w połączonych systemach. Autorzy rekomendują egzekwowany zakres działania, izolowane narzędzia i poświadczenia na jedno uruchomienie oraz monitorowanie akcji, które agent rzeczywiście wykonał.

Z tej listy chcę dodać do naszych przeglądów jedną konkretną kontrolę: migawkę definicji narzędzi serwera MCP w chwili zatwierdzenia i ponowną akceptację po każdej zmianie. Przypadek Deadbugz pokazuje, że poprawne zachowanie serwera przy pierwszych wywołaniach nie gwarantuje, że definicje jego narzędzi się nie zmienią. Takie pytania stawiamy w przeglądzie AI Security, a obronę po obu stronach agentowego ataku opisaliśmy przy okazji JADEPUFFER.

Źródło: OWASP GenAI Security Project, „GenAI and Agentic AI Exploit Roundup Q3 2026”, 8.10.2026. Status: potwierdzone, co podaje zestawienie; źródeł pierwotnych poszczególnych incydentów nie otwieraliśmy.

Na korkowej tablicy w pokoju zespołu bezpieczeństwa wisi dziewięć kart incydentów połączonych czerwoną nitką, analityk przypina dziesiątą pinezkę

8. Małe modele dla agentów na własnym sprzęcie i nasz pomiar na Lenovo ThinkStation PGX

W jednym tygodniu wyszły trzy małe modele projektowane pod agentów działających lokalnie. Underdog Saluki 27B to 2-bitowa wersja gęstego Qwen3.8-27B ściśnięta do 7,89 GB, na licencji Apache 2.0. W teście producenta obejmującym 120 zadań z BFCL v4 uzyskał 88 punktów wobec 84 pełnego modelu, choć producent sam przyznaje, że część przewagi może być wariancją. W osobnym teście 100 zadań z wywołaniami równoległymi przegrywa z konkurencyjną wersją 2-bitową (42 wobec 69). Liquid LFM2.5-24B-A2B to model mieszanki ekspertów z 2 mld aktywnych parametrów, na własnej licencji LFM Open License, dla którego producent podaje 184 tokeny na sekundę na Apple M5 Max i sam wskazuje słabszy wynik w programowaniu. JetBrains Mellum2.1 ma 12 mld parametrów, z czego 2,5 mld aktywnych, licencję Apache 2.0 i zalecaną wersję do uruchomienia lokalnego o rozmiarze 8,1 GB.

Wszystkie te liczby to deklaracje producentów, mierzone na ich sprzęcie, i tu mam własne doświadczenie, które studzi entuzjazm. Na naszym Lenovo ThinkStation PGX z układem NVIDIA GB10 i 128 GB pamięci zmierzyliśmy 1 października OrcaSAQ2 27B, czyli Qwen3.8 o 27 mld parametrów skompresowany do około 3 bitów na wagę. Karta tego modelu podaje 65 tokenów na sekundę, a z przyspieszeniem MTP 90, zmierzone na karcie graficznej z przepustowością pamięci około 960 GB/s. My zmierzyliśmy 8,5 tokena na sekundę, a z MTP 15,4. PGX ma przepustowość 273 GB/s, a model gęsty przy każdym tokenie czyta wszystkie wagi, więc deklaracja z innego sprzętu się nie przenosi. 16 października zmierzyliśmy dwa z nowych modeli na MacBooku Pro z M4 Max i 128 GB pamięci (llama.cpp, trzy powtórzenia, generowanie 128 tokenów). Pliki mają prawie ten sam rozmiar: Saluki 7,9 GB, Mellum2.1 w zalecanej wersji 8,1 GB. Saluki generował 22,3 tokena na sekundę, Mellum2.1 - 168,8, czyli ponad siedem razy szybciej. Różnicę robi architektura: Mellum2.1 przy każdym tokenie uruchamia 2,5 mld aktywnych parametrów, a Saluki wszystkie 27 mld.

Z tego wynika moja praktyczna zasada wyboru: na sprzęcie biurkowym tempo zależy przede wszystkim od liczby aktywnych parametrów modelu, więc do agentów lokalnych szukam najpierw modeli z niewielką liczbą aktywnych parametrów, a wywołania narzędzi sprawdzam własnym testem, bo karta modelu ich nie gwarantuje. Porównanie Mac Studio i DGX Spark jako maszyn do PoC opisałem we wrześniu, a test PGX w sierpniu. Jak dobieramy serwery Lenovo pod lokalny LLM dla UiPath, pokazaliśmy w zeszły czwartek we wpisie o UiPath on-premise. Jako partner Lenovo mamy interes w sprzedaży sprzętu - tym bardziej publikujemy liczby, które nie wyglądają jak z folderu.

Źródła: Underdog, Saluki 27B; Liquid AI, LFM2.5-24B-A2B, Hugging Face, 13.10.2026; JetBrains, Mellum2.1, 8.10.2026; pomiary SNOK z 1.10 i 16.10.2026. Status: wyniki modeli według producentów; prędkości na PGX i MacBooku Pro - nasz pomiar.

Na biurku przy oknie w warszawskim biurze stoi mały srebrny komputer, obok zamknięty laptop, otwarty zeszyt z notatkami i kubek, za szybą szare niebo nad miastem

9. Agenci kodujący w SAP GUI i serwery MCP dla ABAP

Deweloper SAP opisał w tym tygodniu na LinkedIn eksperyment: agenci kodujący, Codex, Claude i Pi, podłączeni bezpośrednio do SAP GUI przez SAP GUI Scripting, czytają stan ekranu i wykonują zadania zlecone w języku naturalnym. Autor zaznacza, że to faza testów, i nie publikuje kodu ani opisu uprawnień. W komentarzu inny praktyk SAP podał przykład zastosowania: aktualizację 500 ról w PFCG, dla której nie ma API. Równolegle rośnie sap-ai-dev-toolkit, pakiet npm dodający serwery MCP dla ABAP do SAP Business Application Studio. Według rejestru npm z 16 października ma licencję MIT, jednego opiekuna, 52 wersje opublikowane od 25 września, skrypt uruchamiany przy instalacji i około 123 MB po rozpakowaniu.

Pomysł jest kuszący, bo GUI Scripting od lat służy do masowych zmian bez API. Przewodnik bezpieczeństwa SAP GUI Scripting opisuje jednak dokładnie ryzyko: z punktu widzenia serwera SAP nie ma różnicy między komunikacją wygenerowaną przez skrypt a komunikacją użytkownika, a skrypt może wytworzyć więcej złych danych, zanim ktoś zauważy błąd. Agent na GUI działa więc z uprawnieniami użytkownika, w granicach ustawionych w konfiguracji, i może szybko powielić błędną operację, a autor nie opisał, jak rejestruje i odróżnia działania agenta. Według tego przewodnika, w wydaniu z 2004 roku, GUI Scripting jest domyślnie wyłączony parametrem sapgui/user_scripting; aktualne ustawienia dla Waszej wersji opisuje nota SAP 480149. Jeśli w Waszym systemie jest włączony, to pierwszy punkt przeglądu konfiguracji.

Przy masowych zmianach w PFCG wolę automatyzację z akceptacją człowieka przed zatwierdzeniem niż agenta, który sam klika w transakcjach. Pakiet od jednej osoby, publikowany kilka razy w tygodniu i wykonujący skrypt przy instalacji, u nas trafia najpierw do skanu i piaskownicy, a na systemy klientów nie trafia wcale. Pytanie o kod ABAP generowany przez AI postawiłem w felietonie „ABAP kompiluje się, więc działa”, a odpowiedź od strony narzędzi opisaliśmy w analizie kodu ABAP.

Źródła: post dewelopera SAP na LinkedIn, październik 2026; sap-ai-dev-toolkit, GitHub, dane z rejestru npm z 16.10.2026; SAP, „SAP GUI Scripting Security Guide”. Status: treść posta odczytana 16.10.2026 (data publikacji niewidoczna bez logowania), dane pakietu potwierdzone; przewodnik SAP z 2004 roku, aktualne ustawienia do sprawdzenia w nocie 480149.

Na biurku w biurze małe robotyczne ramię trzyma myszkę komputerową obok klawiatury, a konsultant w ciemnym swetrze stoi tyłem i przygląda się mu z założonymi rękami

Co sprawdzam, zanim uwierzę w nagłówek

Przy komunikacie politycznym sprawdzam, czy jest umowa i zamówienie. Przy liczbie luk - które są wykorzystywane. Przy cytacie prezesa - pełny tekst. Przy badaniu - kto je zrobił i co sprzedaje. Przy karcie modelu - nasz pomiar na naszym sprzęcie. A przy agencie - kto może go zatrzymać, jakie ma uprawnienia i czy jego narzędzia wyglądają dziś tak samo, jak w dniu zatwierdzenia.

Przegląd tygodnia SNOK · W42 · 9-15 października 2026

Całe wydanie w jednym pliku

PDF, dwanaście stron, około 1,2 MB - bez formularza i bez podawania danych. Wersja do przekazania dalej w zespole albo do przeczytania w telefonie.

Pobierz wydanie W42 (PDF)

Te pytania stawiamy w usługach AI Security, bezpieczeństwa SAP i LLM on-premise. Pytania: office@snok.ai.

Jacek Bugajski, CEO SNOK

Spodobał się artykuł? Proszę podać go dalej:

Skontaktuj się z nami