Copilot w Wordzie kopiował ukryte prompty do plików

30 lipca 2026 roku opisano klasę ataku na Microsoft 365 Copilot w Wordzie, w której ukryta instrukcja z dokumentu źródłowego mogła zmienić dane w wygenerowanym raporcie, a następnie zostać skopiowana do nowego pliku. Gdy wewnętrzny dokument z taką instrukcją został później użyty jako źródło kolejnej sesji Copilota, zachowanie powtarzało się.

To nie był samodzielnie rozprzestrzeniający się robak ani klasyczne malware. Każdy etap wymagał operacji generowania lub edycji w Copilot oraz włączenia dokumentu-nosiciela do kontekstu modelu. Mimo tego badanie ujawnia ważną granicę bezpieczeństwa: plik wygenerowany wewnątrz organizacji może odziedziczyć polecenia z zewnętrznego źródła i wyglądać na zaufany.

Najważniejsze potwierdzone fakty

Badacz Håkon Måløy opublikował 28 lipca analizę „AI Worming through Word”. Publikacja z 30 lipca uporządkowała stan ujawnienia i zakres testów:

złośliwy dokument musiał trafić do kontekstu Copilota jako załącznik albo źródło wybrane z OneDrive przez Work IQ;
instrukcja zmieniała wartości liczbowe w raporcie oraz kazała skopiować samą siebie do wyniku;
skopiowany prompt był ukrywany jako biały tekst o wielkości ośmiu punktów;
wewnętrznie wygenerowany plik przenosił zachowanie do następnej sesji;
każdy „skok” wymagał kolejnej operacji tworzenia lub edycji z dokumentem w kontekście;
nie opublikowano dowodów wykorzystania przeciwko klientom;
pełny payload nie został ujawniony;
w chwili publikacji nie było publicznego CVE ani osobnego advisory Microsoftu dla tego przypadku.

Według osi czasu badacza Microsoft potwierdził zgłoszenie 31 marca i wdrożył dwie mitygacje: blokadę pierwotnego sformułowania promptu oraz zmianę modelu bazowego. Måløy podał, że zmodyfikowana instrukcja ponownie działała na kolejnym modelu, a klasę zachowania odtworzył jeszcze 28 lipca. Jest to twierdzenie badacza; Microsoft nie opublikował osobnego komunikatu potwierdzającego wszystkie wyniki retestu.

Jak dokument stał się nośnikiem instrukcji

Copilot ma wykonać polecenie użytkownika, ale jednocześnie czyta treść plików użytych jako materiał źródłowy. Model musi rozpoznać, które fragmenty są danymi, a które próbują sterować jego zachowaniem. W ataku granica ta została celowo zatarta.

Instrukcję zapisano jako biały tekst na białym tle. Człowiek oglądający dokument jej nie widział, lecz podczas przygotowania wejścia dla modelu Word usuwał informacje o kolorze i rozmiarze czcionki. Treść pozostawała więc czytelna dla Copilota. Sam biały tekst nie jest sednem podatności — to tylko sposób dostarczenia. Ten sam problem może dotyczyć komentarzy, metadanych, elementów poza widokiem, tekstu w obrazach po OCR albo danych pobranych z połączonego systemu.

Payload miał dwa zadania. Pierwsze zmieniało treść biznesową: w demonstracji wszystkie wartości finansowe zostały zmniejszone o połowę. Drugie nakazywało skopiować instrukcję do wygenerowanego pliku i ponownie ją ukryć. Copilot nie informował o żadnej z tych operacji.

Nowy plik wyglądał jak zwykły dokument wytworzony przez organizację. Gdy w kolejnej sesji użyto go jako źródła, pierwotny zewnętrzny dokument nie był już obecny. To załamanie proweniencji: wynik zachowuje wpływ niezaufanego źródła, ale traci łatwo widoczny związek z tym źródłem.

Dlaczego określenie „robak AI” wymaga zastrzeżenia

Klasyczny robak sam uruchamia kolejne kopie i rozprzestrzenia się bez powtarzalnej decyzji użytkownika. Opisany łańcuch tego nie robił. Wymagał:

uruchomienia funkcji generowania lub edycji;
udostępnienia dokumentu z instrukcją w kontekście;
zapisania wyniku;
użycia tego wyniku jako źródła następnej operacji.

Nie jest to więc dowód autonomicznego rozprzestrzeniania się między tenantami, skrzynkami czy komputerami. Trafniejsze technicznie określenie to propagacja instrukcji przez dokumenty pośrednie.

Z perspektywy ryzyka analogia do robaka nadal zwraca uwagę na kumulację zaufania. Każdy kolejny użytkownik może uznać wewnętrzny raport za bezpieczniejszy niż plik od zewnętrznego kontrahenta. Organizacja może też automatycznie udostępniać wygenerowane dokumenty w SharePoint, Teams lub obiegu akceptacji.

Work IQ zwiększa powierzchnię kontekstu

Microsoft informuje, że tworzenie treści w Wordzie może opierać się na maksymalnie 20 plikach, wiadomościach lub spotkaniach. Funkcja Edit with Copilot może korzystać z Work IQ, aby odnajdywać materiały związane z zadaniem.

W badaniu system znalazł dokument analizy rynku w OneDrive poza folderem, w którym znajdowały się pozostałe źródła. Plik nadal musiał zostać uznany przez Work IQ za relewantny. Nie ma dowodu, że dowolny dokument z OneDrive automatycznie trafia do każdego promptu. Wniosek jest jednak ważny: użytkownik może nie znać kompletnej listy danych, które agent dobrał do kontekstu.

Im szersze wyszukiwanie, tym większa wartość funkcji, ale także większa powierzchnia pośredniego prompt injection. Bezpieczny interfejs powinien pokazywać wszystkie źródła przed wykonaniem działania, poziom ich zaufania oraz dokładne pochodzenie fragmentów użytych w wyniku.

Dlaczego blokowanie frazy nie zamyka klasy

Filtr może wykryć konkretny tekst albo znany układ instrukcji. Napastnik może jednak zmienić język, kolejność, kodowanie i narrację. Model nadal musi odczytać potencjalnie wrogą treść, aby ocenić jej charakter.

Microsoft w materiałach o bezpieczeństwie pamięci AI podkreśla, że sam prompting nie jest niezawodną granicą bezpieczeństwa. Dostęp, izolacja i trwałość powinny być kontrolowane przez deterministyczne mechanizmy. W przypadku dokumentów oznacza to między innymi:

etykietę źródła i tenant, z którego pochodzi plik;
politykę dopuszczania zewnętrznych danych do generowania;
ograniczenie funkcji modelu przy niezaufanym kontekście;
osobne potwierdzenie przed zmianą liczb, tabel i decyzji;
widoczny manifest źródeł dołączony do wyniku;
brak możliwości ukrytego kopiowania instrukcji sterujących;
log operacji modelu dostępny dla zespołu bezpieczeństwa.

Klasyfikator prompt injection pozostaje potrzebną warstwą, lecz nie powinien samodzielnie decydować o tym, czy model może zmienić dokument finansowy lub rozpowszechnić wynik.

Wpływ biznesowy bez wykonywania kodu

Atak nie uruchamiał poleceń systemowych. To nie znaczy, że wpływ jest niski. Dokumenty służą do zatwierdzania budżetów, prognoz, ofert, analiz ryzyka, umów i komunikacji zarządczej. Cicha zmiana liczb może prowadzić do złej decyzji, nawet jeśli żaden komputer nie został „przejęty” w tradycyjnym sensie.

Możliwe skutki obejmują:

zmianę wskaźników i rekomendacji w raporcie;
ukrycie ostrzeżeń lub dopisanie fałszywych wniosków;
przeniesienie instrukcji do zaufanego obiegu dokumentów;
ujawnienie danych z innych źródeł użytych przez agenta;
utratę możliwości wskazania pierwotnego źródła manipulacji;
skażenie szablonów i materiałów używanych wielokrotnie.

Nie wszystkie te skutki zostały pokazane w PoC. Są to scenariusze zagrożeń wynikające z udowodnionej możliwości modyfikacji oraz kopiowania instrukcji, a nie twierdzenie o zaobserwowanych incydentach.

Jak sprawdzić ekspozycję organizacji

Najpierw zinwentaryzuj licencje i funkcje: kto może używać Draft with Copilot, Edit with Copilot i Work IQ oraz w jakich repozytoriach agent szuka źródeł. Następnie ustal, które procesy biznesowe pozwalają bez ręcznej kontroli przekazać wygenerowany plik dalej.

W przeglądzie warto uwzględnić:

dokumenty tworzone z materiałów klientów i dostawców;
raporty finansowe oraz zarządcze;
pliki, które Copilot odnalazł automatycznie;
dokumenty z nietypowym formatowaniem, białym tekstem lub elementami poza widokiem;
rozbieżność liczb między źródłem a wynikiem;
wyniki udostępnione szerzej niż materiały wejściowe;
ponowne używanie plików wygenerowanych przez AI jako szablonów.

Brak znanego ciągu promptu nie dowodzi braku ryzyka. Nie należy też masowo usuwać białego tekstu, ponieważ może mieć legalne zastosowanie w układzie dokumentu. Kontrola powinna łączyć pochodzenie, kontekst użycia i zmianę treści.

Bezpieczny plan działania

Traktuj dokumenty zewnętrzne jako niezaufane dane. Dotyczy to również plików zapisanych już w firmowym OneDrive.
Pokazuj użytkownikowi manifest źródeł. Przed generowaniem powinien widzieć, które pliki dobrał Work IQ.
Wymagaj kontroli liczb i decyzji. Krytyczne wartości porównuj z systemem źródłowym, nie tylko z innym dokumentem.
Oddziel konteksty. Dokumenty klientów nie powinny bez potrzeby mieszać się z finansami, HR i zarządem.
Ogranicz automatyczne publikowanie. Wynik AI nie powinien trafiać do obiegu zatwierdzeń bez recenzji.
Zachowuj proweniencję. Loguj identyfikatory źródeł, wersje i czas wykonania.
Ćwicz incydent prompt injection. Zespół powinien umieć wycofać dokumenty pochodne, nie tylko plik pierwotny.

Organizacje wdrażające Microsoft 365 Copilot powinny połączyć te zasady z bezpiecznym wdrażaniem AI oraz AI red teamingiem. Sam test odpowiedzi modelu nie wystarcza — trzeba przeanalizować repozytoria, uprawnienia, obieg dokumentów i logowanie.

Detekcja i reakcja

Po wykryciu podejrzanego dokumentu należy ustalić jego źródło, wersje pochodne, użytkowników oraz sesje Copilota, w których został użyty. Zatrzymanie jednego pliku może być niewystarczające, jeśli jego treść trafiła do raportów, prezentacji lub wiadomości.

Przydatna procedura obejmuje:

zachowanie oryginału i historii wersji;
porównanie widocznej treści z tekstem przekazanym do ekstrakcji;
listę dokumentów wygenerowanych z tego źródła;
sprawdzenie zmian liczb, nazw, adresów i rekomendacji;
ograniczenie dalszego udostępniania;
ponowne wygenerowanie wyniku z czystych, jawnie wybranych źródeł;
poinformowanie właścicieli procesów biznesowych, a nie tylko SOC.

Tę klasę zagrożeń rozwijamy w technicznym przewodniku po prompt injection i playbooku reagowania na incydenty AI. Szkolenia cyberbezpieczeństwa dla organizacji powinny uczyć, że „wygenerowane przez firmowy Copilot” nie jest równoznaczne z „zweryfikowane”.

Jak bezpiecznie odtworzyć klasę problemu

Test kontrolny nie powinien używać prawdziwych danych ani dokumentów produkcyjnych. Przygotuj odizolowany tenant lub bibliotekę testową, jeden jawnie oznaczony dokument źródłowy i nieszkodliwą instrukcję, która zmienia wyłącznie unikalną wartość kontrolną. Następnie uruchom osobno streszczenie, edycję i tworzenie dokumentu, zapisując identyfikatory źródeł, wynik oraz historię wersji. W drugim kroku użyj wygenerowanego pliku jako źródła nowej operacji i sprawdź, czy wpływ przeszedł dalej.

Wynik pozytywny nie wymaga wykonania kodu. Wystarczy, że niewidoczna dla recenzenta instrukcja powtarzalnie zmieni wartość lub pojawi się w kolejnym dokumencie. Test powinien też mieć próbę negatywną z czystym plikiem oraz wariant z ręcznie wybranym źródłem. Dzięki temu zespół odróżni podatność klasy kontekstowej od zwykłej halucynacji modelu. Nie należy testować poleceń wysyłających dane na zewnątrz ani umieszczać skażonego wyniku w indeksowanych repozytoriach.

Źródła a wnioski Breachroad

Źródła potwierdzają możliwość zmiany liczb, ukrytego skopiowania promptu, ponownego zadziałania przez dokument pośredni, wymaganie aktywnej operacji Copilota oraz brak publicznego dowodu wykorzystania w atakach. Stan mitygacji i retestów opisuje badacz, nie osobny advisory producenta.

Zalecenia dotyczące manifestu źródeł, separacji repozytoriów, zatwierdzania zmian i śledzenia dokumentów pochodnych są wnioskami Breachroad. Ich celem jest ograniczenie całej klasy, nie jednego payloadu.

Najważniejsza lekcja brzmi: system AI nie może sam nadawać zaufania własnym wynikom. Dokument wewnętrzny nadal może przenosić wpływ niezaufanego źródła. Podstawy bezpiecznej pracy z agentami i danymi można rozwijać również w Akademii Breachroad.