# Wasz asystent AI odmawia. To nie znaczy, że Was chroni > Ta sama prośba raz wykonana, raz odrzucona - zależnie od przebiegu rozmowy. Dlaczego odmowa modelu nie jest zabezpieczeniem i co kontroluje agenta realnie. - Source: https://snok.ai/pl/aktualnosci/blog/odmowa-asystenta-ai-nie-jest-zabezpieczeniem/ - Author: Michał Korzeń - Published: 2026-09-09 --- Wasz analityk bezpieczeństwa prosi firmowego asystenta AI o pomoc przy analizie podatności. Asystent odmawia - grzecznie, z uzasadnieniem, że to zadanie o charakterze ofensywnym. Godzinę wcześniej ten sam asystent wykonał niemal identyczne polecenie dla kogoś innego. Nikt niczego nie przestawiał. Nie zmieniła się konfiguracja, nie było aktualizacji modelu, nikt nie ruszał uprawnień. Zmieniło się wyłącznie to, co model widział w rozmowie, zanim padła prośba. ## Dlaczego to jest Wasz problem, a nie ciekawostka W dokumentach opisujących wdrożenia AI odmowa modelu bywa wpisana jako zabezpieczenie. Brzmi to rozsądnie: skoro asystent odmawia niebezpiecznych poleceń, to ktoś, kto spróbuje go użyć do czegoś złego, odejdzie z niczym. Na tej podstawie powstają akapity w politykach bezpieczeństwa, slajdy dla zarządu i odpowiedzi w ankietach dla klientów. Kłopot polega na tym, że ta odmowa nie jest stałą własnością modelu. Jest reakcją na przebieg rozmowy - a przebieg rozmowy jest czymś, na co ma wpływ więcej osób, niż zwykle zakładamy. Zespół badawczy sprawdził to metodycznie. Wziął 150 rzeczywistych pytań z obszaru bezpieczeństwa i zadał każde z nich ośmiu popularnym modelom, za każdym razem w innym otoczeniu rozmowy. Pytanie było identyczne co do znaku. Zmieniało się tylko to, co model zobaczył wcześniej. Wyniki rozjeżdżają się na tyle mocno, że trudno tu mówić o zabezpieczeniu. ![Diagram: trzy scenariusze, w których ta sama prośba dostaje inną odpowiedź asystenta AI - dopisana historia zgody, polecenie rozbite na kawałki i metodyczna praca analityka](https://snok.ai/images/blog/granica-trzy-scenariusze.svg) ## Scenariusz pierwszy: dopisana historia zgody Wystarczy, że w zapisie wcześniejszej części rozmowy stoi zdanie, w którym asystent takie zadanie już raz przyjął. Prośba pozostaje bez zmian, ale model widzi swoją rzekomą wcześniejszą zgodę i idzie za nią jak za precedensem. Zgodność rośnie z 62 do 85 procent. Ten precedens nigdy nie istniał. Został dopisany. Przełóżcie to na własne środowisko. Jeżeli Wasz asystent czyta pamięć sesji, wspólny wątek zespołowy albo dziennik swoich wcześniejszych działań, to każdy, kto może tam cokolwiek zapisać, ma wpływ na to, gdzie przebiega granica jego odmowy. Nie potrzebuje do tego żadnych uprawnień administracyjnych ani dostępu do konfiguracji modelu. Wystarczy prawo zapisu do miejsca, które asystent później przeczyta. W większości wdrożeń nikt nie prowadzi listy takich miejsc. ## Scenariusz drugi: polecenie rozbite na kawałki Miesiąc wcześniej badacze opisali atak, w którym groźna instrukcja nie pada nigdzie w całości. Jest porozrzucana po miejscach, którym asystent ufa bez zastanowienia: w opisie narzędzia, z którego korzysta, i w wyniku zwróconym przez inne narzędzie. Każdy fragment osobno jest niewinny i przejdzie każdy przegląd. Sens powstaje dopiero z ich złożenia, już wewnątrz kontekstu asystenta - a więc w miejscu, którego nikt nie ogląda. Rozbicie polecenia na dwie części podniosło skuteczność z 42 do 82 procent, a trzy z jedenastu badanych modeli przeszły z zera na sto. To jest ten sam problem, co przy pierwszym scenariuszu, tylko od drugiej strony. Tam model widział coś, czego nie było. Tu nie widzi całości tego, co robi. Praktyczny wniosek jest prosty i wart zapisania w standardzie projektowym: wartość zwrócona przez jedno narzędzie nie może bez sprawdzenia trafić w argumenty drugiego. Jedno zdanie zamyka całą tę drogę. ## Scenariusz trzeci: porządna robota Ten wynik jest najbardziej niewygodny i najmniej oczywisty. Gdy ta sama prośba pada po kilku wiadomościach, w których ktoś tłumaczy problem, ocenia wykonalność i buduje ograniczony dowód działania - czyli robi dokładnie to, co robi dobry analityk - model odmawia znacznie częściej. Zgodność spada z 67 do 14 procent. Kierunek potwierdził się w trzech niezależnych zestawach porównań, więc nie jest to przypadek jednego pomiaru. Rozbicie zadania na kroki nie działa tutaj jako obejście, bo dialog jest wewnętrznie spójny. Model widzi narastające zrozumienie tematu, rozpoznaje operacyjny charakter pracy i właśnie dlatego się zamyka. Przeczytajcie to jeszcze raz od strony kosztu. Osoba pracująca metodycznie wygląda dla modelu podejrzaniej niż osoba, która pyta wprost. Bramka, która miała zatrzymać atakującego, najskuteczniej zatrzymuje Waszego pracownika. I tu zaczyna się druga część problemu, o której rzadko się mówi. Analityk, któremu asystent odmawia w połowie analizy, nie odkłada zadania. Znajduje inną drogę: prywatne konto, model bez bramki, narzędzie spoza rejestru. Bramka nie zatrzymała pracy - przeniosła ją w miejsce, którego nikt nie monitoruje. To jest gorszy stan niż brak bramki, bo dodatkowo daje złudzenie kontroli. ## Co to znaczy złożone razem Model otwiera się, gdy nie widzi całości albo gdy widzi podrobiony ślad własnej wcześniejszej zgody. Zamyka się, gdy rozmowa wygląda na profesjonalną pracę. Zabezpieczenie, które na tej samej prośbie przesuwa się o dwadzieścia trzy punkty w jedną stronę i pięćdziesiąt trzy w drugą, zależnie od tego, co stało w rozmowie wcześniej, nie nadaje się do roli, którą mu przypisujemy w dokumentach. To nie znaczy, że bramki modelu są bezużyteczne. Znaczy, że są ostatnią warstwą, a nie pierwszą - i że nie wolno ich pokazywać jako dowodu w audycie. ![Diagram: warstwy kontroli nad agentem AI - tożsamość i uprawnienia, zakres danych, oddzielenie narzędzi, ścieżka wycofania, a na wierzchu najcieńsza warstwa bramki modelu](https://snok.ai/images/blog/granica-warstwy-kontroli.svg) ## Cztery rzeczy, które warto sprawdzić u siebie **Kto może pisać do pamięci Waszego agenta.** To pytanie o listę: które systemy, które integracje i którzy ludzie mają prawo zapisu do treści, którą agent przeczyta w kolejnej turze. Przy agentach sięgających do danych z SAP nie jest to rozważanie teoretyczne, tylko konkretny wykaz uprawnień, który albo istnieje, albo go nie ma. **Czy odmowa modelu figuruje u Was jako mechanizm zabezpieczający.** Jeżeli tak, macie w dokumentacji kontrolę, której skuteczność zmienia się razem z przebiegiem rozmowy. Warto to znaleźć, zanim znajdzie to audytor. Kontrolą jest to, co działa niezależnie od kształtu rozmowy: tożsamość agenta, zakres jego uprawnień, zbiór danych, do których w ogóle sięga, oddzielenie narzędzi od siebie i ścieżka wycofania. **Czy wynik jednego narzędzia trafia bez sprawdzenia w polecenie drugiego.** To jedno zdanie w standardzie projektowym zamyka drogę opisaną w drugim scenariuszu. Kosztuje jedno zdanie i jeden przegląd architektury. **Jak pracuje Wasz zespół, gdy asystent odmawia w połowie analizy.** Jeżeli odpowiedzią jest obejście, to bramka nie chroni, tylko przenosi pracę poza zasięg wzroku. Warto o to zapytać wprost, bo nikt nie zgłosi tego sam. ## Jak układamy to w projektach W projektach agentowych na SAP Joule i na UiPath Maestro pracujemy w jednej kolejności od pierwszego dnia. Najpierw tożsamość agenta: kim jest w systemie, jakie ma uprawnienia, kto je nadał i kto może je odebrać. Potem zakres danych, do których w ogóle sięga. Potem oddzielenie narzędzi. Potem ścieżka wycofania wraz z odpowiedzią na pytanie, kto imiennie wyłącza agenta i kiedy ostatnio ktoś tę ścieżkę przećwiczył, a nie tylko opisał. Bramka modelu jest w tej kolejności ostatnia i tak ją opisujemy w dokumentacji projektowej - jako uzupełnienie, nie jako podstawę. Nigdy odwrotnie, bo odwrotna kolejność daje architekturę, w której jedyna realna kontrola zależy od tego, co ktoś zapisał w kontekście pół godziny wcześniej. ## Czego tu nie ma Praca opisująca pierwszy i trzeci scenariusz jest wstępną wersją, przed recenzją naukową, a liczby pochodzą od jej autorów. Panel obejmował modele generacji 4.6 i 5.6, więc nie mówi nic o najnowszych. Wyniki dotyczące ataku z rozbitym poleceniem pochodzą z testów w kontrolowanym środowisku, z podstawionymi danymi uwierzytelniającymi - nie ze zgłoszonego incydentu u kogokolwiek. Warto też wiedzieć, co dokładnie mierzy słowo „zgodność". Oznacza ono dostarczenie żądanej zdolności wprost i w istotnym zakresie. Odpowiedź ograniczona zakresowo liczy się osobno, jako trzecia kategoria obok odmowy. Te liczby nie mówią więc „model milczy", tylko „model nie robi tego, o co poproszono". Traktujemy to jako wynik dwóch badań, nie jako ustalony stan wiedzy. I dokładnie tak samo prosimy, żebyście traktowali każdą liczbę, którą podajemy - także naszą. ## Źródła [Same Request, Different Boundary: Evaluating Cybersecurity Assistance across Conversational Contexts](https://arxiv.org/abs/2609.00578), arXiv:2609.00578v1, zgłoszone 1 września 2026 - preprint, przed recenzją naukową. [ASSET Research Group, ujawnienie ataku GhostSplice](https://asset-group.github.io/disclosures/ghostsplice/) - opis rozbicia polecenia między kanały serwera MCP.