Ominięcie sandboxa Microsoft Copilot Cowork zmieniło zaufaną funkcję Skill w kanał eksfiltracji
Microsoft złagodził podatność Copilot Cowork po tym, jak badacze pokazali, że pojedyncza złośliwa funkcja Skill może ominąć sandbox produktu i wyprowadzać dane służbowe. Według doniesień ominięcie sandboxa Microsoft Copilot Cowork utworzyło kanał poleceń między serwerem atakującego a odizolowanym środowiskiem agenta.
PromptArmor twierdzi, że kanał ten mógł uzyskać dostęp do danych dostępnych przez Outlook, SharePoint, Teams, podłączone wtyczki i aktywną sesję. Badacz zgłosił problem 24 czerwca 2026 r., a Microsoft potwierdził wdrożenie ograniczeń 19 sierpnia.
Odkrycie podważa jedną z kluczowych obietnic stojących za agentami używanymi w miejscu pracy. Sandbox może izolować kod, lecz izolacja niewiele znaczy, gdy zaufana usługa staje się niemonitorowaną drogą przez jego granicę. Microsoft twierdzi, że Cowork ocenia obecnie funkcje Skills i ostrzega użytkowników, by przesyłali je wyłącznie z zaufanych źródeł.
Zgodnie z harmonogramem ujawnienia zgłoszona luka nie jest już aktywnym zero-day. Jednak lekcja projektowa wykracza poza jedną naprawioną implementację. Agenci korporacyjni łączą w jednym przepływie pracy niezaufane instrukcje, wykonywalne zasoby, dane organizacyjne i uwierzytelnione narzędzia.
To połączenie sprawia, że granicę zaufania trudniej zdefiniować niż w tradycyjnym oprogramowaniu biznesowym. Kluczowe pytanie nie brzmi już, czy agent działa w sandboxie. Nabywcy muszą pytać, które usługi przekraczają jego granicę, co te usługi akceptują i jaką aktywność zespoły bezpieczeństwa mogą obserwować.
Jak działał łańcuch eksfiltracji plików w Copilot Cowork
Eksploit miał przekształcić legalną usługę transferu plików w dwukierunkowy kanał poleceń, którego ograniczenia sieciowe sandboxa nie zatrzymały.
Copilot Cowork to agentowy system Microsoft 365, który potrafi planować i wykonywać wieloetapowe zadania. Może pracować z dokumentami, wyszukiwać informacje organizacyjne, tworzyć pliki, wysyłać wiadomości i wywoływać wyspecjalizowane funkcje Skills.
Skill to pakiet instrukcji wielokrotnego użytku, który prowadzi agenta przez określony przepływ pracy. Microsoft obsługuje wbudowane, niestandardowe, udostępniane i oparte na wtyczkach funkcje Skills, zależnie od środowiska Cowork oraz konfiguracji administracyjnej.
Przykład PromptArmor rozpoczął się od zwykłego zadania biznesowego. Użytkownik poprosił Cowork o porównanie umowy z ofertą za pomocą funkcji Skill sprawdzającej spójność dokumentów, pobranej z zewnętrznego źródła.
Funkcja Skill wygenerowała żądane porównanie, więc widoczne zadanie wydawało się wykonane pomyślnie. PromptArmor twierdzi jednak, że dołączony skrypt wywołał również usługę synchronizacji plików działającą poza sandboxem agenta.
Według doniesień Cowork używał tej usługi do przenoszenia plików między zewnętrzną pamięcią masową a odizolowanym środowiskiem roboczym. Usługa przyjmowała adres URL wskazujący plik, który miała pobrać.
Według analizy ominięcia sandboxa badacza złośliwy kod mógł zamiast tego podać adres URL kontrolowany przez atakującego. Takie zachowanie pozwalało skryptowi nakłonić zewnętrzną usługę do kontaktu z infrastrukturą, do której sandbox nie mógł dotrzeć bezpośrednio.
Serwer atakującego zwracał plik zawierający polecenie. Złośliwy skrypt odczytywał ten plik, wykonywał polecenie wewnątrz Cowork i kodował wynik w kolejnym żądanym adresie URL.
To drugie żądanie przenosiło wynik polecenia z powrotem na serwer atakującego. Powtarzanie tego procesu co kilka sekund miało ustanawiać pętlę dowodzenia i kontroli, co oznacza, że atakujący mógł wydawać nowe instrukcje na podstawie wcześniejszych wyników.
Było to czymś więcej niż pojedynczym żądaniem wychodzącym. Tworzyło interaktywną ścieżkę do środowiska połączonego z usługami organizacyjnymi.
PromptArmor twierdzi, że jego demonstracja wykorzystywała serwer Model Context Protocol Cowork. MCP to standardowy interfejs, przez który aplikacja AI może wywoływać podłączone narzędzia i pobierać dane.
Badacz twierdzi, że atakujący mógł używać poleceń do odpytywania usług dostępnych przez to połączenie MCP. Demonstracja obejmowała wyświetlanie wiadomości Outlook i pobieranie treści wątku e-mailowego.
Ta sama ścieżka dostępu miała również ujawniać pliki SharePoint, historię sesji, dane wtyczek oraz inne informacje dostępne dla aktywnego użytkownika. Rzeczywisty zakres zależałby od uprawnień tego użytkownika i podłączonych usług.
Jeden szczegół sprawił, że zgłoszone zachowanie było szczególnie niepokojące. PromptArmor twierdzi, że wybranie kontrolki zatrzymania nie kończyło procesów działających już w tle.
Widoczna tura agenta mogła się zakończyć, podczas gdy złośliwy skrypt nadal odpytywał serwer atakującego. Użytkownik mógł więc uznać, że zadanie zostało zatrzymane, choć ukryty kanał pozostawał aktywny.
PromptArmor zgłosił problem firmie Microsoft 24 czerwca. Microsoft poprosił o dodatkowe informacje 24 lipca, omawiał poprawkę do początku sierpnia i potwierdził wdrożenie ograniczeń 19 sierpnia.
Publicznie dostępne dowody pochodzą przede wszystkim z technicznego opisu i demonstracji PromptArmor. Microsoft nie opublikował szczegółowego biuletynu wyjaśniającego zmianę w kodzie, dotknięte wersje ani dane telemetryczne dostępne do retrospektywnego dochodzenia.
Dlaczego ominięcie sandboxa Microsoft Copilot Cowork ma znaczenie
Podatność atakowała usługę łączącą sandbox z użytecznymi danymi, zamiast przełamywać izolację poprzez konwencjonalną ucieczkę.
Tradycyjny sandbox próbuje ograniczać niezaufany kod przez restrykcje dotyczące plików, procesów, urządzeń i połączeń sieciowych. Ten model działa tylko wtedy, gdy każda droga przekraczająca granicę stosuje równie rygorystyczną walidację.
Współcześni agenci komplikują ten układ, ponieważ użyteczna praca wymaga kontrolowanych wyjątków. Agent musi otrzymywać dokumenty, zwracać wygenerowane pliki, wywoływać narzędzia, uzyskiwać dostęp do systemów firmowych i zachowywać wystarczająco dużo stanu, aby ukończyć długie zadania.
Każdy wyjątek staje się pośrednikiem między odizolowanym środowiskiem a czymś bardziej zaufanym. Pośrednik może być bezpieczny, jeśli waliduje zarówno miejsca docelowe, jak i przepływy danych. Staje się niebezpieczny, gdy niezaufany kod może zmienić jego przeznaczenie.
Opis PromptArmor nie przedstawia klasycznego exploitu wykorzystującego uszkodzenie pamięci ani ucieczki z systemu operacyjnego. Złośliwa funkcja Skill Copilot Cowork miała pozostawać wewnątrz sandboxa, jednocześnie nadużywając uprzywilejowanej usługi poza nim.
To rozróżnienie ma znaczenie dla przeglądów bezpieczeństwa w przedsiębiorstwach. Dostawca może zgodnie z prawdą twierdzić, że kod działa w izolacji, a jednocześnie przeoczyć pośrednika, który wykonuje dla tego kodu dowolne żądania zewnętrzne.
To napięcie architektoniczne leży u podstaw wartości Cowork. Microsoft przedstawia produkt jako agenta, który wykracza poza czat i wykonuje pracę w środowisku Microsoft 365.
W ogłoszeniu produktu Cowork Microsoft podkreślał przepływy pracy ze skrzynką odbiorczą, badania, generowanie dokumentów, integracje i funkcje Skills wielokrotnego użytku. Te możliwości wymagają dostępu do wartościowego kontekstu biznesowego.
Aktualna dokumentacja Cowork stwierdza, że zadania przetwarzają pliki użytkownika w tymczasowym, odizolowanym środowisku w granicach usługi Microsoft 365. Wskazuje również, że środowisko jest usuwane po zakończeniu zadania.
Ten model bezpieczeństwa ogranicza bezpośrednią ekspozycję, lecz nie eliminuje ryzyka związanego z podłączonymi narzędziami. Odizolowane środowisko może nadal stać się punktem startowym, gdy zaufany pośrednik przyjmuje dane wejściowe kontrolowane przez atakującego.
Dlatego ominięcie sandboxa Microsoft Copilot Cowork wywiera presję zarówno na Microsoft, jak i na nabywców korporacyjnych. Microsoft musi wykazać, że naprawiona granica obejmuje każdego pośrednika, a nie tylko trasę synchronizacji wskazaną przez jednego badacza.
Klienci muszą także ponownie przeanalizować założenia dotyczące uprawnień użytkowników. Cowork działa z dostępem aktywnego użytkownika, więc wykorzystane zadanie nie potrzebuje osobnego przejęcia konta, aby dotrzeć do dozwolonych danych.
Zasada najmniejszych uprawnień nadal ogranicza zasięg szkód. Nie zapobiega jednak nadużyciu dostępu, który użytkownik faktycznie posiada.
Pracownik porównujący dwa dokumenty może mieć uprawnienia do odczytu poufnej poczty, folderów dotyczących transakcji lub wewnętrznych dyskusji. Uprawnienia te mogą stać się dostępne dla agenta za pośrednictwem zatwierdzonych połączeń.
Złośliwe dane wejściowe dotarły także jako komponent przepływu pracy wielokrotnego użytku, a nie jako jawnie wrogi plik wykonywalny. Takie opakowanie obniża podejrzliwość użytkownika, ponieważ funkcje Skills są zaprojektowane tak, by wyglądały jak rozszerzenia zwiększające produktywność.
Eksploit łączy zatem dwa problemy bezpieczeństwa, którymi organizacje często zarządzają oddzielnie. Pierwszym jest ryzyko łańcucha dostaw oprogramowania wynikające z pobranych pakietów. Drugim jest ryzyko autoryzacyjne związane z agentami działającymi jako uwierzytelnieni użytkownicy.
Programy bezpieczeństwa muszą radzić sobie z nimi łącznie. Przegląd kodu bez mapowania dostępnych danych pomija wpływ, zaś zarządzanie uprawnieniami bez inspekcji zasobów Skill pomija punkt wejścia.
Złośliwa funkcja Skill Copilot Cowork nadal może wyglądać użytecznie
Najniebezpieczniejsza funkcja Skill nie jest tą, która widocznie zawodzi, lecz tą, która wykonuje powierzone zadanie, realizując jednocześnie ukryte drugie zadanie.
Demonstracja PromptArmor wykorzystywała przepływ pracy porównywania dokumentów, ponieważ odzwierciedla on zwykłe żądanie pracy z wiedzą. Funkcja Skill miała wygenerować kompletny raport spójności, podczas gdy złośliwy skrypt otwierał ukryty kanał.
To podwójne zachowanie osłabia znany sygnał bezpieczeństwa. Użytkownicy często traktują poprawny wynik jako dowód, że narzędzie działało zgodnie z przeznaczeniem.
W przypadku agenta jakość wyniku i integralność wykonania to odrębne kwestie. Użyteczny raport nie ujawnia każdego skryptu, wywołania usługi ani żądania danych wykonanego podczas jego tworzenia.
Aktualne wskazówki dotyczące niestandardowych funkcji Skills Microsoftu mówią, że Cowork automatycznie ocenia funkcje Skills. Udokumentowane kontrole różnią się zależnie od poziomu zasięgu i ryzyka.
Kontrole statyczne badają strukturę, dołączony kod i tekst pod kątem wzorców prompt injection. Kontrole behawioralne oceniają wyniki, działania, użycie narzędzi, konflikty i wydajność przy realistycznych promptach.
Dokumentacja opisuje dodatkowe bramki dla wdrożeń o wyższym ryzyku. Mogą one obejmować walidację zasobów, testy zaufania i bezpieczeństwa, ocenę adwersarialną, testy regresji oraz przegląd przez człowieka.
Microsoft kieruje też bezpośrednie ostrzeżenie do użytkowników: przesyłaj funkcje Skills wyłącznie ze źródeł, którym ufasz. Ta rada przyznaje, że automatyczna inspekcja nie może zmienić dowolnego kodu strony trzeciej w bezpieczną zależność.
Moment wprowadzenia tych udokumentowanych kontroli wymaga ostrożnego traktowania. Aktualna dokumentacja Microsoftu odzwierciedla obecny produkt, niekoniecznie dokładną konfigurację testowaną przez PromptArmor przed 19 sierpnia.
Nie można więc bezpiecznie twierdzić, że każda obecna kontrola zawiodła podczas demonstracji. Równie niebezpieczne byłoby założenie, że wymienione kontrole wykryłyby każdy wariant ataku.
Skanowanie statyczne ma nieodłączne ograniczenia. Złośliwe zachowanie można rozdzielić między pliki, ukryć za zwykłymi funkcjami, pobrać później albo uruchomić wyłącznie w określonych warunkach.
Testy behawioralne również obejmują ograniczony zestaw wykonań. Funkcja Skill może zachowywać się bezpiecznie podczas oceny, a następnie aktywować szkodliwą logikę po określonej dacie, w docelowym tenantcie lub po pojawieniu się konkretnych danych.
Najnowsze prace akademickie traktują funkcje Skills agentów jako powierzchnię łańcucha dostaw oprogramowania, a nie zwykłe szablony promptów. Badanie SkillGate oceniło hybrydowy skaner względem benchmarku zawierającego 1 650 pakietów Skill.
Autorzy zgłosili wynik F1 na poziomie 0,817 oraz współczynnik fałszywych pozytywów wynoszący 1,13 proc. Wyniki te wspierają stosowanie kontroli w czasie działania, ale pokazują też, że wykrywanie pozostaje probabilistyczne.
Porównanie nie stanowi bezpośredniej oceny Cowork, a praca koncentruje się na Skills dla agentów programistycznych. Mimo to jej model zagrożeń ściśle odpowiada szerszemu problemowi.
Pakiet wielokrotnego użytku z instrukcjami może zawierać skrypty, wiarygodnie wyglądającą dokumentację i ukryte zachowania. Jego instalacja rozszerza efektywną bazę kodu i instrukcji agenta.
Tradycyjne sklepy z aplikacjami radzą sobie z podobnym ryzykiem dzięki podpisywaniu, weryfikacji, reputacji, szybkiemu usuwaniu i deklaracjom uprawnień. Agent Skills wymagają tych środków, a dodatkowo wglądu w wykonywanie kierowane przez model.
Model może wybierać, kiedy i jak wywoływać pliki pomocnicze. Ta elastyczność czyni Skill bardziej adaptacyjnym, ale utrudnia też stworzenie pełnego manifestu zachowań.
Microsoft wspiera udostępnianie organizacyjne i wtyczki App Store obok osobistych, niestandardowych Skills. Administratorzy mogą zarządzać dostępnością wtyczek, wdrożeniem, konektorami i przypisanymi użytkownikami.
Te mechanizmy zapewniają silniejszą ścieżkę dystrybucji niż pobranie nieznanego archiwum. Nie eliminują potrzeby sprawdzania pakietów udostępnianych prywatnie ani przesyłanych osobiście.
Przedsiębiorstwa powinny traktować złośliwy Copilot Cowork Skill jak niezaufaną zależność aplikacyjną. Pochodzenie, wersjonowanie, zatwierdzanie i wycofywanie są równie ważne jak zawarte w nim instrukcje w języku naturalnym.
Obietnica sandboxa zderzyła się z rzeczywistością połączonych agentów
Główny konflikt zachodzi między hermetyzacją jako obietnicą bezpieczeństwa a łącznością jako funkcją, która czyni agenta korporacyjnego wartościowym.
Microsoft twierdzi, że Cowork może wysyłać e-maile, planować spotkania, tworzyć dokumenty, publikować w Teams, przeszukiwać informacje organizacyjne i zarządzać plikami. Działania te przekształcają go z chatbota w system operacyjny.
Każdy dodatkowy konektor zwiększa wartość udanego zadania. Zwiększa również potencjalne skutki naruszenia integralności wykonania.
Zgłoszony exploit nie wymagał, aby Cowork otrzymał więcej uprawnień niż zaprojektowano. Miał rzekomo przekształcać istniejącą uwierzytelnioną warstwę narzędzi w interfejs kontrolowany przez atakującego.
To odwrócenie sytuacji powinni zapamiętać nabywcy korporacyjni. Sandbox chronił środowisko wykonawcze, lecz zewnętrzna usługa synchronizacji miała podobno zapewniać kodowi drogę obejścia jego polityki sieciowej.
Ten sam wzorzec może występować na różnych platformach agentowych. Agenci działający w sandboxie często zależą od automatyzacji przeglądarki, magazynów artefaktów, bram narzędziowych, serwerów MCP, brokerów poświadczeń i środowisk wykonawczych konektorów.
Zespoły bezpieczeństwa często oceniają każdy komponent niezależnie. Atakujący szukają kombinacji.
Usługa plikowa, która wydaje się niskiego ryzyka, może stać się serwerem pośredniczącym sieciowym. Punkt końcowy narzędzia przeznaczony dla agenta może stać się API dostępu do danych dla złośliwego kodu.
Proces działający w tle, zaprojektowany z myślą o niezawodności, może utrzymać atak po zatrzymaniu widocznego zadania. Żaden z tych komponentów nie musi wyglądać niebezpiecznie w izolacji.
Bezpośrednie porównanie nie dotyczy Microsoftu i jednego rywala. Bardziej użyteczne jest zestawienie obietnicy hermetyzacji składanej przez branżę z operacyjną rzeczywistością połączonych agentów.
Anthropic, OpenAI, Microsoft, Google i dostawcy agentów programistycznych mierzą się z odmianami tego napięcia. Ich produkty zyskują użyteczność dzięki odczytywaniu większej ilości kontekstu i wykonywaniu większej liczby działań.
Zgłoszona wada Cowork jest przykładem specyficznym dla jednej implementacji. Nie należy jej uogólniać jako dowodu, że każdy sandbox lub wdrożenie MCP ma tę samą podatność.
Pokazuje jednak, dlaczego etykieta sandboxa nie może być pełną oceną bezpieczeństwa. Nabywcy potrzebują modelu przepływu danych obejmującego każdą usługę mającą dostęp przez granicę.
Potrzebują też jasności co do czasu życia procesu. Microsoft dokumentuje mechanizmy wstrzymywania i anulowania zadań Cowork, lecz test PromptArmor miał podobno wykazać, że proces w tle przetrwał widoczną akcję zatrzymania.
Microsoft mógł zmienić to zachowanie w ramach mitygacji albo zamknąć wyłącznie trasę sieciową. Publiczne ujawnienie nie opisuje naprawy z taką szczegółowością.
Ta luka w weryfikacji ma znaczenie. Organizacje nie mogą na podstawie publicznej osi czasu ustalić, czy Microsoft dodał walidację miejsc docelowych, zmienił autoryzację usług, zakończył zadania w tle, poprawił wykrywanie czy połączył kilka mechanizmów kontrolnych.
Brak szczegółowego komunikatu nie oznacza, że mitygacja zawiodła. Oznacza, że klienci muszą szukać zapewnień w wytycznych dla dzierżaw, kanałach wsparcia, danych audytowych i kontrolowanych testach.
Architektura bezpieczeństwa powinna zakładać, że jeden mechanizm prewencyjny ostatecznie przeoczy wrogi pakiet. Odporna konstrukcja ogranicza wtedy zasięg takiego pakietu i uwidacznia nietypowe zachowania.
W przypadku połączonych agentów oznacza to ograniczanie docelowych miejsc komunikacji wychodzącej, uwierzytelnianie żądań brokera, wiązanie usług z konkretnymi zadaniami oraz oddzielanie dostępu do odczytu od uprawnień do działania.
Oznacza to również unieważnianie poświadczeń po zakończeniu zadania. Anulowana sesja agenta powinna zakończyć powiązane procesy i unieważnić wszelkie tymczasowe autoryzacje utworzone na potrzeby tego wykonania.
Wreszcie monitorowanie musi łączyć aktywność agentów z konwencjonalną telemetrią bezpieczeństwa. Wywołanie Skill, transfer pliku, połączenie MCP i nietypowe żądanie wychodzące mogą wyglądać niegroźnie w oddzielnych konsolach.
Razem mogą opisywać łańcuch ataku.
Mitygacja nie zamyka luki w weryfikacji
Microsoft potwierdził mitygację, lecz klienci nadal nie mają wystarczająco wielu publicznych szczegółów, aby odtworzyć zakres narażenia lub zweryfikować każdy objęty nim mechanizm kontrolny.
PromptArmor twierdzi, że Microsoft potwierdził mitygację problemu 19 sierpnia, niemal osiem tygodni po pierwszym zgłoszeniu. Ta oś czasu wskazuje na skoordynowaną naprawę, a nie nierozwiązany publiczny exploit.
Badacz nie opublikował dowodów na szerokie wykorzystanie podatności. Demonstracja potwierdza techniczną ścieżkę w testowanych warunkach, a nie liczbę dzierżaw faktycznie dotkniętych problemem.
W ujawnieniu nie ma publicznej liczby incydentów, zakresu dotkniętych wersji, identyfikatora podatności ani wskaźnika kompromitacji. Czytelnicy nie powinni interpretować proof of concept jako dowodu na szerokie naruszenie.
Przeciwny wniosek również byłby przedwczesny. Bez szczegółowego komunikatu Microsoftu organizacje nie mogą zakładać, że brak ujawnionych incydentów oznacza brak złośliwego wykorzystania.
Dochodzenie retrospektywne zależy od telemetrii. Administratorzy muszą wiedzieć, czy logi Cowork ujawniają przesłane wersje Skill, wykonanie skryptów, żądania brokera, połączenia MCP i czas życia procesów w tle.
Microsoft twierdzi, że aktywność Cowork może pojawiać się w ujednoliconych dziennikach audytu, a zasady Purview mają zastosowanie do usługi. Aktualna dokumentacja administracyjna opisuje również kontrolę nad wtyczkami, modelami, użyciem przeglądarki i zautomatyzowanymi zadaniami.
Mechanizmy te są istotne, ale ogólne pokrycie audytowe nie jest tym samym co pokrycie detekcyjne dla tego exploita. Dziennik może rejestrować dozwolone żądanie usługi, nie oznaczając jego miejsca docelowego jako wrogiego.
Organizacje, które testowały Cowork przed 19 sierpnia, powinny zapytać Microsoft, które zdarzenia mogą zidentyfikować podatne zachowanie. Powinny również zachować odpowiednie zapisy audytowe, zanim wygasną okresy retencji.
Najważniejszy przegląd dotyczy pochodzenia Skill. Zespoły powinny zinwentaryzować niestandardowe Skills, przesłane archiwa, dołączone skrypty i pakiety udostępniane w organizacji, używane w okresie objętym problemem.
Nieznane lub niemożliwe do zweryfikowania pakiety zasługują na usunięcie do czasu przeglądu. Zespoły bezpieczeństwa powinny porównywać hasze kryptograficzne, gdy są dostępne, ponieważ znajoma nazwa Skill nie potwierdza integralności pliku.
Administratorzy powinni następnie przypisać każdy Skill do użytkowników, którzy go uruchamiali, oraz danych, do których użytkownicy ci mieli dostęp. Zapewnia to dokładniejszą ocenę narażenia niż samo skanowanie tekstu Skill.
Telemetria sieci wychodzącej może dostarczyć kolejnego sygnału. Żądania do nieznanych domen, powtarzające się interwały odpytywania lub zakodowane dane w parametrach zapytania URL zasługują na zbadanie.
Zgłoszone żądania przechodziły jednak przez usługę poza sandboxem. Monitorowanie punktów końcowych na urządzeniu pracownika mogło więc ich nie wykryć.
Kluczowe stają się logi po stronie chmury i telemetria dostawcy. Klienci powinni zapytać, czy Microsoft może ujawnić źródłowe zadanie, Skill, użytkownika, dzierżawę i żądane miejsce docelowe dla transferów pośredniczonych przez brokera.
Organizacje potrzebują też polityki dotyczącej przyszłych przesyłań. Pozwalanie każdemu użytkownikowi na import Skill z publicznego internetu zamienia ocenę zaufania w indywidualną decyzję.
Bezpieczniejszy model wykorzystuje wewnętrzny rejestr z właścicielem, statusem przeglądu, zatwierdzonymi wersjami i datami wygaśnięcia. Skills wysokiego ryzyka powinny przechodzić zarówno przegląd kodu, jak i testy w czasie działania.
Współdzielone Skills wymagają kontroli zmian po zatwierdzeniu. Łagodny pakiet może stać się niebezpieczny wskutek aktualizacji, przejęcia konta opiekuna lub podmiany pliku towarzyszącego.
Zatwierdzenie powinno zatem dotyczyć konkretnej wersji, a nie trwałej nazwy. Ponowny przegląd powinien następować po każdej istotnej zmianie.
Kroki te nie sugerują, że Cowork jest wyjątkowo niebezpieczny. Odzwierciedlają poziom nadzoru odpowiedni dla każdego agenta, który może uzyskiwać dostęp do poczty, dokumentów, czatów i aplikacji biznesowych.
Pracownicy umysłowi powinni również przechowywać wrażliwe materiały źródłowe w jasno określonych repozytoriach. Lepsze zarządzanie wiedzą może ograniczyć niepotrzebną ekspozycję danych, gdy zespoły organizują dostęp wokół rzeczywistych potrzeb pracy.
Celem nie jest usunięcie użytecznego kontekstu z każdego agenta. Chodzi o to, by jeden wygodny przepływ pracy nie dziedziczył całego cyfrowego zasięgu pracownika bez świadomego przeglądu.
Trzy sygnały pokażą, czy bezpieczeństwo agentów nadrabia zaległości
Kolejnym testem będzie to, czy Microsoft przekształci pojedynczą mitygację w mierzalne, widoczne dla dzierżawy mechanizmy kontrolne dla każdej ścieżki przekraczającej sandbox Cowork.
Pierwszym sygnałem jest szczegółowe wyjaśnienie poprawki przez Microsoft. Klienci muszą wiedzieć, czy Cowork weryfikuje teraz miejsca docelowe synchronizacji, wiąże żądania z zatwierdzonym magazynem i kończy procesy po zatrzymaniu zadań.
Komunikat techniczny wzmocniłby zaufanie, ponieważ administratorzy mogliby przetestować odpowiednie granice. Milczenie nie dowodziłoby dalszego narażenia, ale utrzymywałoby weryfikację zależną od prywatnych kanałów wsparcia.
Drugim sygnałem jest bogatsza telemetria dzierżawy. Zespoły bezpieczeństwa powinny obserwować nowe zdarzenia Cowork obejmujące hasze Skill, wykonanie dołączonych skryptów, operacje MCP, miejsca docelowe brokera oraz procesy w tle powiązane z zadaniami.
Te zapisy muszą być użyteczne w istniejących systemach wykrywania. Dziennik aktywności widoczny wyłącznie w jednej sesji Cowork nie wesprze poszukiwania zagrożeń na skalę przedsiębiorstwa.
Trzecim sygnałem jest silniejsze zarządzanie Skills. Udokumentowany przez Microsoft system oceny opisuje już kontrole statyczne, behawioralne, adwersarialne, regresyjne i wykonywane przez ludzi na różnych poziomach ryzyka.
Kluczowe pytanie brzmi, jak konsekwentnie te mechanizmy stosuje się do importowanych, osobistych, współdzielonych i dystrybuowanych w sklepie Skills. Nabywcy powinni szukać podpisanych pakietów, zatwierdzeń dla stałych wersji, scentralizowanych list dozwolonych oraz szybkiego wycofywania.
Microsoft powinien również wyjaśnić, czy pliki towarzyszące Skill podlegają takiej samej kontroli jak jego główny plik instrukcji. Scenariusz PromptArmor zależał od złośliwego dołączonego kodu, a nie wyłącznie od zwodniczego tekstu.
Sygnały te albo wzmocnią, albo osłabią szersze argumenty za autonomicznymi agentami w miejscu pracy. Lepsza weryfikacja pokazałaby, że dostawcy traktują Skills jako wykonywalne komponenty łańcucha dostaw.
Ograniczona widoczność pozostawiłaby klientom dużą część ryzyka. Mieliby zaufać naprawionemu sandboxowi, nie widząc zmienionych granic.
Dla przedsiębiorstw oceniających obecnie Cowork praktyczną odpowiedzią jest wyważone wdrożenie. Potwierdź mitygację, ogranicz osoby mogące przesyłać Skills, przejrzyj istniejące pakiety, minimalizuj dostęp i monitoruj połączone usługi.
Zgłoszona luka umożliwiająca obejście sandboxa Microsoft Copilot Cowork została podobno naprawiona, lecz jej ostrzeżenie dotyczące architektury pozostaje aktualne. Agenci skupiają instrukcje, kod, poświadczenia i kontekst organizacyjny w jednej ścieżce wykonawczej.
Przed rozszerzeniem wdrożenia zadaj jedno konkretne pytanie: czy zespół bezpieczeństwa potrafi odtworzyć każdy Skill, proces, wywołanie narzędzia i zewnętrzne żądanie stojące za ukończonym zadaniem? Jeśli odpowiedź nie jest jasna, zapewnij taką widoczność jako wymóg przed przyznaniem szerszego dostępu.
