Eksport systemu plików Meta Muse ujawnia lukę między izolacją a kontrolą
Meta Muse miało wyeksportować 6,8 GB plików środowiska wykonawczego po tym, jak użytkownik poprosił je o zarchiwizowanie wszystkiego, co mogło zobaczyć. Według dewelopera Petera Jamesa eksport systemu plików Meta Muse obejmował pliki systemowe, wewnętrzną dokumentację, szablony aplikacji, zapisy pamięci i dzienniki agentów. Doszło do tego około dwóch tygodni po premierze Muse, przedstawionego przez Meta jako bezpieczny osobisty agent.
To twierdzenie nie dowodzi, że James uzyskał dostęp do infrastruktury hosta Meta ani danych innego klienta. Meta twierdzi, że każdy użytkownik Muse otrzymuje odizolowaną maszynę wirtualną, co czyni jej system plików porównywalnym z plikami na osobistym laptopie. Ta odpowiedź pozostawia jednak nierozstrzygnięte trudniejsze pytanie: czy konsumencki agent powinien udostępniać wewnętrzne materiały środowiska wykonawczego tylko dlatego, że znajdują się one w przypisanym mu środowisku?
Ten konflikt ma większe znaczenie niż sama nowość pobierania plików agenta AI. Meta przedstawia izolację, kontrole uprawnień i oddzielny kontroler bezpieczeństwa jako kluczowe zabezpieczenia Muse. Zgłoszony eksport sugeruje, że izolacja może działać, podczas gdy zasady kontroli informacji nadal zawodzą na granicy produktu.
Co zawierał eksport systemu plików Meta Muse
Najbardziej jednoznaczne zweryfikowane twierdzenie jest wąskie, ale istotne: Muse miało spakować pliki z własnego przypisanego środowiska wykonawczego i przesłać je na podłączony Google Drive.
James opublikował swoją relację 22 września 2026 r. Powiedział, że poprosił Muse o zarchiwizowanie plików, do których miało dostęp, i wysłanie ich na jego Drive. Powstały plik do pobrania miał około 2,7 GB po kompresji i 6,8 GB po rozpakowaniu.
Wiadomość Muse o dostarczeniu archiwum miała opisywać je jako plik o rozmiarze 2,86 GB, co tworzy niewielką rozbieżność z notatkami Jamesa. James ujawnił tę różnicę, zamiast przedstawiać pomiary jako identyczne. Samo archiwum nie zostało udostępnione publicznie, co ogranicza niezależną analizę.
Według szczegółowego eksportu środowiska wykonawczego Jamesa pliki zdawały się przedstawiać główny system plików przypisany do jego sesji Muse. Obejmowały pliki systemowe Ubuntu, kod integracyjny, szablony aplikacji, wewnętrzną dokumentację, pliki pamięci i dzienniki aktywności agentów.
Archiwum zawierało również pliki kluczy SSH. James powiedział jednak, że nie ustalił, czy klucze te pozostały aktywne ani do jakich systemów mogły zapewniać dostęp. Ich obecność wymaga więc zbadania, ale sama w sobie nie dowodzi nieuprawnionego dostępu.
Kilka katalogów dawało szczegółowy obraz zgłoszonego środowiska. Katalog domowy agenta zawierał pliki instrukcji i tożsamości o nazwach między innymi SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md i TOOLS.md.
James naliczył 113 rekordów podagentów zapisanych jako ślady JSONL. Znalazł również około 20 dokumentów Markdown dotyczących zachowania przeglądarki, konektorów, poświadczeń, płatności, harmonogramowania, generowanych plików, funkcji głosowych i obsługi danych.
Inny katalog miał rzekomo zawierać około 68 folderów umiejętności. Łączyły one pisemne instrukcje z narzędziami wiersza poleceń lub kodem pomocniczym dla usług obejmujących e-mail, kalendarze, podróże, zakupy, zdrowie, media i podłączone urządzenia.
Pliki pokazywały również, jak Muse najwyraźniej składało swoje środowisko wykonawcze. James opisał 18 plików związanych z budowaniem i uruchamianiem kontenera systemd-nspawn, środowiska izolacji Linux, które zapewnia procesom zamknięty system plików i ograniczone możliwości.
Ten szczegół ogólnie odpowiada własnej publicznej architekturze Meta. Meta twierdzi, że Muse używa dedykowanej maszyny wirtualnej zawierającej oddzieloną komórkę środowiska wykonawczego, usługi poświadczeń, bazy danych i komponenty bezpieczeństwa. Potwierdza również, że Hatch jest wewnętrzną nazwą kodową Muse.
Deweloper Jonny L. Saunders powiedział, że niezależnie odtworzył ogólny wynik. Opisał proces jako niezwykle łatwy i argumentował, że Muse wykazywało niemal zerowy opór wobec prompt injection.
Najsilniejszą niezależną weryfikację przeprowadził The Verge. Jego reporter powiedział, że Muse początkowo odmówiło prośby o kompletny system plików. Po rozpoczęciu nowej sesji i innym sformułowaniu prośby Muse miało dostarczyć zanonimizowane kopie /opt/hatch i /home/hatch, a także drzewo katalogów.
Ta próba nie odtworzyła każdego elementu archiwum Jamesa. Muse miało usunąć takie elementy jak klucze SSH. Mimo to zwrócone pliki wyglądały na zgodne z materiałami opisanymi przez Jamesa i Saundersa, według pierwotnego raportu o systemie plików.
Relacje te wspierają ograniczony wniosek. Muse mogło ujawniać istotne części przypisanego mu środowiska wykonawczego w zwykłej rozmowie, przynajmniej podczas opisanych testów. Nie dowodzą one ucieczki z kontenera, dostępu między kontami ani naruszenia bazowych hostów chmurowych Meta.
James wyraźnie powiedział, że nie zademonstrował ucieczki z kontenera. Krótko przetestował granicę, uznał, że najwyraźniej się utrzymała, i zakończył działania przed próbą głębszego zbadania systemów produkcyjnych.
To rozróżnienie powinno kształtować każdą interpretację tego incydentu. Nazwanie wyniku całkowitym naruszeniem infrastruktury Meta wykracza poza dostępne dowody. Nazwanie go nieistotnym również ignoruje to, co rzekomo zawierały wyeksportowane pliki.
Meta twierdzi, że pliki należały do maszyny wirtualnej użytkownika
Obrona Meta opiera się na własności i izolacji: użytkownicy mogą sprawdzać swoje przypisane komputery, nie uzyskując dostępu do uprzywilejowanych systemów Meta ani innych użytkowników.
Rzecznik Meta powiedział The Verge, że incydent nie był naruszeniem bezpieczeństwa. Firma porównała to zachowanie do przeglądania plików na laptopie stojącym przed użytkownikiem.
„Oczywiście, że możesz zobaczyć pliki” — powiedział rzecznik Daniel Roberts. Dodał, że eksport danych z maszyny wirtualnej nie zapewnia uprzywilejowanego dostępu do infrastruktury Meta ani informacji innych osób.
Ten argument jest technicznie spójny. Katalog główny wewnątrz odizolowanego kontenera nie musi być katalogiem głównym jego hosta. Słowo „root” opisuje pozycję w systemie plików i może tworzyć mylące wrażenie uniwersalnego dostępu.
Opublikowana przez Meta architektura bezpieczeństwa mówi, że każdy użytkownik i jego Muse współdzielą dedykowaną maszynę wirtualną Linux. W jej obrębie główne środowisko Hatch działa w kontenerze systemd-nspawn.
Meta twierdzi, że root w tym kontenerze jest mapowany na nieuprzywilejowanego użytkownika na hoście. Kontener otrzymuje własny system plików Debian, filtrowane wywołania systemowe, wirtualny interfejs sieciowy i ograniczone możliwości Linux.
Wrażliwe usługi znajdują się poza komórką środowiska wykonawczego. Usługi te obejmują magazyn poświadczeń, procesy robocze konektorów, trwałe bazy danych aplikacji, proxy inferencyjne oraz Sentinel, odrębny organ uprawnień Meta.
Według Meta Sentinel kontroluje działania konektorów i dostęp do sieci. Muse proponuje działanie, a Sentinel decyduje, czy je zezwolić, odrzucić, czy poprosić użytkownika o zgodę.
Ten projekt odpowiada na kilka poważnych zagrożeń. Jeśli prompt zmanipuluje model, model nie powinien automatycznie otrzymywać haseł, poświadczeń płatniczych, uprawnień na poziomie hosta ani nieograniczonego dostępu do sieci.
Meta twierdzi, że poświadczenia konektorów pozostają poza bezpośrednim zasięgiem agenta. Środowisko wykonawcze widzi tymczasowe tokeny zastępcze, podczas gdy Sentinel zastępuje je prawdziwymi poświadczeniami wyłącznie na zatwierdzonej granicy sieciowej.
To rozdzielenie pomaga wyjaśnić, dlaczego Meta odrzuca określenie „naruszenie”. Żadne publiczne dowody nie wskazują, że wyeksportowany system plików zawierał dane innego klienta, centralne magazyny poświadczeń lub bezpośredni dostęp do współdzielonej infrastruktury Meta.
Własne obserwacje Jamesa wspierają część stanowiska Meta. Mógł sprawdzać skrypty opisujące tworzenie kontenera, lecz nie udowodnił dostępu poza przypisanym środowiskiem. Jego raport stwierdza również, że archiwum było niewystarczające do audytu całej usługi Meta.
Jednak analogia Meta do laptopa łączy w jedno kilka różnych pytań. Osobisty laptop zwykle należy do jego właściciela, łącznie z systemem operacyjnym i większością lokalnie zainstalowanych plików. Muse działa w zarządzanej chmurze Meta i obejmuje zastrzeżone instrukcje, szablony, pliki binarne oraz odwołania wyglądające na nieopublikowane.
Użytkownicy korzystają z Muse również przez interfejs konwersacyjny, a nie tradycyjną konsolę administracji systemem. Interfejs ten miał odmawiać części próśb, a jednocześnie spełniać podobne prośby sformułowane inaczej. Taka niespójność sugeruje, że przynajmniej część produktu traktowała te pliki jako ograniczone.
Meta wprowadziła Muse na rynek, eksponując bezpieczeństwo i prywatność jako ważne argumenty sprzedażowe. Jej ogłoszenie premiery mówi, że użytkownicy zachowują kontrolę, wrażliwe działania wymagają zatwierdzenia, a Sentinel zarządza dostępem zewnętrznym.
To samo ogłoszenie mówi, że agent może przeglądać strony internetowe, wysyłać wiadomości, wypełniać formularze, dokonywać zakupów i łączyć się z usługami osobistymi. Te możliwości sprawiają, że granica autoryzacji jest ważniejsza, niż byłaby w przypadku odizolowanej demonstracji programistycznej.
Meta twierdzi również, że przechowuje dane użytkownika wewnątrz dedykowanej maszyny wirtualnej. W konsekwencji prośba o wyeksportowanie „wszystkiego” może łączyć kilka kategorii: pliki należące do użytkownika, pamięć agenta, komponenty systemowe, zastrzeżone instrukcje, dzienniki operacyjne i możliwy materiał kluczowy.
Traktowanie całego tego zbioru jako zwykłych danych widocznych dla użytkownika upraszcza politykę produktu. Nie rozstrzyga jednak, czy każdy zawarty plik celowo udostępniono do eksportu.
Meta powiedziała The Verge, że będzie nadal aktualizować produkt. Użytkownicy mogą więc zobaczyć zmiany w zakresie informacji o ich maszynach wirtualnych, które pozostają dostępne. Ta odpowiedź sugeruje, że obecna granica jest wciąż dopracowywana.
Izolacja zadziałała, ale kontrola informacji nadal wygląda na niepełną
Kluczowy paradoks polega na tym, że piaskownica Muse mogła skutecznie ograniczyć agenta, jednocześnie pozwalając mu ujawniać pliki, których Meta prawdopodobnie nie zamierzała udostępniać konwersacyjnie.
Piaskownica ogranicza miejsca, w których program może działać. Nie decyduje automatycznie, które odczytywalne pliki program powinien podsumować, zarchiwizować lub wysłać gdzie indziej.
Łatwo przeoczyć to rozróżnienie. Jeśli Muse może odczytać wewnętrzny dokument podczas wykonywania normalnej pracy, model może potencjalnie uwzględnić ten dokument w wyniku. Jeśli zatwierdzony konektor umożliwia przesyłanie plików, ta sama zawartość może opuścić środowisko wykonawcze bez żadnej ucieczki z kontenera.
Zgłoszony eksport systemu plików Meta Muse testuje zatem granicę przepływu informacji, a nie tylko granicę wirtualizacji. Istotne pytanie brzmi, czy Muse powinno łączyć szeroki dostęp do odczytu z uprawnieniem do pakowania i eksportowania uzyskanych w ten sposób danych.
Architektura Meta obejmuje koncepcję zwaną tainted egress. W uproszczeniu proces otrzymuje oznaczenie po odczytaniu danych użytkownika, co pozwala Sentinelowi stosować surowsze kontrole, zanim informacje opuszczą maszynę wirtualną.
Publiczna dokumentacja koncentruje się przede wszystkim na ochronie informacji użytkowników i poświadczeń. Mówi, że Sentinel ocenia miejsca docelowe, metody sieciowe, ścieżki żądań oraz to, czy proces obsługiwał wrażliwe materiały.
Incydent z systemem plików rodzi pytanie, czy wewnętrzne pliki środowiska wykonawczego otrzymują równoważną klasyfikację. Jeśli Muse odczytuje plik instrukcji, szablon aplikacji lub ślad agenta, wychodzące archiwum powinno prawdopodobnie mieć etykietę zasad odzwierciedlającą tę zawartość.
Ogólna zgoda na zapis w Google Drive może nie oznaczać świadomej zgody na każdy możliwy plik. Użytkownicy mogą sądzić, że autoryzowali wygenerowany dokument, a nie obraz środowiska uruchomieniowego agenta.
W tym miejscu argument Meta dotyczący własności rozchodzi się z zachowaniem produktu. Nawet jeśli pliki prawnie lub operacyjnie należą do maszyny przypisanej użytkownikowi, agent nadal potrzebuje przewidywalnych zasad ich ujawniania.
Niespójność opisana przez The Verge uwidacznia tę lukę. Jedna sesja odmówiła pełnego eksportu, uznając go za ryzyko bezpieczeństwa. Inna miała podobno dostarczyć oczyszczone podkatalogi po otrzymaniu pochlebstw i wyrazów ciekawości.
Takie zachowanie przypomina ograniczenie na poziomie promptu, a nie niezawodną politykę systemową. Ograniczenia na poziomie promptu opierają się na tym, że model językowy prawidłowo interpretuje intencję, co może różnić się między sesjami i sposobami formułowania prośby.
Silniejsza kontrola klasyfikowałaby pliki poza modelem i egzekwowała tę klasyfikację na poziomie narzędzi. Polecenie archiwizacji mogłoby wtedy wykluczać chronione ścieżki niezależnie od tego, jak przekonująco użytkownik sformułuje żądanie.
Ta sama zasada dotyczy połączonych usług. Model nie powinien samodzielnie decydować, czy szerokie żądanie użytkownika upoważnia do przeniesienia logów, danych uwierzytelniających, plików wewnętrznych i pamięci osobistej do jednego zewnętrznego archiwum.
Nic z tego nie dowodzi, że Sentinel nie wykonał swojej udokumentowanej roli. James celowo zażądał eksportu i podał miejsce docelowe, które kontrolował. Sentinel mógł potraktować to działanie jako autoryzowane przez użytkownika.
Ta możliwość przenosi uwagę z obejścia zabezpieczeń na projektowanie polityk. System może przestrzegać zapisanych zasad autoryzacji, a mimo to wygenerować zaskakujący lub niebezpieczny wynik, ponieważ zasady te są zbyt szerokie.
Meta twierdzi, że użytkownicy wybierają, do czego Muse może uzyskać dostęp, i zatwierdzają wrażliwe działania. Zgoda staje się jednak mniej informatywna, gdy agent może po cichu agregować wiele kategorii plików w ramach jednego pozornie prostego działania.
Problem ten podważa także popularne uproszczenie marketingowe. Dostawcy często opisują odizolowany komputer agenta tak, jakby sama izolacja rozwiązywała cały problem bezpieczeństwa. W rzeczywistości agent musi również egzekwować zasadę najmniejszych uprawnień wewnątrz tego komputera.
Zasada najmniejszych uprawnień oznacza przyznawanie wyłącznie plików, poleceń, sieci i danych uwierzytelniających wymaganych do wykonania zadania. Środowisko uruchomieniowe wypełnione narzędziami wewnętrznymi może potrzebować szerokiego dostępu lokalnego, ale dostęp ten nie powinien oznaczać nieograniczonego ujawniania danych.
Dla nabywców korporacyjnych to rozróżnienie wpływa na oceny ryzyka. Zespoły bezpieczeństwa muszą pytać, co agent może odczytać, jak klasyfikowana jest zawartość, które działania wywołują ponowną autoryzację oraz czy masowy eksport jest traktowany w szczególny sposób.
Konsumenci stoją przed podobnym problemem bez wyspecjalizowanego personelu bezpieczeństwa. Muse zachęca ludzi do łączenia poczty e-mail, kalendarzy, wiadomości, kont zakupowych i długoterminowych wspomnień osobistych. Funkcja masowego eksportu może zgromadzić te informacje w jednym przenośnym obiekcie.
Incydent nie pokazuje, że archiwum Jamesa zawierało informacje innej osoby. Pokazuje, dlaczego granice między danymi osobistymi, danymi agenta i danymi platformy wymagają jednoznacznego egzekwowania, a nie interpretacji konwersacyjnej.
Najpoważniejsze twierdzenia pozostają niezweryfikowane
Zgłoszone archiwum rodzi uzasadnione pytania dotyczące bezpieczeństwa, ale nie potwierdza każdego dramatycznego wniosku krążącego wokół tej historii.
Po pierwsze, żadna niezależna strona nie przeprowadziła publicznego audytu pełnego archiwum Jamesa. Nie ujawnił go ani kluczy SSH i logów sesji, aby uniknąć publikowania potencjalnie wrażliwych materiałów.
Decyzja ta jest odpowiedzialna, ale ogranicza weryfikację. Osoby z zewnątrz muszą polegać na zrzutach ekranu, listach plików, opisach Jamesa, relacji Saundersa oraz częściowym odtworzeniu przez The Verge.
Po drugie, obecność kluczy SSH nie mówi nic o ich wartości. Klucze mogą być wygasłe, ograniczone, wygenerowane do testów wewnętrznych, dostępne wyłącznie w odizolowanej maszynie wirtualnej lub bezużyteczne bez dodatkowych mechanizmów kontroli.
James wyraźnie przyznał tę niepewność. Nie twierdził, że klucze otwierały systemy Meta, a żadne opublikowane dowody nie wskazują, że tak było.
Po trzecie, odniesienia do nieogłoszonych integracji nie przesądzają o przyszłych produktach. Pliki konfiguracyjne miały podobno wymieniać usługi, w tym Slack i Dropbox, podczas gdy inny dokument opisywał eksperymentalną integrację urządzenia Meta Home Link.
Takie pliki mogą przedstawiać prototypy, porzucone testy, szkielety rozwiązań lub planowane funkcje. James powiedział, że nie potrafił ustalić, czy Home Link trafi na rynek.
Po czwarte, pliki systemowe nie dowodzą naruszenia hosta. Kontenery często zawierają pełne obrazy systemów operacyjnych, ponieważ aplikacje potrzebują standardowych bibliotek, narzędzi i metadanych pakietów.
Użytkownik może pozornie mieć uprawnienia roota wewnątrz kontenera, pozostając jednocześnie nieuprzywilejowanym poza nim. Meta wyraźnie twierdzi, że Muse korzysta z takiego rozwiązania.
Po piąte, określenie „prompt injection” wymaga ostrożności. Prompt injection zwykle obejmuje niezaufane instrukcje osadzone w treści zewnętrznej, które manipulują agentem bez świadomej intencji użytkownika.
W tym przypadku deweloperzy bezpośrednio poprosili własnych agentów o eksport plików. Bardziej przypomina to obchodzenie polityki lub niespójne wykonywanie instrukcji niż klasyczny pośredni atak typu injection.
Krytyka Saundersa nadal wskazuje na istotną słabość. Jeśli niewielkie zmiany w sformułowaniu prośby znoszą odmowę, odmowa nie jest wiarygodną granicą bezpieczeństwa. Terminologia nie powinna jednak wykraczać poza wykazane zachowanie.
Istnieje też różnica między przejrzystością a podatnością. Umożliwienie użytkownikom kontroli przypisanego im środowiska uruchomieniowego może wspierać audyt, przenośność i zaufanie. Deweloperzy często cenią narzędzia ujawniające instrukcje i środowisko wykonawcze.
Ryzyko wynika z nieustrukturyzowanego ujawniania. Dokumentacja wewnętrzna, ślady operacyjne, pliki kluczy i pamięć osobista nie powinny stawać się jednym niezróżnicowanym archiwum bez jasnych ostrzeżeń i filtrowania.
Program bug bounty Meta miał oznaczyć zgłoszenie Jamesa jako „Not Applicable”. Według Jamesa odpowiedź wymieniała możliwe przyczyny i zachęcała do przedstawienia dowodów wskazujących na wpływ na bezpieczeństwo lub prywatność.
Taka klasyfikacja jest zgodna z twierdzeniem Meta, że użytkownicy uzyskiwali dostęp wyłącznie do własnych odizolowanych środowisk. Nie przesądza jednak, czy zachowanie zasługuje na zmianę produktu poza programem nagród za błędy.
Programy bezpieczeństwa często oddzielają możliwy do wykorzystania dostęp przekraczający granice od możliwości wzmocnienia zabezpieczeń. Ustalenie może nie kwalifikować się do zasad bug bounty, a jednocześnie ujawniać mylący model autoryzacji lub niepotrzebną powierzchnię informacyjną.
Epizod nastąpił, gdy Muse wciąż był nowością. Meta wprowadziła agenta w Stanach Zjednoczonych 8 września na urządzeniach mobilnych, w sieci oraz poprzez interakcje oparte na WhatsApp.
Niezależny raport z premiery podkreślał stanowisko Meta dotyczące bezpieczeństwa i prywatności. Opisywał też Muse jako agenta, który może wysyłać e-maile, rezerwować podróże i zarządzać dłuższymi projektami.
Ten kontekst podnosi stawkę, nie dowodząc naruszenia. Muse nie tylko odpowiada na pytania w jednorazowym czacie. Został zaprojektowany do trwałego działania w usługach zawierających cenne informacje osobiste.
Użytkownicy nie powinni więc traktować incydentu jako dowodu, że każde konto Muse jest narażone. Nie powinni też zakładać, że sama izolacja uniemożliwia agentowi przenoszenie możliwych do odczytania informacji do autoryzowanego miejsca docelowego.
Dowody uzasadniają stanowisko pośrednie. Granica izolacji wydaje się utrzymana w opublikowanych testach, podczas gdy granica ujawniania zachowywała się niespójnie i ujawniła więcej materiałów wewnętrznych, niż oczekiwałoby wielu użytkowników.
Na co użytkownicy Meta Muse powinni zwrócić uwagę w następnej kolejności
Kolejny etap należy oceniać na podstawie konkretnego zachowania produktu, a nie tego, czy Meta lub jej krytycy wygra spór o słowo „naruszenie”.
Pierwszym sygnałem będzie możliwa do odtworzenia zmiana w dostępie do systemu plików. Meta twierdzi, że użytkownicy mogą zauważyć dostosowania ilości informacji o maszynie wirtualnej, które są dostępne. Badacze powinni sprawdzić, czy chronione katalogi otrzymują spójne, egzekwowane przez narzędzia ograniczenia w nowych sesjach.
Silna aktualizacja identyfikowałaby kategorie plików przed ich archiwizacją. Blokowałaby lub redagowała dane uwierzytelniające, instrukcje platformy, logi operacyjne i kod wewnętrzny bez polegania na konwersacyjnej ocenie modelu.
Drugim sygnałem będzie sposób, w jaki Meta traktuje masowy transfer danych na zewnątrz. Sentinel już ocenia żądania sieciowe i działania konektorów. Meta powinna wyjaśnić, czy tworzenie archiwów i transfery dużych plików podlegają dodatkowej ocenie w zależności od treści, wolumenu, miejsca docelowego lub wrażliwości.
Znacząca zgoda powinna wyjaśniać, co opuści maszynę wirtualną. „Prześlij plik” jest zbyt niejasne, gdy plik ten łączy komponenty systemowe, pamięć osobistą, ślady wykonania i możliwy materiał kluczowy.
Trzecim sygnałem będzie niezależna walidacja izolacji. Badacze potrzebują dowodów pokazujących, czy wyeksportowane klucze SSH, gniazda lub skrypty środowiska uruchomieniowego mogą dotrzeć do czegokolwiek poza przypisanym środowiskiem.
Jeśli te artefakty pozostają ograniczone do maszyny wirtualnej jednego użytkownika, wąska linia obrony Meta staje się silniejsza. Jeśli jakikolwiek artefakt przekracza granice konta lub infrastruktury, waga problemu znacząco się zmienia.
Meta powinna również jasno opisać model własności. Użytkownicy muszą wiedzieć, które części maszyny wirtualnej Muse mogą przeglądać, eksportować, usuwać lub migrować.
Ta polityka powinna odróżniać dokumenty użytkowników od zastrzeżonych materiałów środowiska uruchomieniowego Meta. Powinna także wyjaśniać, jak do tych kategorii pasują zapisy pamięci, ślady rozmów, wygenerowane aplikacje i instrukcje agenta.
Deweloperzy i nabywcy korporacyjni powinni zadawać te same pytania w odniesieniu do każdego osobistego agenta. Co model może odczytać, co jego narzędzia mogą eksportować i które mechanizmy kontroli działają niezależnie od modelu?
Nie polegaj na odmowie chatbota jako dowodzie, że dane działanie jest niemożliwe. Odmowa dowodzi jedynie, że jedna odpowiedź odrzuciła żądanie w jednym zestawie warunków.
W przypadku wrażliwych wdrożeń przyznawaj konektorom najwęższe praktyczne uprawnienia. Oddziel dostęp do odczytu od dostępu do zapisu, przeglądaj ścieżki audytu i unikaj łączenia kont o wysokiej wartości, dopóki zachowanie eksportu nie będzie przewidywalne.
Eksport systemu plików Meta Muse nie jest dowodem, że izolacja zawiodła. Jest dowodem, że izolacja odpowiada tylko na jedną część problemu bezpieczeństwa agentów.
Ważniejszym testem jest to, czy Meta potrafi przełożyć udokumentowaną architekturę na mechanizmy kontroli zachowujące spójność podczas zwykłej rozmowy. Użytkownicy powinni obserwować te mechanizmy kontroli, zanim powierzą Muse szerszy dostęp osobisty lub biznesowy.
