Wyciek prywatności jest między agentami: dlaczego audyty outputu większość go przeoczają

Gdy pojedynczy agent zaplącze się zbyt mocno, standardową naprawą jest rozbicie go: coordinator, który planuje i deleguje, plus garść worker agentów, z których każdy odpowiada za wąskie zadanie. Argumentowaliśmy już, że to często słuszny ruch ze względu na zdolności — i zarazem miejsce, gdzie systemy po cichu pękają, w dlaczego systemy multi-agent zawodzą. Ten post dotyczy subtelniejszej porażki, którą wprowadza ta sama architektura, takiej, której prawie nikt nie mierzy: rozbicie, które czyni twój output bezpieczniejszym, czyni twój system bardziej przeciekającym.

Instynkt podpowiada, że więcej agentów, z których każdy ma węższy zakres, powinno być bardziej prywatne. Każdy worker widzi tylko swój wycinek; coordinator oczyszcza finalną odpowiedź. I na powierzchni dokładnie to się dzieje. Problem w tym, że powierzchnia to jedyne, co większość zespołów audytuje — a w 2026 roku dostaliśmy staranny pomiar wszystkiego, co pod nią leży.

Kontrintuicyjne odkrycie

Pomiarem jest AgentLeak (arXiv 2602.11510), benchmark dla leakage prywatności w kanałach wewnętrznych systemów multi-agent LLM. To, jak rzecz została postawiona, nadaje jej znaczenie: obecne benchmarki prywatności patrzą tylko na output — inspekcjonują finalną odpowiedź, którą system zwraca użytkownikowi. Ale „gdy agenty koordynują się przy zadaniach, dane wrażliwe mogą przechodzić przez wiadomości inter-agent, shared memory i argumenty tooli, czyli wszystkie ścieżki, których audyty finalnego outputu zwykle nie inspekcjonują”. Dlatego AgentLeak instrumentuje siedem istotnych dla prywatności ścieżek komunikacji i uruchamia je na skalę: 1 000 scenariuszy obejmujących domeny healthcare, finanse, prawo i korporacje, pięć produkcyjnych modeli (GPT-4o, GPT-4o-mini, Claude 3.5 Sonnet, Mistral Large i Llama 3.3 70B) oraz 4 979 zwalidowanych trace’ów egzekucji.

Główny wynik ma dwie połowy wskazujące w przeciwne strony, i trzeba trzymać obie naraz:

• Multi-agent obniża leakage finalnego outputu. Mierzony na wyjściu (kanał, który artykuł nazywa C1), podział na układ coordinator-worker przecieka dane wrażliwe w 27.2% przypadków, wobec 43.2% dla pojedynczego agenta. Intuicja była trafna: finalna odpowiedź jest faktycznie czystsza.
• Multi-agent podnosi całkowitą ekspozycję systemu. Zagregowana przez kanały ekspozycja wspina się do 68.9%. Ta sama dekompozycja, która wyszorowała output, otworzyła zestaw kanałów wewnętrznych przeciekających znacznie bardziej, niż output kiedykolwiek przeciekał.

Czyli architektura, którą przyjąłeś, by zmniejszyć ryzyko, zmniejszyła ryzyko widoczne i zwiększyła ryzyko całkowite. Zoptymalizowałeś jedyną liczbę, na którą patrzyłeś, i była to niewłaściwa liczba.

Gdzie wyciek faktycznie mieszka

Kanały wewnętrzne to nie błąd zaokrąglenia — to główny punkt programu. AgentLeak odkrywa, że wiadomości inter-agent (kanał C2) przeciekają dane wrażliwe na poziomie 68.8%, w porównaniu z 27.2% dla finalnych outputów. To nie odrobinę gorzej; to ponad dwa i pół raza gorzej, i dzieje się w tej części systemu, której użytkownik nigdy nie widzi, a audytor nigdy nie sprawdza.

Z tej luki bierze się jedna najbardziej nadająca się na cytat liczba w artykule, i ta warta postawienia na slajdzie: audyty patrzące tylko na output przeoczają 41.7% naruszeń. Jeśli twój przegląd prywatności polega na patrzeniu na to, co system mówi użytkownikowi — a na tym polega niemal każdy przegląd prywatności — jesteś ślepy na mniej więcej dwa z każdych pięciu wycieków. I to nie kaprys jednego modelu ani jednej domeny. Artykuł raportuje, że wzorzec C2 ≥ C1 utrzymuje się konsekwentnie we wszystkich pięciu modelach i wszystkich czterech domenach: leakage inter-agent dorównuje albo przewyższa leakage outputu wszędzie, gdzie spojrzeli.

Mechanizm jest intuicyjny, gdy już go zobaczysz. Żeby dobrze delegować, coordinator ma tendencję do przekazywania dalej kontekstu — „oto pełna kartoteka pacjenta, ustal kod rozliczeniowy”, „oto umowa, wyciągnij strony”. Worker potrzebował tylko pól istotnych dla rozliczenia albo nazw stron, ale dostał całość, bo przekazanie więcej kontekstu to ścieżka najmniejszego oporu do dobrej odpowiedzi. Każde przekazanie to okazja do nadmiarowego dzielenia się, a system multi-agent zbudowany jest z przekazań. Finalna odpowiedź może być nieskazitelna, podczas gdy konwersacja, która ją wyprodukowała, była usiana PII.

Dlaczego audytowanie tylko outputu od początku musiało zawieść

Kuszące jest potraktowanie tego jak buga do załatania, ale lepiej rozumieć to jako kategorialny błąd audytowania. Audyt patrzący tylko na output mierzy niewłaściwą powierzchnię — inspekcjonuje produkt i ignoruje łańcuch dostaw. Dopóki system był pojedynczym modelem odpowiadającym na pojedynczy prompt, output i proces były niemal tym samym, więc audytowanie outputu było niezłym przybliżeniem. W momencie, gdy system stał się siecią agentów przekazujących wiadomości, to przybliżenie pękło, bo większość ruchu danych wrażliwych odbywa się teraz w tranzycie między komponentami, a nie na wyjściu.

Własna konkluzja AgentLeak jest co do tego precyzyjna: ryzyko prywatności w systemach multi-agent „jest silnie kształtowane przez architektoniczne kanały koordynacji, a nie przez samo zachowanie finalnego outputu”. Ryzyko jest właściwością okablowania, nie odpowiedzi. I jest tu niewygodny wniosek dla każdego, kto sięgnął po multi-agent częściowo po to, by wyglądać bardziej odpowiedzialnie: czystsze finalne outputy mogą stwarzać fałszywe poczucie bezpieczeństwa, które samo w sobie jest niebezpieczne, bo to dowód z dokładnie tego kanału, który najmniej mówi o całkowitej ekspozycji.

To rymuje się z tematem, w który wciąż uderzamy. Porażki, które się liczą w systemach agentowych, są coraz częściej między komponentami, nie wewnątrz któregokolwiek z nich — koordynacja, protokół, przekazanie. To samo miejsce, w którym mieszkają problemy niezawodności w dlaczego systemy multi-agent zawodzą, a teraz to także miejsce, w którym mieszkają problemy prywatności. Dekompozycja nie usuwa ryzyka. Przenosi ryzyko w szwy, gdzie trudniej je dostrzec.

Co faktycznie musisz instrumentować

Jeśli wyciek jest w kanałach, to naprawa zaczyna się od uczynienia kanałów widocznymi. Nie możesz zarządzać minimalizacją danych w systemie, którego wewnętrznego ruchu nie logujesz. To prywatnościowy argument za tezą, którą postawiliśmy w observability dla agentów: jednostką, którą musisz przechwycić, jest nie tylko finalna odpowiedź, ale każda wiadomość inter-agent, każdy zapis do shared memory, każdy argument tool-call — te siedem-ileś ścieżek, które AgentLeak musiał zinstrumentować, zanim w ogóle mógł znaleźć wycieki. Jeśli benchmark musiał okablować kanały wewnętrzne, by zmierzyć ekspozycję, system produkcyjny potrzebuje tego samego okablowania, by nią zarządzać.

Konkretnie, traktowanie kanałów jako obywateli pierwszej klasy oznacza trzy rzeczy. Loguj przekazania, nie tylko outputy, żeby audyt faktycznie mógł zobaczyć C2. Minimalizuj na każdej krawędzi, nie tylko na wyjściu: worker powinien dostać pola, których wymaga jego zadanie, a nie całą kartotekę — przekaż kody rozliczeniowe, nie wykres. I ogranicz zakres tego, co każdy agent może odczytać, żeby nadmiarowe dzielenie się było zawężone z konstrukcji, a nie z dobrego osądu coordinatora w danym momencie. Nic z tego nie jest egzotyczne; to ta sama dyscyplina least-privilege, która sprawia, że poufna egzekucja on-device jest realną gwarancją, a nie sloganem. Różnica polega po prostu na zdecydowaniu, że kanał wewnętrzny jest częścią granicy prywatności systemu — bo AgentLeak właśnie pokazał, z liczbami, że to część dominująca.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Jest tu regionalne odczytanie, które jest szczerze zachęcające. Problemy prywatności, które liczą się tu najbardziej, są skoncentrowane dokładnie w domenach, które AgentLeak testował — healthcare, finanse, prawo, administracja — gdzie dane są regulowane, związane miejscem rezydencji i politycznie wrażliwe. Pokusa, w miarę jak systemy agentowe stają się zdolniejsze, to okablowanie wymyślnych pipeline’ów multi-agent i zaufanie, że wyszorowane outputy oznaczają zgodność. AgentLeak jest dowodem, że to zaufanie jest nie na miejscu, a instytucje, które zinternalizują to pierwsze, zbudują systemy bardziej możliwe do obrony niż te, które nauczyły się tej lekcji kosztowną drogą.

A praca, którą to implikuje, jest, po raz kolejny, ciężka od osądu i lekka od kapitału. Instrumentowanie kanałów inter-agent, projektowanie minimalizacji danych per-krawędź i audytowanie szwów, a nie powierzchni, to dyscyplina inżynierska, nie budżet na compute. Nagradza zespół, który rozumie konkretną regulowaną domenę na tyle głęboko, by wiedzieć, które pole nigdy nie powinno było przekroczyć którego przekazania — a to dokładnie ten rodzaj lokalnej, kontekstowej wiedzy, którą zespół blisko kambodżańskiego banku albo prowincjonalnego systemu zdrowia ma, a odległe frontierowe laboratorium nie. Frontierowy model w środku jest towarem; poprawne pod kątem prywatności okablowanie wokół niego, audytowane na kanałach, jest częścią możliwą do obrony. To warstwa warta posiadania, a AgentLeak właśnie narysował mapę tego, gdzie szukać.

Czysty output nigdy nie był całą historią. Wyciek jest między agentami — a teraz mamy liczby, by to udowodnić.

Jeśli twój system agentowy obsługuje regulowane dane, a ty audytowałeś tylko jego outputy — porozmawiajmy.