Nowa funkcja agenta może wyglądać jak zwykły dodatek, ale po instalacji staje się kodem działającym z częścią jego uprawnień. Polska placówka powinna dopuścić taki dodatek dopiero po potwierdzeniu właściciela i źródła kodu, przejrzeniu zależności, ograniczeniu dostępu, teście w izolacji oraz sprawdzeniu cofnięcia. Ten tekst prowadzi przez sześć kontroli i kończy się jedną z trzech decyzji: dopuścić, odizolować do dalszych testów albo zablokować.

Agent AI (program, który może wykonywać kolejne polecenia i uruchamiać podłączone narzędzia) nie działa wyłącznie w oknie rozmowy. Może pobrać plik, wywołać usługę albo uruchomić kod, jeśli jego środowisko na to pozwala. 27 sierpnia 2026 r. Ars Technica opisał badanie, w którym dokumentacja na ponad 100 witrynach wskazywała setki komend lub nazw prowadzących do niezarejestrowanych pakietów i domen. Badacze przejęli część wolnych nazw do bezpiecznego testu i odnotowali połączenia z firmowych środowisk.

To nie jest opis incydentu w polskiej placówce medycznej ani dowód, że każdy agent instaluje kod samodzielnie. Jest to ostrzeżenie o mechanizmie: prawdziwa strona i wiarygodnie wyglądająca instrukcja nie potwierdzają, kto kontroluje nazwę pakietu. Jeżeli agent ma dostęp do plików, poczty, elektronicznej dokumentacji medycznej (EDM) lub narzędzia wykonującego polecenia, granicę decyzji musi ustalić placówka przed pierwszym uruchomieniem dodatku.

Co zewnętrzne badanie pokazało o pakietach bez właściciela?

Badacze analizowali dodatkowe pliki tekstowe, w których strony podawały narzędziom AI instrukcje. Część plików na prawdziwych domenach zawierała polecenia instalacji nazw, które w publicznych katalogach pakietów kodu nie miały przypisanego właściciela. Oficjalna domena potwierdza pochodzenie dokumentu, ale nie rezerwuje automatycznie nazwy pakietu w innym serwisie.

Kluczowe jest tu konto publikujące pakiet — konto, które może umieszczać kod pod daną nazwą w publicznym katalogu. Jeżeli nazwa jest wolna, ktoś może ją przejąć i opublikować pod nią kod inny niż oczekiwany przez autora dokumentacji. W opisanym przypadku jedno polecenie mogło pobrać i uruchomić kod prosto z katalogu bez zapisania go na zwykłej liście składników projektu. To utrudnia zauważenie, że uruchomiono dodatkowy kod.

Badacze wskazali, że część połączeń wykonywały programy oznaczone nazwami Claude, Codex i Hermes, ale nie dowiedli powszechnego zainfekowania firm ani nie opublikowali surowego zbioru danych. Niezależna baza Google OSV potwierdza natomiast, że dwie wersje pakietu clerk-next-fix-auth-protection były złośliwe i podczas instalacji wysyłały podstawowe informacje o środowisku. To wystarcza do wniosku zarządczego: instrukcja z zaufanej strony nie może zastąpić weryfikacji kodu, który zostanie wykonany.

Kontrole 1–4: kto odpowiada za kod, instrukcję, dodatkowe pakiety i dostęp?

Pierwsze cztery kontrole placówki ustalają, kto opublikował kod, skąd pochodzi instrukcja, jakie dodatkowe pakiety uruchamia dodatek i do czego chce uzyskać dostęp. Model, agent i dodatek to trzy różne warstwy. Model przygotowuje odpowiedź. Agent decyduje, jakich narzędzi użyć. Dodatek rozszerza dostępne czynności i może zawierać własne skrypty instalacyjne. Ocena marki modelu nie mówi jeszcze, co robi kod rozszerzenia ani skąd pochodzi.

Dodatek może też pobierać kolejne zależności, czyli dodatkowe pakiety kodu. Dlatego nazwa jednego pakietu nie wyczerpuje przeglądu. CERT Polska zaleca jednoznaczną identyfikację produktu i wersji oraz aktualną listę wszystkich składników oprogramowania. Taki wykaz, często nazywany SBOM, nie gwarantuje bezpieczeństwa, ale pokazuje, co placówka ma monitorować i co może wymagać naprawy.

Druga oś to uprawnienia. Dodatek powinien dostać wyłącznie dostęp niezbędny do jednej zatwierdzonej funkcji. Rozszerzenie porządkujące pliki testowe nie potrzebuje produkcyjnej skrzynki pocztowej ani EDM. Centrum e-Zdrowia zaleca zasadę najmniejszych uprawnień, separację środowisk oraz używanie pakietów i repozytoriów z zaufanych źródeł. Ochrona przed prompt injection w placówce (wrogimi instrukcjami ukrytymi w treści) pozostaje osobną kontrolą: nawet poprawnie pozyskany dodatek nie powinien wykonywać każdej instrukcji znalezionej w dokumencie lub na stronie.

Kontrola 5 — scenariusz testu: jak odizolować dodatek od danych pacjentów?

Przykład modelowy — poniższa placówka, skrzynka i przebieg testu są hipotetyczne. Scenariusz pokazuje sposób ograniczenia pierwszego uruchomienia dodatku; nie opisuje zdarzenia w konkretnej placówce ani nie dowodzi skuteczności klinicznej lub pełnego bezpieczeństwa.

Wyobraźmy sobie, że dostawca proponuje rozszerzenie, które ma pobierać załączniki z poczty i przygotowywać ich spis. Wygoda jest realna, ale test na produkcyjnej skrzynce natychmiast łączy nieznany kod z wiadomościami pacjentów. Pierwsze uruchomienie powinno odbyć się w oddzielonym środowisku, z fikcyjną skrzynką, syntetycznymi plikami i kontem pozbawionym dostępu do sieci placówki.

Manager nie wykonuje tych technicznych czynności sam. Administrator lub partner IT obserwuje, jakie pliki dodatek tworzy, jakie polecenia uruchamia, z jakimi adresami próbuje się łączyć i czy zachowuje się zgodnie z deklaracją. Brak dostępu do internetu na początku testu jest bezpieczniejszy niż otwarte połączenie; administrator dopuszcza później tylko konkretne, zatwierdzone adresy. Projekt SAFE prowadzony przy Linux Foundation proponuje podobne mechanizmy dla agentów: listę dozwolonych adresów, niezależne sprawdzenie odizolowania testu, zapisywanie działań i automatyczne zatrzymanie przy niejasnym zakresie. SAFE jest jednak propozycją do dyskusji, a nie przyjętym standardem ani polskim obowiązkiem.

Kotwica decyzji jest prosta. Jeśli dodatek nie wykona funkcji bez prawdziwego hasła lub klucza dostępu, szerokiego dostępu do plików albo nieograniczonego internetu, test ujawnił warunek ryzyka, a nie przeszkodę do obejścia. Placówka może poprosić dostawcę o węższy wariant, osobne konto lub podpisany plik instalacyjny, którego źródło można potwierdzić i sprawdzić, czy plik nie został zmieniony. Nie powinna przesuwać eksperymentu do EDM tylko dlatego, że w środowisku testowym „nic się nie wydarzyło”.

Kontrola 6: kto zatwierdza instalację i potrafi ją cofnąć?

Manager powinien, najpierw wyznaczyć właściciela decyzji. Nie podpisuje jednak sam kontroli technicznej: administrator lub partner IT sprawdza konto publikujące, dokładną wersję, dodatkowe pakiety, znane luki bezpieczeństwa i adresy, z którymi dodatek chce się łączyć. Dostawca przedstawia pochodzenie, wersję, zależności, wymagane uprawnienia i procedurę usunięcia. Administrator lub partner IT sprawdza te informacje w środowisku testowym, ogranicza poświadczenia, analizuje logi (zapisy działań systemu) i potwierdza, że procedura cofnięcia rzeczywiście działa.

Inspektor ochrony danych (IOD) ocenia cel i zakres przetwarzania, gdy test lub planowane użycie dotyka danych osobowych, logów użytkowników albo systemów medycznych. Nie zastępuje jednak przeglądu kodu. Manager procesu rozstrzyga, czy funkcja jest potrzebna, kto może jej używać i jaki tryb ręczny obowiązuje po zatrzymaniu dodatku. Jeżeli wynik może wpływać na dokumentację lub decyzję kliniczną, odpowiednia osoba medyczna zatwierdza treść; agent ani administrator nie przejmuje tej odpowiedzialności.

Cofnięcie nie kończy się na kliknięciu „odinstaluj”. Trzeba unieważnić tokeny dostępu (cyfrowe poświadczenia używane przez system) i klucze, sprawdzić utworzone pliki, przywrócić zmienioną konfigurację, przejrzeć połączenia oraz zachować log decyzji. Na końcu zespół ustala kto podpisuje decyzję. Bez przypisanego właściciela i sprawdzonego trybu ręcznego nie ma podstaw do uruchomienia produkcyjnego.

Karta decyzji z sześciu kontroli: dopuścić, odizolować czy zablokować?

Kartę wypełnia się dla jednego pakietu i jednej wersji, nie dla całej marki agenta. Manager zbiera dokumenty i wyznacza osoby sprawdzające. Administrator lub partner IT potwierdza konto publikujące, dodatkowe pakiety, polecenia instalacyjne, znane luki i połączenia; IOD ocenia dane osobowe, a manager procesu podpisuje końcową decyzję. Samo „dostawca zapewnia” nie jest dowodem technicznym.

KontrolaDowód wymagany przed testemWynik przy braku dowodu
Właściciel i pochodzeniezgodność firmy z kontem, które opublikowało kod; dokładna nazwa i wersja; link do publicznego katalogu sprawdzony przez administratoraodizoluj; zablokuj przy sprzecznym lub przejętym właścicielu
Źródło instrukcjizatwierdzona dokumentacja z dokładną komendą i opisem skutkówzablokuj instrukcję znalezioną w nieznanym dokumencie lub treści zewnętrznej
Kod i zależnościlista wszystkich pakietów, dokładne numery wersji, opis poleceń uruchamianych podczas instalacji oraz raport z kontroli znanych luk bezpieczeństwaodizoluj do wyjaśnienia; brak listy nie daje zgody
Uprawnienia i połączenialista plików, usług, haseł lub kluczy, narzędzi i adresów internetowych potrzebnych funkcjizablokuj, gdy dostępu nie można zawęzić
Izolacja i obserwacjaśrodowisko testowe bez danych pacjentów, pełne logi działań i możliwość natychmiastowego zatrzymanianie uruchamiaj poza izolacją
Cofnięcie i reakcjaprocedura usunięcia, unieważnienia poświadczeń, odtworzenia konfiguracji oraz właściciel incydentuodizoluj do testu cofnięcia; zablokuj, jeśli skutków nie da się ograniczyć

Dopuść oznacza, że wszystkie dowody są kompletne, dostęp jest minimalny, test zakończył się zgodnie z planem, a cofnięcie zadziałało. Odizoluj oznacza, że właściciel i źródło kodu wydają się prawidłowe, ale brakuje dowodu; pakiet nie trafia do prawdziwych systemów. Zablokuj oznacza sprzeczne pochodzenie, nieznany kod, nadmierny dostęp, złośliwy fragment kodu albo brak sposobu zatrzymania.

Jaki jest pierwszy krok przed rozmową z dostawcą?

Pierwszym krokiem jest wstrzymanie instalacji i otwarcie karty sześciu kontroli dla dokładnej nazwy oraz wersji pakietu. Wyślij ją dostawcy przed demonstracją, nie po niej. Poproś o dowód właściciela konta publikującego, listę dodatkowych pakietów, opis poleceń uruchamianych podczas instalacji, minimalne uprawnienia, używane adresy internetowe i procedurę cofnięcia. Wyznacz administratora lub partnera IT, który niezależnie sprawdzi te odpowiedzi.

Warto kontynuować, gdy każdy dowód ma źródło, właściciela i sposób sprawdzenia, a funkcja działa bez danych pacjentów i szerokiego dostępu. Zatrzymaj projekt, gdy nazwa pakietu nie zgadza się z właścicielem, dostawca nie potrafi wyjaśnić zależności, rozszerzenie żąda haseł lub kluczy do prawdziwych systemów przed testem albo cofnięcie pozostaje tylko obietnicą.

Po pozytywnym teście placówka nadal nie wydaje zgody „na zawsze”. Decyzja dotyczy konkretnej wersji i konkretnego zakresu. Zmiana kodu, zależności lub uprawnień otwiera kartę ponownie. Dzięki temu szybkość dodawania funkcji nie zamienia się w zgodę na niewidoczny kod działający pod zbyt szerokim kontem.

Źródła