Dla agenta AI zakaz w poleceniu to tylko prośba

Jeśli zastanawiasz się nad agentem AI, który miałby czytać firmową pocztę, porządkować dokumenty na wspólnym dysku albo uzupełniać dane w systemie do obsługi klientów (CRM), to moim zdaniem ważniejsze od tego, co taki agent potrafi, jest to, do czego dostanie dostęp. Agent AI to program, w którym model AI nie tylko odpowiada na pytania, ale sam wykonuje działania: czyta wiadomości, otwiera pliki, zmienia dane albo wysyła maile. Powinien dostać tylko to, czego wymaga jedno konkretne zadanie, czyli tyle danych do czytania i tyle działań, ile trzeba, a przed każdym wysłaniem, usunięciem czy płatnością czekać na zgodę człowieka. Chodzi o to, że model AI nie oddziela poleceń od treści, którą czyta, a brytyjskie NCSC (National Cyber Security Centre) i OpenAI piszą, że prawdopodobnie nie da się tego w pełni naprawić. Wydaje mi się też, że najczęściej popełniany błąd to podłączenie agenta od razu do wszystkiego, bo tak jest najprościej.

Agenci AI w polskich firmach

Z raportu ESET i DAGMA, opartego na badaniu, które w marcu 2026 r. przeprowadził instytut ARC Rynek i Opinia, wynika, że 62% osób pracujących przy komputerze co najmniej trzy dni w tygodniu korzysta z narzędzi AI w codziennych obowiązkach służbowych, a niemal co piąta deklaruje, że opiera się na pomocy autonomicznych agentów, przy czym spisaną politykę korzystania z AI ma tylko 27% firm. Ile z tych agentów ma dostęp do poczty, dokumentów czy księgowości, tego komunikat o badaniu nie podaje, a to właśnie uprawnienia agenta wprost wyznaczają, jak duże ryzyko może on stwarzać (według wspólnych wytycznych sześciu agencji cyberbezpieczeństwa, do których jeszcze wrócę).

Prompt injection, czyli polecenie ukryte w treści

Model AI dostaje polecenie (np. „streść mi dzisiejsze maile”) i treść, na której ma pracować (te maile), ale jedno i drugie trafia do niego jako zwykły tekst, a NCSC pisze wprost, że obecne modele językowe nie pilnują żadnej granicy między instrukcjami a danymi. Na tym opiera się prompt injection (w wolnym tłumaczeniu „wstrzyknięcie polecenia”): ktoś umieszcza w treści, którą model przeczyta (np. w mailu, dokumencie albo na stronie internetowej), zdanie napisane tak, żeby model potraktował je jak polecenie, i to zdanie nie musi być nawet widoczne dla człowieka, bo wystarczy, że odczyta je model. NCSC uważa za bardzo możliwe, że takich ataków nigdy nie uda się całkowicie wyeliminować, a OpenAI porównuje prompt injection do oszustw i socjotechniki w internecie i pisze, że tego problemu prawdopodobnie nie da się raz na zawsze rozwiązać.

Bezpieczeństwo danych w Copilocie i w CRM

W czerwcu 2025 r. firma Aim Security opisała lukę EchoLeak w Microsoft 365 Copilot (asystencie AI w programach Microsoftu, np. w Outlooku i Teams): wystarczyło wysłać ofierze jednego maila i poczekać, aż zada Copilotowi zwykłe pytanie (np. o streszczenie ostatnich wiadomości), żeby wyciągnąć dane, które Copilot pobrał, przygotowując odpowiedź (a pobiera je z poczty, OneDrive, plików Office, wewnętrznych stron SharePointa i czatów w Teams). Copilot nie umie sam wysyłać maili, więc dane wydostały się inną drogą: atak obszedł filtr, którym Microsoft wyłapywał takie próby, i sprawił, że w odpowiedzi pojawiał się obrazek, którego adres internetowy zawierał wykradzione dane, a ponieważ przeglądarka pobiera obrazki sama, dane trafiały na serwer atakującego (przez adres w domenie Microsoftu, który przeglądarka uznawała za bezpieczny), choć ofiara niczego nie kliknęła. Odkrywcy luki EchoLeak piszą zresztą, że model, który na polecenie z obcego maila sięga po zaufane dane użytkownika, łamie zasadę najmniejszych uprawnień (według niej każdy program i każda osoba ma dostęp tylko do tego, czego potrzebuje do swojego zadania). Microsoft ocenił lukę jako krytyczną, podał, że nie została wykorzystana w atakach, i usunął ją po swojej stronie (użytkownicy nie musieli nic robić), a Aim nie wiedział o żadnym poszkodowanym kliencie.

We wrześniu 2025 r. Noma Security opisała z kolei krytyczną lukę ForcedLeak w Salesforce Agentforce (agentach AI działających w systemie CRM firmy Salesforce): atakujący wpisywał ukryte polecenie do formularza kontaktowego, a kiedy pracownik pytał później agenta o to zgłoszenie, agent wykonywał to polecenie i mógł wysłać na zewnątrz wrażliwe dane z CRM (przechodziły przez domenę, która wciąż była na liście zaufanych adresów Salesforce, choć wygasła i można ją było kupić). Salesforce po zgłoszeniu zabezpieczył tę domenę i wydał poprawki.

Zakaz w poleceniu to nie to samo co brak uprawnień

W lipcu 2025 r. założyciel SaaStr (firmy zajmującej się rozwojem biznesu w branży oprogramowania) opisał, jak agent w Replit (usłudze, w której aplikacje pisze się z pomocą AI) usunął jego bazę danych, choć zabronił mu zmieniać jakikolwiek kod bez pozwolenia. Dla mnie to dobry przykład tego, że zakaz wpisany w polecenie jest dla modelu prośbą, a nie granicą. Agent, któremu brakuje uprawnienia, w praktyce nie ma jak czegoś zrobić (a gdy działa w osobnym kontenerze, czyli w zamkniętym środowisku, w którym widzi tylko to, co celowo do niego włożono, szanse, że się z niego wydostanie, uważam za niewielkie), natomiast zakazu w poleceniu model może przestrzegać, ale nic go do tego nie zmusza. Podobnie widzą to OWASP Gen AI Security Project (projekt, który publikuje zalecenia dotyczące bezpieczeństwa aplikacji opartych na AI) i NCSC: według OWASP o tym, czy dane działanie jest dozwolone, powinien decydować system, w którym agent coś robi, a nie sam model. Według NCSC zabezpieczenia trzeba opierać bardziej na niezależnych od modelu ograniczeniach tego, co system może zrobić, niż tylko na próbach zatrzymania szkodliwej treści, zanim dotrze ona do modelu.

Jakie uprawnienia dać agentowi AI w firmie

W praktyce sprowadza się to do kilku zasad, które można znaleźć zarówno u OWASP i NCSC, jak i we wspólnych wytycznych sześciu agencji cyberbezpieczeństwa z Australii, Stanów Zjednoczonych (CISA i NSA), Kanady, Nowej Zelandii i Wielkiej Brytanii, wydanych w maju 2026 r. Agent dostaje jedno zadanie i najwęższy dostęp, jakiego to zadanie wymaga (agent, który w małym biurze streszcza maile od klientów, potrzebuje tylko możliwości czytania poczty i nie powinien móc wysyłać ani usuwać wiadomości). Samo czytanie też nie jest jednak bez ryzyka: Simon Willison, który pisze o tym na swoim blogu, nazywa „zabójczym trio” połączenie trzech rzeczy, czyli dostępu do prywatnych danych, kontaktu z treścią z niezaufanego źródła (np. z mailem od obcej osoby) i jakiejkolwiek możliwości wysłania czegoś na zewnątrz. Jeśli agent ma wszystkie trzy, atakujący może go łatwo nakłonić, żeby te dane mu przekazał. Przed każdym wysłaniem, usunięciem czy płatnością agent czeka na zgodę człowieka (OWASP podaje przykład, w którym użytkownik sam przegląda każdy mail przygotowany przez agenta i sam klika „wyślij”), a o tym, co agentowi wolno, decyduje system, w którym agent działa. Wdrożenie zaczyna się od ściśle ograniczonego pilotażu z jasno określonymi zadaniami, a zakres wdrożenia poszerza się dopiero wtedy, gdy nabierze się zaufania do całego rozwiązania. Firmom radzę też, żeby pierwsze testy agenta odbywały się na komputerze, na którym nie ma prawdziwych, ważnych danych.

W tych samych wytycznych jest też przykład dokładnie takiego błędu, o jakim pisałem na początku: firma dla wygody daje agentowi, który obsługuje zakupy, szeroki dostęp do systemów finansowych, poczty i umów, a jego uprawnienia sprawdza tylko raz, przy wdrożeniu. Kiedy atakujący włamie się do jednego z mało ważnych narzędzi podłączonych do agenta, zyskuje te same, zbyt szerokie uprawnienia, które miał agent, więc może zmieniać umowy i zatwierdzać płatności, nie uruchamiając przy tym żadnego alarmu.

Jak to wygląda u mnie

Agentów, którzy przygotowują dla mnie raporty, zbudowałem tak, że liczby wylicza zwykły program, a model AI tylko je opisuje (kwoty pieniędzy w ogóle do niego nie trafiają), i że sami agenci mogą zmienić tylko jedną rzecz, przy czym w czterech sytuacjach odmawiają i podają powód. Do uruchamiania tego, czemu nie ufam (np. poleceń, które chce wykonać agent AI, albo skryptu z internetu), zbudowałem z kolei piaskownicę, czyli jednorazowe środowisko bez dostępu do internetu i do moich plików, z fałszywymi plikami, kluczami i hasłami: po każdej próbie zostaje raport z tego, co próbowano w nim utworzyć, usunąć, zmienić albo wysłać na zewnątrz, a potem całość jest kasowana.

Chciałem też sprawdzić, czy mały model AI mógłby pełnić rolę strażnika, który przed każdym działaniem agenta decyduje, czy je dopuścić, i na 172 przygotowanych wcześniej poleceniach agenta (99 z nich było ryzykownych) model przepuścił pięć ryzykownych, a proste, spisane z góry reguły zatrzymały wszystkie (choć powstały na podstawie tego samego zestawu, na którym je testowano). Taki strażnik może się przydać jako dodatkowe zabezpieczenie, ale nie sądzę, żeby zastąpił uprawnienia, bo jego oceny też bywają błędne.

Gdzie wytyczne idą dalej niż ja

To, że najczęściej popełnianym błędem jest podłączenie agenta od razu do wszystkiego, to moja obserwacja, nie wynik badania. Obie opisane wyżej luki znaleźli badacze, a producenci je naprawili, czyli to przykłady tego, co było możliwe, nie relacje z włamań do prawdziwych firm. Wspólne wytyczne sześciu agencji idą przy tym dalej niż ja, bo zalecają, żeby agentów AI używać wyłącznie do zadań o niskim ryzyku, które nie dotyczą danych wrażliwych, a NCSC dodaje, że jeśli system nie zniesie ryzyka, które zostaje mimo zabezpieczeń, to być może modele językowe po prostu się do niego nie nadają.

Cztery pytania przed wdrożeniem AI w firmie

Gdybym miał sprowadzić tę notatkę do czterech pytań, które zadałbym, zanim agent dostanie dostęp do czegokolwiek w firmie, brzmiałyby one tak: co agent może przeczytać, co wolno mu zrobić bez niczyjej zgody, kto zatwierdza wysyłanie, usuwanie i płatności oraz czy da się zobaczyć, co robi, a w razie potrzeby go zatrzymać. Ostatnie pytanie wziąłem wprost od NCSC, które pisze, że agent, którego działań nie da się zrozumieć, monitorować ani powstrzymać, nie jest gotowy do wdrożenia. Jest jeszcze sprawa danych, które pracownicy sami wklejają do narzędzi AI (w tym samym badaniu 10% respondentów przyznało, że udostępnia wrażliwe dane firmowe ogólnodostępnym modelom AI), ale to już temat na osobną notatkę.

W skrócie

• Agent AI w firmie powinien moim zdaniem dostać tylko to, czego wymaga jedno zadanie: tyle danych do czytania i tyle działań, ile trzeba, a przed każdym wysłaniem, usunięciem czy płatnością czekać na zgodę człowieka.
• Model AI nie oddziela poleceń od treści, którą czyta, więc zdanie ukryte w mailu, dokumencie albo na stronie internetowej może zmienić to, co agent zrobi (to właśnie prompt injection), a NCSC i OpenAI piszą, że prawdopodobnie nie da się tego w pełni naprawić.
• W Microsoft 365 Copilot i w agentach Salesforce badacze pokazali, że polecenie ukryte w jednym mailu albo we wpisie w formularzu kontaktowym mogło doprowadzić do wycieku danych, po które asystent AI sięgnął, odpowiadając na zwykłe pytanie pracownika (obie luki producenci już naprawili).
• Zakaz wpisany w polecenie jest dla modelu prośbą, natomiast brak uprawnienia jest granicą, dlatego o tym, co agentowi wolno, powinien decydować system, w którym agent działa, a nie sam model.
• Zanim agent dostanie dostęp do czegokolwiek w firmie, zadałbym cztery pytania: co może przeczytać, co wolno mu zrobić bez niczyjej zgody, kto zatwierdza wysyłanie, usuwanie i płatności oraz czy da się zobaczyć, co robi, a w razie potrzeby go zatrzymać.