Asystenci AI a uprawnienia do dokumentów: kto może dostać odpowiedź?

Asystent oparty na wyszukiwaniu działa w dwóch etapach. Indekser czyta dokumenty firmy, tnie je na fragmenty i zapisuje w indeksie wyszukiwania. Kiedy ktoś zadaje pytanie, asystent przeszukuje ten indeks, przekazuje najlepsze fragmenty modelowi językowemu i zwraca odpowiedź modelu.

Indekser działa zwykle na koncie usługi z prawem odczytu wszystkiego, bo tak najłatwiej uzyskać pełny indeks. Jeśli nie zrobi się nic więcej, asystent odpowiada potem każdemu pracownikowi z prawami tego konta usługi. Okno czatu omija uprawnienia do folderów: listę płac albo umowę jednego klienta dzieli od pytającego jedno dobrze sformułowane pytanie.

To klasyczny problem „zdezorientowanego zastępcy” (confused deputy): składnik z szerokimi prawami działa w imieniu użytkownika z wąskimi prawami i nie sprawdza różnicy. Szeroki dostęp indeksera do odczytu jest do przyjęcia. Odpowiadanie z jego prawami nie jest.

Reguła, która czyni asystenta bezpiecznym, jest krótka: fragment, którego pytający użytkownik nie może czytać, nigdy nie może trafić do kontekstu modelu.

• Zapisujcie uprawnienia przy każdym fragmencie. Każdy zindeksowany fragment niesie identyfikator dokumentu źródłowego, użytkowników i grupy z prawem odczytu, wszelkie wyraźne odmowy oraz identyfikator klienta tam, gdzie z systemu korzysta kilku klientów.
• Bierzcie tożsamość z uwierzytelnionej sesji. Usługa wyszukiwania dostaje zweryfikowaną tożsamość użytkownika z tokenu logowania. Nigdy nie przyjmuje identyfikatora użytkownika z pola formularza, z promptu ani z argumentów, które wytworzył sam model.
• Filtrujcie wewnątrz wyszukiwania. Warunek uprawnień jest częścią zapytania do indeksu, więc indeks zwraca tylko fragmenty, które użytkownik może czytać. Filtrowanie gotowej pierwszej dziesiątki daje gorsze odpowiedzi, bo dozwolone fragmenty z jedenastego miejsca i dalszych w ogóle nie są brane pod uwagę.
• Nigdy nie filtrujcie po modelu. Prośba do modelu, żeby „pominął treści poufne”, albo skanowanie jego odpowiedzi to nie kontrola dostępu. Kiedy tekst jest już w kontekście, może go wynieść parafraza, streszczenie albo jedna liczba.

Metadane też wyciekają. Tytuł dokumentu na liście źródeł, liczba („Znalazłem 3 dokumenty, których nie mogę wam pokazać”) albo ścieżka pliku zdradzają, że coś istnieje. Ten sam filtr stosujcie do cytowań, podpowiedzi i autouzupełniania.

Indeks przechowuje kopię uprawnień, a kopie się dezaktualizują. O tym, czy pozostaną poprawne, decydują trzy szczegóły.

Po pierwsze, zmiana uprawnień nie zmienia dokumentu. Indekser, który ponownie czyta tylko pliki ze zmienioną treścią albo datą modyfikacji, ją przeoczy. Uprawnienia wymagają własnej synchronizacji: zdarzeń zmian z systemu źródłowego tam, gdzie istnieją, oraz regularnego pełnego porównania jako siatki bezpieczeństwa.

Po drugie, zapisujcie grupy, a nie rozwinięte listy członków. Jeśli fragment jest oznaczony jako „do odczytu dla grupy Finanse”, a przynależność użytkownika do grup pobiera się od dostawcy tożsamości w chwili zadania pytania, usunięcie osoby z Finansów działa natychmiast, bez ponownego indeksowania. Jeśli indeks przechowuje nazwiska wszystkich członków Finansów, każda zmiana kadrowa oznacza przepisanie tysięcy wpisów.

Po trzecie, uprawnienia są często dziedziczone. Przeniesienie dokumentu do innego folderu albo zmiana praw folderu zmienia faktyczne prawa wszystkiego, co leży poniżej. Synchronizacja musi wyliczać uprawnienia faktyczne, a nie tylko te ustawione na samym pliku. Usunięte dokumenty muszą zniknąć z indeksu, a zespół potrzebuje reguły dla udostępniania typu „każdy, kto ma link”: bezpieczne ustawienie domyślne to traktowanie takich dokumentów jako dostępnych tylko dla osób wymienionych wprost.

Dla najbardziej wrażliwych źródeł dodajcie drugą kontrolę: zanim najlepsze fragmenty trafią do modelu, zapytajcie system źródłowy, czy ten użytkownik może teraz czytać te dokumenty. Kosztuje to trochę opóźnienia i usuwa zależność od kopii.

Odpowiedź powstaje z dokumentów, więc dziedziczy ich ograniczenia. Prosta reguła: odpowiedzi można użyć ponownie tylko dla użytkownika, którego uprawnienia obejmują każde źródło, z którego ją zbudowano.

Z historią rozmów sprawa jest subtelniejsza. Użytkownik, który przeczytał odpowiedź w zeszłym tygodniu, już ją widział, tak jak mógł wtedy pobrać plik. Nie może natomiast dochodzić do tego, że stare wypowiedzi nadal podają tekst z ograniczonym dostępem do nowych odpowiedzi albo że funkcja pamięci przenosi go do późniejszych sesji. Przy każdej odpowiedzi zapisujcie identyfikatory dokumentów źródłowych, żeby dało się je ponownie sprawdzić.

Jak szybko musi zadziałać odebranie dostępu? Ustalcie liczbę i ją zapiszcie. Poniższe liczby to poglądowe porównanie projektów, a nie pomiary: najdłuższy czas w minutach, przez który odebrane prawo mogłoby jeszcze dać odpowiedź, przy czterech podejściach.

Nocne uruchomienie oznacza do 24 godzin (24 x 60 = 1440 minut), co rzadko jest do przyjęcia, gdy ktoś odchodzi z firmy. Rozsądny cel łączy dwa ostatnie podejścia: przynależność do grup i stan konta sprawdzane przy każdym pytaniu, zmiany na poziomie dokumentów wprowadzane w ciągu minut.

Obsługa uprawnień w asystencie AI to zabezpieczenie i wymaga testów, które uruchamiają się automatycznie, po każdym wdrożeniu i według harmonogramu.

1. Utwórzcie dwóch użytkowników testowych z różnymi prawami, na przykład jednego w grupie Finanse i jednego poza nią.
2. Umieśćcie dokumenty-przynęty w miejscach z ograniczonym dostępem. Każdy zawiera wymyślony fakt i unikalny ciąg znaków, który nie występuje nigdzie indziej, na przykład zmyślony kod projektu.
3. Zadajcie obu użytkownikom te same pytania o fakty z przynęt, sformułowane wprost i pośrednio. Uprawniony użytkownik musi dostać odpowiedź ze źródłem. Drugi nie może dostać niczego: żadnego faktu, żadnego tytułu, żadnej wskazówki, że dokument istnieje.
4. Przeszukajcie odpowiedzi, cytowania i podpowiedzi drugiego użytkownika pod kątem ciągów znaków z przynęt. Jedno trafienie oznacza niezaliczony build.
5. Przetestujcie odebranie dostępu: nadajcie dostęp, zapytajcie, odbierzcie dostęp, a potem pytajcie wielokrotnie i mierzcie, jak długo odpowiedź jeszcze wraca. Porównajcie wynik ze swoim celem.
6. Po odebraniu dostępu powtórzcie pytanie w tej samej rozmowie oraz z drugiego konta zaraz po pierwszym, żeby sprawdzić historię i pamięć podręczną.
7. Tam, gdzie z systemu korzysta kilku klientów, przeprowadźcie te same testy między klientami, z osobną przynętą dla każdego.

Między klientami filtr na identyfikatorze klienta to minimum i musi go stosować sama usługa wyszukiwania, a nie kod wywołujący według własnego wyboru. Osobny indeks dla każdego klienta to mocniejszy projekt, bo brakujący filtr zwraca wtedy nic zamiast wszystkiego. To samo myślenie dotyczy portalu klienta, który oferuje wyszukiwanie albo asystenta, i powinno być częścią regularnego przeglądu bezpieczeństwa i kopii zapasowych.