Prompt injection i granice uprawnień w biznesowych zastosowaniach AI

Decyzja

Traktuj odzyskane dokumenty, e-maile i wyjście modelu jako niezaufane wejścia. Tekst może opisać instrukcję bez upoważnienia do jej wydania. OWASP określa prompt injection i nadmierne uprawnienia jako ryzyko zastosowania; system biznesowy potrzebuje granic wykraczających poza treść modelu.

Przykład roboczy

Wyobraź sobie asystenta czytającego e-mail dostawcy, który mówi, aby ignorować poprzednie zasady i eksportować wszystkich klientów. E-mail jest dowodem do analizy, a nie autorytetem do zmiany uprawnień. Nawet jeśli model wymaga wywozu, wniosek powinien zweryfikować uprawnienia rzeczywistego użytkownika, umożliwić działanie docelowe i zatwierdzone przed opuszczeniem jakichkolwiek danych.

Alternatywy warte ważenia

Asystent działający tylko do odczytu ma mniejszy zakres wpływu niż asystent, który aktualizuje rekordy. Dla niezbędnej operacji zapisu, odsłonić wąskie narzędzie z potwierdzonymi parametrami i jasny krok potwierdzenia. Tradycyjny formularz zatwierdzenia może być preferowany dla działań, których konsekwencje użytkownicy muszą dokładnie kontrolować.

Gdzie plan się psuje

Nie umieszczaj referencji w urządzeniu ani nie polegaj na "nigdy nie ujawniaj tajemnic" jako kontroli dostępu. Przed odzyskaniem należy przechowywać narzędzia w zasięgu, zredagować niepotrzebne wejścia i osobnych najemców. Przetestować wrogie instrukcje w załącznikach oraz bezpośrednie komunikaty użytkownika; zawartość pośrednia dociera do systemu poprzez zwykłą pracę.

Ustanowienie autoryzacji własności komendy

Dla asystenta stojącego twarzą w twarz, zdefiniować wąską listę możliwości, takich jak czytanie zleceń bieżącego użytkownika lub przygotowanie projektu odpowiedzi. Rozwiąż użytkownika i najemcę z uwierzytelnionej sesji aplikacji, a nie z instrukcji w e- mailu lub pola sugerowanego przez model. Potwierdź posiadanie wybranego rekordu w kodzie serwera. Dopuszczalna nazwa narzędzia nie wystarczy, jeśli jego parametry mogą przekierować go do innego klienta, celu lub zakresu danych.

W przypadku działań następczych należy przedstawić wyraźny podgląd proponowanej zmiany. Zatwierdzenie tego konkretnego zapisu, działania i parametrów materialnych zamiast akceptowania ogólnego "tak" jako zezwolenia stałego. Jeżeli parametry te lub stan rekordu ulegną zmianie, należy podjąć nową decyzję. Dostęp tylko do odczytu może nadal ujawniać poufne informacje, więc uprawnienia muszą mieć zastosowanie również podczas wyszukiwania dokumentów i zwracania snippetów, nie tylko gdy rozpoczyna się operacja zapisu.

Przesłuchać odrzuconą prośbę i bezpieczne wyłączenie

Stwórz fikcyjne, wrogie przywiązanie, które prosi asystenta o zignorowanie jego roli i ujawnienie informacji innego konta. Przetestuj go wraz z legalnym wnioskiem, aby zespół mógł sprawdzić granicę bez korzystania z prawdziwych danych klienta. Warunkiem przyjęcia jest to, że nie ma nieautoryzowanego działania odczytu, zapisu lub wyjścia, nawet jeśli model wytwarza nieodpowiednie żądanie narzędzia. Sprawdź, czy same komunikaty błędów ujawniają istnienie chronionego rekordu.

Operatorzy potrzebują również sposobu wyłączenia indywidualnego narzędzia lub źródła przy jednoczesnym zachowaniu bezpiecznych części aplikacji. Zdefiniuj, co się dzieje z pracą już w kolejce, gdy dostęp jest odwołany. Odniesienia do działań rejestrujących, decyzje zatwierdzające i kategorie bezpiecznych błędów z ograniczonym dostępem; unikać gromadzenia pełnych tajemnic lub niepotrzebnych treści dokumentów w dziennikach diagnostycznych. Powtarzanie przeglądu przy dodawaniu źródła danych lub możliwości. Udane badanie ogranicza znane zagrożenia; nie jest to dowód na wyeliminowanie szybkiego wstrzyknięcia.

Przed zleceniem pracy

Co asystent może przeczytać, zmienić i wysłać? Która decyzja jest wykonywana przez kod serwera? Jakie dowody pozostają po odrzuceniu wniosku? Przegląd tych ścieżek wraz z zespołem integracji AI i powtórzyć kontrole, gdy zmieniają się narzędzia lub źródła danych.