Publiczne linki rozmów AI: udostępnienie może być publikacją

Przycisk „Udostępnij” w asystencie AI wygląda jak wygodny sposób przekazania rozmowy współpracownikowi. Technicznie często tworzy jednak publiczny zasób HTTP bez uwierzytelnienia. Każdy, kto ma adres, może otworzyć rozmowę lub artefakt. Jeżeli wyszukiwarka albo archiwum odwiedzi stronę, trudny do odgadnięcia identyfikator przestaje chronić przed odkryciem.

Varonis Threat Labs przeanalizowało mechanizmy udostępniania w popularnych usługach, m.in. ChatGPT, Claude, Gemini, Grok, DeepSeek, Perplexity, Meta AI, Manus i Kimi. Raport z 29 lipca pokazuje, że problem nie sprowadza się do jednego błędu produktu. To kolizja trzech modeli: użytkownik myśli o prywatnym linku, przeglądarka widzi publiczny URL, a firma często nie widzi danych przekazywanych przez osobiste konto AI.

Długi token nie jest kontrolą dostępu

Linki mają zwykle postać stałej ścieżki i losowego identyfikatora, np. UUID. Taki identyfikator skutecznie utrudnia zgadywanie adresów metodą brute force. Nie pomaga jednak, gdy URL pojawi się w:

• indeksie wyszukiwarki;
• historii i telemetrii przeglądarki;
• komunikatorze albo systemie zgłoszeń;
• nagłówku odsyłającym lub logach proxy;
• publicznym repozytorium, dokumencie lub nagraniu ekranu;
• archiwum internetu albo kopii wykonanej przez odbiorcę.

Po pierwszym ujawnieniu nie trzeba już odgadywać tokenu. Można go skopiować, zaindeksować i rozesłać. To ta sama zasada, która dotyczy publicznych linków do plików w chmurze: wysoka entropia adresu zmniejsza ryzyko enumeracji, ale nie zastępuje tożsamości, autoryzacji ani wygaśnięcia.

noindex ogranicza odkrywanie, nie dostęp

Badacze wskazują, że większość platform dodaje dziś meta robots: noindex, nagłówek X-Robots-Tag lub reguły w robots.txt. To właściwe zabezpieczenia przed przypadkowym indeksowaniem, ale mają ograniczony zakres:

• są dyrektywami dla współpracujących robotów, a nie mechanizmem autoryzacji;
• nie cofają kopii już pobranych przez osoby, boty i archiwa;
• nie blokują dostępu użytkownikowi, który posiada URL;
• nie chronią przed wklejeniem linku do publicznego kanału.

Usunięcie wyniku z Google również nie jest równoznaczne z usunięciem danych ze wszystkich indeksów i archiwów. Varonis opisało różnice między nowymi i starszymi domenami share oraz platformami, które w różnym tempie ograniczały indeksowanie. Stan pojedynczej usługi może się zmienić, ale model zagrożenia pozostaje: publiczny link jest formą publikacji.

Co może wyciec z firmowej rozmowy

Najgroźniejsze nie są zwykłe pytania do modelu, lecz kontekst dołączony do odpowiedzi. Rozmowa może zawierać:

• fragmenty kodu i błędy z produkcji;
• logi z tokenami, adresami systemów i danymi klientów;
• pliki, umowy, zgłoszenia i wewnętrzne decyzje;
• instrukcje systemowe, konfigurację agenta i listę podłączonych narzędzi;
• dane pobrane przez asystenta z nadmiernie dostępnych repozytoriów;
• treść, którą model streścił, ale której użytkownik nie powinien publikować.

Ryzyko rośnie przy shadow AI: pracownik używa prywatnego konta na urządzeniu służbowym, poza kontrolą tenantów, DLP i retencji. Wtedy dostawca AI staje się warstwą publikacji, a firma może nawet nie mieć inwentarza utworzonych linków.

Plan działania dla organizacji

1. Ustal, gdzie działa funkcja share

Zidentyfikuj zatwierdzone i popularne niezatwierdzone asystenty. Sprawdź osobno rozmowy, artefakty, aplikacje i publiczne strony. Nie zakładaj, że polityka dla planu Enterprise obowiązuje także konto osobiste.

2. Ogranicz wrażliwe dane przed modelem

Zasada „nie klikaj Udostępnij” jest za słaba, jeżeli sekret już trafił do rozmowy. Stosuj klasyfikację danych, DLP, redakcję sekretów i minimalne uprawnienia konektorów. Asystent powinien widzieć tylko zasoby potrzebne do konkretnego celu.

3. Traktuj link jak zmianę uprawnień

Tworzenie publicznego adresu powinno być rejestrowanym zdarzeniem. W wersjach firmowych preferuj odbiorców uwierzytelnionych, datę wygaśnięcia, możliwość centralnego unieważnienia i widoczność administratora.

4. Przygotuj procedurę wycieku

Jeśli link zawierał dane firmowe:

1. unieważnij lub usuń udostępnienie u dostawcy;
2. zachowaj URL, czas, właściciela i zakres rozmowy jako dowód;
3. ustal, czy strona była indeksowana, archiwizowana lub przesłana dalej;
4. rotuj widoczne tokeny, klucze, hasła i sesje — samo usunięcie strony nie wystarcza;
5. oceń obowiązki kontraktowe, prawne i komunikacyjne;
6. usuń pierwotną przyczynę: nadmierne uprawnienia, brak DLP albo osobiste konto.

Jak szkolić pracowników

Najlepszy komunikat nie brzmi „nigdy nie udostępniaj AI”. Powinien wyjaśniać, że publiczny link przypomina opublikowanie strony internetowej. Przed utworzeniem linku użytkownik ma sprawdzić rozmowę od początku, załączniki, cytowane dane i treść wygenerowanego artefaktu. W razie wątpliwości należy przekazać bezpiecznie oczyszczony fragment, a nie pełną historię.

Ten temat warto połączyć z przewodnikiem bezpieczeństwa LLM w firmie oraz zasadami zarządzania sekretami. Problem share linków jest prostym testem dojrzałości: czy organizacja kontroluje dane zanim model wygeneruje atrakcyjną odpowiedź.

Fakty źródłowe a wnioski Breachroad

Wzorce publicznych URL-i, obserwacje indeksowania i działanie noindex opisuje Varonis. Konkretne ustawienia platform mogą zmieniać się z dnia na dzień, dlatego przed decyzją należy sprawdzić dokumentację i zachowanie używanego planu. Nie każdy link był lub jest indeksowany, a publiczna dostępność nie dowodzi, że ktoś poza odbiorcą go odczytał.

Wnioskiem Breachroad jest traktowanie funkcji share jako operacji publikacji i objęcie jej DLP, rejestrowaniem, retencją oraz reakcją na incydenty. Szkolenia z bezpiecznego wdrażania AI pomagają ustalić te zasady, a AI red teaming może sprawdzić, czy publiczne linki, konektory i uprawnienia tworzą realną ścieżkę wycieku.