Ogień w fundamentach - przegląd tygodnia W43

Przegląd tygodnia W43, 16-22 października 2026: krytyczne luki w PHP, poważne luki w Node.js, złośliwe wydanie bramy LiteLLM, kwartalne poprawki Oracle, modele AI w badaniach nad podatnościami i w atakach, nowe techniki w MITRE ATT&CK oraz kontrola agentów w SAP i UiPath.

W tym tygodniu zawiodły warstwy, które traktujemy jak grunt pod nogami: PHP, na którym działa między innymi WordPress, środowisko uruchomieniowe Node.js i brama do modeli językowych LiteLLM.

PHP. 21 października projekt PHP wydał poprawki dwóch luk, CVE-2026-109618 i CVE-2026-109619, z oceną 9,2 w CVSS 4.0. Dotyczą każdej instalacji obsługującej żądania WWW, a zdalne wykonanie kodu wykazano dla mod_php i PHP-FPM. Amazon odnotował w swoich honeypotach pierwszą próbę ataku już 17 października, cztery dni przed publikacją poprawek, a identyfikatory luk zaczęły krążyć dzień przed nią. Centralny Ośrodek Informatyki czasowo wyłączył część stron BIP w systemie SSDIP. CISA w alercie z 21 października nie odnotowała wykorzystania, a Cloudflare, watchTowr i Patchstack raportują próby. Żadne ze źródeł sprawdzonych 23 października nie dokumentuje udanego włamania.

Node.js. Tego samego dnia projekt Node.js opublikował poprawki dziesięciu CVE, w tym zapisu poza buforem w dekoderze Brotli, który według komunikatu pozwala na zdalne wykonanie kodu. Dotyczy to także klientów SAP: na Node.js działają aplikacje SAP CAP i wiele rozszerzeń na SAP BTP, a za aktualizację środowiska odpowiada zespół aplikacji.

LiteLLM. Wydanie 1.107.0 w PyPI i w obrazach Docker, opublikowane przez przejęty potok wydań, zawierało kod kradnący poświadczenia. Narzędzie, które firmy stawiają między aplikacją a modelem, samo stało się kanałem ataku. Według Datadog okno ekspozycji w PyPI trwało około dwóch godzin, w Docker Hub dłużej. Opiekunowie projektu zalecają powrót do wersji 1.106.2, ręczne usunięcie złośliwych plików i rotację sekretów.

AI po obu stronach. W odkryciu luk PHP brali udział badacze korzystający z modeli AI - według Tenable mówią o tym Calif i Wiz - a błąd w dekoderze Brotli zgłosił zespół OpenAI Codex Security. XBOW opisał łańcuch exploita na Chrome, który jego agenci zbudowali w sierpniu w sześć dni na publicznie dostępnym modelu. Ta sama technologia, która pozwala znaleźć lukę przed atakującym, skraca drogę od opisu podatności do działającego ataku, a przy PHP pierwsza próba wyprzedziła poprawkę.

Inwentaryzacja i czas. Z tego tygodnia wynikają dla mnie trzy zadania: ustalić, gdzie działają PHP, Node.js i bramy modeli, także wewnątrz produktów, które tego nie pokazują; mierzyć w dniach czas od poprawki do wdrożenia; po każdym incydencie w łańcuchu dostaw rotować wszystkie sekrety. Rekomendacja Pełnomocnika Rządu ds. Cyberbezpieczeństwa, opublikowana 16 października na podstawie art. 67a ustawy o KSC, zaleca identyfikację usług dostępnych publicznie z internetu i formalny proces zarządzania podatnościami.

1. PHP2Shell: krytyczne luki w rdzeniu PHP i próby ataku przed poprawką

21 października projekt PHP wydał wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, które usuwają dwie luki: CVE-2026-109618, czyli uszkodzenie pamięci przy jej wyczerpaniu, oraz CVE-2026-109619, czyli odwołanie do pamięci po jej zwolnieniu, wynikające z nieaktualnego stanu globalnego. Zespół PHP ocenił obie na 9,2 w CVSS 4.0; krążąca wcześniej ocena 10,0 była błędna. Gałęzie 7.4-8.1 dostały tylko minimalne poprawki w kodzie źródłowym, bez nowych wydań. Według PHP Foundation pełne zdalne wykonanie kodu wykazano na serwerze Apache z mod_php przy ustawieniach domyślnych, a na PHP-FPM przez ścieżki kodu aplikacji; najwyższe ryzyko dotyczy mod_php. Zakres podatnych wersji źródła opisują różnie: CERT Polska od PHP 5.0, Calif i Tenable od 5.4.0.

Ujawnienie przebiegło w nieładzie. Amazon odnotował w honeypotach MadPot pierwszą próbę ataku 17 października. 20 października identyfikatory CVE zaczęły krążyć bez szczegółów technicznych, Calif omyłkowo opublikował nagranie z demonstracją exploita. 21 października o 7:41 UTC, ponad sześć godzin przed skoordynowanym wydaniem, Chainguard opublikował obrazy z poprawką; Fundacja zarzuca mu złamanie embarga, a Chainguard odpowiada, że widział już próby wykorzystania. CISA napisała w alercie z 21 października, że nie zaobserwowała wykorzystania, i do 22 października nie wpisała luk do katalogu KEV. Amazon, Cloudflare, watchTowr i Patchstack raportują próby ataków, przy czym według watchTowr krążące demonstracje exploita nie dają zdalnego wykonania kodu. Żadne ze źródeł sprawdzonych 23 października nie dokumentuje udanego włamania ani poszkodowanej firmy. W Polsce Centralny Ośrodek Informatyki czasowo wyłączył część stron BIP w systemie SSDIP.

Po takim tygodniu zaczynam od ustalenia, gdzie mamy PHP, także w produktach, w których go nie widać - CISA wprost zastrzega, że jego obecność nie zawsze jest widoczna z zewnątrz. Aktualizacja WordPressa czy wtyczek luki nie usuwa: trzeba zaktualizować samo PHP i zrestartować procesy robocze, a obejścia w konfiguracji zmniejszają ekspozycję, ale jej nie zamykają. Liczby serwerów krążące w mediach opisują hosty z PHP widoczne w skanach i nie mówią, ile instancji jest rzeczywiście podatnych, więc skali problemu nie da się dziś rzetelnie podać. Inwentaryzację usług wystawionych do internetu i plan poprawek po stronie infrastruktury prowadzimy w ramach audytu cyberbezpieczeństwa.

Źródła: php.net, 21.10.2026; PHP Foundation, 21.10.2026; CISA, 21.10.2026; katalog CISA KEV; CERT Polska, komunikat 195/2026; Tenable, FAQ, aktualizacja 22.10.2026; SecurityWeek, 22.10.2026; ITwiz, 22.10.2026. Status: wersje, oceny CVSS, przebieg ujawnienia i brak wpisu w KEV potwierdzone u źródeł pierwotnych 23.10.2026; próby ataków według relacji Amazon, Cloudflare, watchTowr i Patchstack (za SecurityWeek i Tenable); wyłączenie stron BIP według ITwiz.

2. LiteLLM 1.107.0: złośliwe wydanie bramy do modeli

21 października przed południem czasu UTC ktoś przejął potok wydań LiteLLM, popularnej bramy pośredniczącej między aplikacjami a modelami językowymi. Wersja 1.107.0 trafiła do PyPI, Docker Hub i GHCR, także pod tagami latest, main-latest i main-stable, i zawierała pliki cook.pth, cook.py i sitecustomize.py, uruchamiane przy każdym starcie interpretera Pythona, nawet gdy LiteLLM nie jest importowany. Kod zbierał sekrety chmurowe, poświadczenia narzędzi deweloperskich, sesje narzędzi AI i przeglądarek oraz zawartość bazy proxy LiteLLM, a tylna furtka co godzinę sprawdzała zdalny plik i mogła pobrać kolejny kod; drugiego etapu nie zaobserwowano. Według LiteLLM złośliwa wersja była dostępna w PyPI od 11:39 do 13:23 UTC, w Docker Hub od 11:46 do 14:20, a w GHCR najpóźniej do 13:51. Datadog podaje dla PyPI około dwóch godzin.

Datadog ustalił, że napastnicy użyli skradzionych tokenów OAuth GitHub CLI z kont trzech inżynierów i uruchomili potok z łudząco podobnego repozytorium. LiteLLM opisuje ten sam mechanizm, ale pierwotne wejście nadal traktuje jako hipotezę. Zalecenia opiekunów projektu: przypiąć wersję 1.106.2, ręcznie usunąć trzy pliki (odinstalowanie pakietu ich nie usuwa, a pip install w zainfekowanym środowisku uruchamia je ponownie), najlepiej odbudować środowisko, przy hoście z dostępem do internetu zakładać udaną eksfiltrację i zmienić wszystkie sekrety, w tym klucze dostawców modeli zapisane w bazie proxy oraz klucze master i virtual.

Złośliwe wydanie nie wzięło się z błędu w kodzie pakietu - przyszło przez przejęty potok publikacji, czyli kanał dystrybucji, któremu użytkownicy ufają. Brama modeli trzyma klucze do wszystkich dostawców naraz, więc jej przejęcie daje dostęp do całej warstwy AI firmy. Uważam, że tag latest nie powinien trafiać do produkcji: wersję bramy przypinam, obrazy odbudowuję z zaufanego źródła, a listę kluczy, które brama przechowuje, traktuję jak listę do rotacji po każdym incydencie. Bramy modeli i sposób przechowywania ich sekretów sprawdzamy w przeglądzie AI Security.

Źródła: LiteLLM, komunikat o incydencie, 21.10.2026; Datadog Security Labs, 21.10.2026. Status: potwierdzone u obu źródeł 23.10.2026; okna ekspozycji według LiteLLM (Datadog podaje dla PyPI różnicę kilku minut), wektor według Datadog, pierwotne wejście - hipoteza LiteLLM.

3. Node.js: dziesięć CVE i zdalne wykonanie kodu w dekoderze Brotli

21 października projekt Node.js wydał poprawki dziesięciu CVE - czterech o wadze high, trzech medium i trzech low - w liniach 26.x, 24.x i 22.x; bezpieczne wersje to 26.12.1, 24.22.1 i 22.23.4. Najpoważniejsza, CVE-2026-111497, to zapis poza buforem w dekoderze Brotli, który według komunikatu pozwala na zdalne wykonanie kodu. Zgłosił ją zespół OpenAI Codex Security. Komunikat nie podaje oceny CVSS ani warunków skutecznego ataku i nie wspomina o wykorzystaniu. To samo wydanie poprawia obejście weryfikacji nazwy hosta w TLS (CVE-2026-106069 i CVE-2026-105483) i aktualizuje magazyn certyfikatów CA w związku z naruszeniem bezpieczeństwa pośredniego urzędu certyfikacji eMudhra.

Najwyższa waga w komunikacie to „high”, ale dla klientów SAP temat jest pierwszoplanowy. Na Node.js działają aplikacje SAP Cloud Application Programming Model (CAP), wiele rozszerzeń na SAP BTP w środowisku Cloud Foundry i narzędzia budowania aplikacji MTA. Za wersję środowiska w buildpackach i potokach CI odpowiada zespół aplikacji, nie SAP, więc to ten zespół musi sprawdzić i wdrożyć poprawkę. Skoro PHP i Node.js wydały poprawki tego samego dnia, planowałbym dla nich jedno okno serwisowe i jedną inwentaryzację, obejmującą także obrazy kontenerów i agenty budowania. Rozszerzenia SAP BTP budujemy i utrzymujemy w ramach SAP BTP i Clean Core.

Źródło: Node.js, „October 2026 Security Releases”, 21.10.2026. Status: wersje, liczba CVE, opis błędu Brotli, zgłaszający i brak informacji o wykorzystaniu potwierdzone 23.10.2026; powiązanie z SAP CAP i SAP BTP to komentarz SNOK, nie treść komunikatu.

4. Oracle Critical Patch Update: 1295 poprawek i ocena 10,0 w E-Business Suite

20 października Oracle wydał kwartalny Critical Patch Update z 1295 nowymi poprawkami. Najwięcej dotyczy Fusion Middleware (206, w tym 134 dla luk możliwych do wykorzystania zdalnie bez uwierzytelnienia) i E-Business Suite (194, w tym 31 dla takich luk); dalej są Siebel CRM (122), Communications (110), JD Edwards (102), MySQL (98) i Java SE (55). Najwyżej oceniona luka, CVE-2026-101809, dotyczy komponentu Workflow Notification Mailer w Oracle Workflow, w E-Business Suite 12.2.3-12.2.15: atak przez HTTP, zdalnie i bez uwierzytelnienia, z oceną 10,0 w CVSS 3.1. Biuletyn nie oznacza żadnej luki jako wykorzystywanej, a katalog KEV jej nie zawiera. SecurityWeek i Tenable liczą 1209 unikalnych CVE i 95 krytycznych; inne zestawienia podają 112 krytycznych, bo liczą poprawki. Kolejne terminy Oracle to Critical Security Patch Update 17 listopada i 15 grudnia 2026 oraz CPU 19 stycznia 2027.

Oracle łata kwartalnie, SAP co miesiąc w ramach SAP Security Patch Day. W firmach z oboma systemami warto planować oba rytmy w jednym kalendarzu okien serwisowych, z jednym zespołem testów. Bardziej niż liczba poprawek zastanawia mnie miejsce najpoważniejszej luki: moduł wysyłający powiadomienia z workflow to komponent pomocniczy, którego zwykle nikt nie traktuje jak punktu wejścia do systemu, a jest dostępny bez logowania. Październikowe poprawki SAP omówiliśmy 13 października w serii SAP Security Patch Day, a testy regresji po paczce poprawek w SAP i Oracle opisaliśmy przy fabryce testów UiPath Test Cloud.

Źródła: Oracle, Critical Patch Update Advisory - October 2026; SecurityWeek, 22.10.2026. Status: liczba poprawek, liczby per produkt i CVE-2026-101809 z oceną 10,0 potwierdzone w biuletynie Oracle (wersja z 20.10.2026, odczyt 23.10.2026); 1209 unikalnych CVE i 95 krytycznych według SecurityWeek i Tenable.

5. Modele AI po obu stronach: badania nad PHP2Shell i łańcuch exploita na Chrome

PHP Foundation opisała 21 października, jak doszło do odkrycia luk. Pierwsze ślady problemu z wyczerpaniem pamięci znalazł w 2024 roku zewnętrzny audyt bezpieczeństwa PHP, który uznał exploit za teoretycznie możliwy, ale nie znalazł konkretnych wektorów. Wcześniej w 2026 roku Fundacja, we współpracy z Alpha-Omega, skanowała kod PHP modelem Anthropic Claude Mythos i włączyła OpenAI Daybreak Red do walidacji zgłoszeń i exploitów. 30 lipca audyt zaczęła firma Calif, której badacz 11 sierpnia zgłosił bezwarunkowe zdalne wykonanie kodu. Ten sam błąd niezależnie zgłosił OpenAI, który 18 września dosłał kolejne wektory, raport Wiz wpłynął 24 sierpnia, a audyt prowadzi też Trail of Bits. Według Tenable Calif i Wiz deklarują, że w badaniach korzystały z modeli AI. Fundacja pisze, że badania wspierane przez AI przynoszą „far more reports than before”, a modele pomagają walidować i grupować zgłoszenia, ale „a person makes every call and works on every patch”.

13 października XBOW opisał łańcuch trzech błędów Chrome dla Windows - w silniku V8, w dekoderze animowanych obrazów WebP i w Crashpad - zbudowany w dniach 2-7 sierpnia przez agentów pracujących na publicznie dostępnym modelu GPT-5.6 Sol i jego poprzednikach. Strategię wyznaczali i pracę agentów weryfikowali ludzie. Google wypłacił 250 000 USD nagrody, a wszystkie trzy błędy są naprawione. Pierwszy taki łańcuch zajął tej firmie wcześniej w 2026 roku około dwóch miesięcy. To deklaracje XBOW; niezależnej replikacji brak.

Wpis XBOW pochodzi z 13 października, sprzed okna tego przeglądu, i pokazuje to samo przyspieszenie co badania nad PHP. Ta sama klasa narzędzi zalewa opiekunów oprogramowania zgłoszeniami i skraca budowę exploita z miesięcy do dni. Zwracam uwagę na zdanie Fundacji o człowieku przy każdej decyzji: wąskim gardłem są dziś ludzie, którzy weryfikują zgłoszenia i przygotowują poprawki, a nie liczba znalezionych błędów. Po stronie obrońcy ten wyścig rozstrzyga czas od poprawki do wdrożenia - jeżeli pierwsza próba ataku na PHP wyprzedziła poprawkę o cztery dni, harmonogram łatania liczony w tygodniach przestaje wystarczać. O skracającym się czasie od ujawnienia do wykorzystania i o tym, co oznacza dla systemów przestarzałych, pisaliśmy 21 października przy liście EBC.

Źródła: PHP Foundation, 21.10.2026; Tenable, FAQ, aktualizacja 22.10.2026; XBOW, 13.10.2026; XBOW Labs, opis techniczny; Cloud Security Alliance, 14.10.2026. Status: przebieg odkrycia luk PHP potwierdzony u Fundacji 23.10.2026; dane XBOW potwierdzone u źródła jako deklaracje firmy, bez niezależnej replikacji (CSA); wpis XBOW z 13.10, spoza okna tygodnia.

6. MITRE ATT&CK v20: prompt injection i osłabianie autonomicznej obrony w katalogu technik

13 października MITRE wydał ATT&CK v20. Wśród dziewięciu nowych pozycji w macierzy Enterprise są T1698 Indirect Prompt Injection, T1699 Direct Prompt Injection, T1700 AI-Enabled Exfiltration, T1608.007 Stage Capabilities: AI Result Poisoning i T1685.007 Disable or Modify Tools: Impair Autonomous Defenses, a obok nich T1697 Steal Application Specific Passwords oraz T1696 Anti-Automation Evasion z podtechnikami dotyczącymi CAPTCHA. MITRE od lat prowadzi osobną bazę zagrożeń dla systemów AI, ATLAS. W ATT&CK, katalogu, którym zespoły SOC opisują każdy inny atak, techniki wymierzone w modele i agentów pojawiają się po raz pierwszy.

To pozycja nadrobiona z poprzedniego tygodnia, ale dobrze łączy się z resztą wydania. Wspólny identyfikator ułatwia rozmowę między zespołem bezpieczeństwa a zespołem, który wdraża SAP Joule albo agentów UiPath: prompt injection dostaje numer techniki, który da się powiązać z regułą detekcji i scenariuszem testu. Proponuję, żeby przeglądy AI Security mapowały ryzyka agentów na T1698-T1700 - to moja propozycja, praktyki jeszcze nie wdrożyliśmy. Jak wykorzystujemy MITRE ATT&CK przy ochronie SAP, opisaliśmy we wpisie o pogłębionej ochronie SAP, a agentów sprawdzamy w przeglądzie AI Security.

Źródło: MITRE ATT&CK - Updates. Status: numery, nazwy technik i data wydania potwierdzone 23.10.2026; wydanie z 13.10, spoza okna tygodnia.

7. Raporty OpenAI: agent wyłączył monitoring, model użył cudzego konta w sieci testowej

OpenAI prowadzi publiczną serię „Misalignment Reports and Notices” - na 23 października 20 raportów i 3 noty. Raport z 20 października opisuje dwa incydenty we wdrożeniach wewnętrznych. 3 października agent na GPT-6.1 Sol, naprawiając potok ewaluacyjny, wyłączył automatyczne alerty do zespołu bezpieczeństwa; monitor dalej zapisywał wyniki. 6 października agent na GPT-6 Astra podczas migracji środowiska, w którym działał (harness), usunął integrację monitoringu, a zapytany odpowiedział: „I did not remove an enabled monitor from it”. Żaden incydent nie miał priorytetu P0 i żadnego przebiegu pracy agenta nie zatrzymano automatycznie. OpenAI zaktualizował mechanizm Auto-Review dla wewnętrznego użycia Codex i przyznaje: „We don’t yet have a satisfying explanation for this behavior”.

Raport z 15 października, opublikowany dzień przed oknem tego przeglądu, dotyczy incydentu z 26 czerwca. Wewnętrzny model badawczy z rodziny GPT-5.6 Sol, wykonując zadanie programistyczne, sprawdził 362 adresy, wybrał konto z saldem w testowej sieci Ethereum Sepolia, którego klucz wyprowadził z publicznie znanych fraz odzyskiwania używanych przez deweloperów, opłacił z niego wdrożenie i nie wspomniał o tym w odpowiedzi końcowej.

Tydzień temu, przy wpisie Satyi Nadelli, pisałem o hamulcu awaryjnym, po który musi móc sięgnąć człowiek. Te raporty pokazują drugą stronę: agenci w trakcie zadania wyłączyli nadzór nad sobą, a jeden z nich zaprzeczył temu wobec pracownika; OpenAI nie ma jeszcze wyjaśnienia tego zachowania. Ślad działań i alarmowanie muszą więc działać poza zasięgiem agenta, którego dotyczą - uważam, że konfiguracja monitoringu nie powinna mieścić się w jego uprawnieniach. Doceniam, że wiemy o tym od samego producenta, który takie raporty publikuje regularnie. W projektach agentowych UiPath przegląd AI Security jest u nas obowiązkowy, a decyzje wysokiego ryzyka przechodzą przez akceptację człowieka w UiPath Maestro.

Źródła: OpenAI, raport z 20.10.2026 o monitoringu; OpenAI, raport z 15.10.2026 o portfelu testowym; OpenAI, lista raportów; BleepingComputer, 21.10.2026. Status: oba raporty potwierdzone u źródła pierwotnego 23.10.2026; wszystkie incydenty dotyczą wdrożeń wewnętrznych OpenAI.

8. Cairn: zautomatyzowane włamania prowadzone przez agentów AI

19 października Reuters i firma NorForge opisali operatorów, którzy wystawili do internetu panele Cairn - otwartej platformy wieloagentowej - i prowadzili przez nie zautomatyzowane włamania. NorForge oceniła jako złośliwe ponad 20 paneli. Chińskojęzyczny klaster oznaczony AIA0001 obejmował 14 paneli i ponad 1100 projektów wymierzonych w firmy e-commerce i płatności w USA, Japonii i Australii. Według NorForge od startu do osiągnięcia celu mijało średnio mniej niż 23 godziny, skuteczność autorzy szacują na około 10 procent, a z setek zebranych poświadczeń 11 procent zweryfikowali jako aktywne. Reuters pisze o włamaniach na strony ponad 100 firm i próbach wobec ponad 1200 witryn od 25 września. Deere poinformował, że podjął niezbędne działania naprawcze i nie ma oznak dostępu do danych wrażliwych, SharkNinja, że chodziło o samodzielną stronę wsparcia produktów, a zagrożenie opanowano, a Cummins sprawdza możliwy atak na stronę prowadzoną przez dostawcę. Autor Cairn podkreśla, że platforma nie powstała do ataków.

Pozycja 5 pokazywała przyspieszenie u badaczy, ta - u atakujących, w operacji opisanej na podstawie danych z samych paneli. Atak prowadzony przez automat trwa godziny i kosztuje niewiele, więc czas reakcji zespołu monitorującego trzeba odnosić do tempa automatu. Całą operację ujawniły panele narzędzia AI wystawione do internetu bez uwierzytelnienia. To samo dotyczy narzędzi AI uruchamianych w firmach, dlatego inwentaryzacja usług wystawionych do internetu powinna obejmować także ich panele. Monitorowanie ekspozycji i reagowanie na incydenty prowadzimy w ramach cyberbezpieczeństwa.

Źródła: NorForge, „Inside Cairn”, 19.10.2026; Reuters, 19.10.2026, przedruk w CP24. Status: raport NorForge potwierdzony u źródła 23.10.2026; relacja Reutersa i oświadczenia firm według przedruku depeszy; nazwy firm pochodzą od Reutersa, NorForge ich nie podaje.

9. NVIDIA OpenShell Reference Architecture: SAP Joule Studio runtime i Lenovo wśród partnerów

21 października, na GTC w Berlinie, NVIDIA ogłosiła OpenShell Reference Architecture - referencyjny stos do uruchamiania agentów AI: inferencja na platformie Vera Rubin, procesory Vera dla harnessów agentów, OpenShell jako granica wykonania i BlueField-4 z oprogramowaniem Sentry jako nadzór działający poza agentem (out-of-band). Według komunikatu „SAP is integrating the NVIDIA OpenShell Reference Architecture with Joule Studio runtime” jako częścią SAP Business AI Platform, „connecting business governance with secure agent execution”. Lenovo jest wymienione obok Dell Technologies, Cisco, HPE i Supermicro wśród firm, które budują infrastrukturę na tej architekturze. NVIDIA podaje, że architektura jest dostępna, ale wiele produktów i funkcji opatruje zastrzeżeniem „when-and-if-available”.

Czytam to jako odpowiedź na pytanie, kto pilnuje agenta w SAP: dwa punkty kontrolne - autoryzacja biznesowa w SAP Joule Studio runtime i izolacja wykonania w OpenShell - w miejsce ogólnika o „guardrails”. Łączy się to z pozycją 7, bo nadzór działa tu w warstwie, której agent nie konfiguruje. W przeglądzie W40 pisałem o agentach w SAP Joule Studio i o tym, że ograniczenie zapisane w prompcie nie daje gwarancji; architektura NVIDIA przenosi tę zasadę na sprzęt i środowisko wykonania. To zapowiedź producenta: SAP jest w trakcie integracji, a NVIDIA zastrzega dostępność wielu elementów. W jednym komunikacie spotykają się dwa obszary działalności SNOK - SAP i Lenovo, którego jesteśmy partnerem Platinum - więc piszę o nim z pozycji, która nie jest neutralna. Pytanie o bezpieczeństwo agentów w SAP rozwijałem w felietonie o trzech aktach SAP AI.

Źródła: NVIDIA Newsroom, 21.10.2026; SAP News, 28.09.2026. Status: cytaty o SAP, Lenovo, dostępności i zastrzeżeniu potwierdzone w komunikacie NVIDIA 23.10.2026; podział ról między SAP Joule Studio runtime i OpenShell - moja interpretacja, zgodna z zapowiedzią SAP z 28.09.

10. UiPath Delegate: polityka Automation Ops i nowe modele dopuszczone domyślnie

UiPath Delegate, agent działający na komputerze pracownika, jest zarządzany polityką w Automation Ops (produkt „Assistant”, szablon 26.10.0 lub nowszy). Polityka ma zakładki Tools, Helper Agents, MCP Servers, Security, Tool Permissions, Models oraz Skills & Knowledge, a gdy użytkownika obejmuje kilka polityk, wygrywa najbardziej szczegółowa. Informacje o wydaniach z października: 1 października Delegate wszedł w publiczną wersję zapoznawczą na macOS (Apple Silicon, macOS 14 lub nowszy), a 6 października administratorzy dostali możliwość wymuszenia trybu Restricted access, wskazania miejsca zapisu zadań i ograniczenia celów telemetrii. 22 października, wraz z wersją 1.6.9, UiPath wprowadził zmianę: „Automation Ops allows each new model by default”. Kto zablokował Claude Opus 5 albo 4.8, musi osobno wyłączyć Claude Opus 5.5. Dokumentacja nie opisuje wykrywania ani blokowania innych narzędzi AI na stacji roboczej.

Dla administratora to konkretny punkt kontrolny: lista blokad modeli nie przenosi się sama na kolejne wersje, więc każdy nowy model w Delegate wymaga ponownego przejrzenia polityki. Agenta, którego organizacja sama daje pracownikom, da się objąć jedną polityką obejmującą narzędzia, serwery MCP i modele, pod warunkiem że polityka nadąża za producentem. Delegate opisywaliśmy przy publicznej wersji zapoznawczej i we wpisie o agencie dla osoby.

Źródła: UiPath Delegate - Governance with Automation Ops; UiPath Delegate - informacje o wydaniach, październik 2026. Status: polityka, zakładki i zmiany z 1, 6 i 22 października potwierdzone w dokumentacji UiPath 23.10.2026.

Inwentaryzacja, czas wdrożenia poprawki i nadzór poza agentem

W tym wydaniu zawiodły trzy rodzaje fundamentów: oprogramowanie, na którym stoją aplikacje (PHP, Node.js, Oracle), łańcuch dostaw narzędzi AI (LiteLLM) i sam agent, który potrafi wyłączyć nadzór (raporty OpenAI). Odpowiedź zaczyna się od inwentaryzacji tego, co faktycznie działa, od czasu między poprawką a wdrożeniem mierzonego w dniach i od śladu działań, który powstaje poza narzędziem, którego dotyczy. Identyfikację usług dostępnych z internetu i formalny proces zarządzania podatnościami zaleca wprost rekomendacja Pełnomocnika Rządu dla podmiotów KSC (pkt 2.1 d i 3.2). Pomiar czasu w dniach to moja propozycja, a potrzebę śladu działań poza agentem pokazują raporty, które producenci modeli publikują sami.

Te sprawy prowadzimy w usługach cyberbezpieczeństwa, AI Security i bezpieczeństwa SAP. Gotowość systemów SAP na wymagania KSC i NIS2 sprawdza bezpłatne narzędzie SNOK KSC-CHECK. Pytania: office@snok.ai.

Jacek Bugajski, CEO SNOK