Zasada najmniejszych uprawnień w AI

Zasada najmniejszych uprawnień, po angielsku least privilege, mówi prosto: człowiek, aplikacja lub agent dostaje wyłącznie taki dostęp, jaki jest potrzebny do wykonania jednego, jasno określonego zadania. Nie jest to zasada zarezerwowana dla działu IT. Staje się praktyczna od momentu, gdy AI może czytać CRM, kalendarz, dysk, skrzynkę lub uruchamiać automatyzacje. Model nie powinien dostać dostępu do całego biznesu tylko dlatego, że wygodniej jest podłączyć jedno konto administratora.

W systemie AI uprawnienia występują na kilku poziomach. Pierwszy to zakres danych: agent do researchu może odczytać wybrany folder, ale nie całą chmurę. Drugi to rodzaj działania: może utworzyć szkic odpowiedzi albo zadanie, lecz nie wysłać maila i nie usunąć kontaktu. Trzeci to czas: token testowy lub dostęp dla jednego workflow powinien wygasać i być możliwy do odebrania bez zatrzymania całej firmy. Warto ograniczać też środowisko, na przykład oddzielić sandbox od produkcji.

Dlaczego jest to szczególnie ważne dla agentów? Agent podejmuje kolejne kroki na podstawie tekstu, danych i wyników narzędzi. Może źle zinterpretować polecenie, halucynować albo natrafić w dokumencie na złośliwą instrukcję. OWASP opisuje ryzyko nadmiernej sprawczości wtedy, gdy system ma zbyt szerokie funkcje, uprawnienia albo autonomię. Najmniejsze uprawnienia nie sprawią, że model przestanie popełniać błędy. Zmniejszą jednak promień rażenia błędu, ponieważ błędna decyzja nie otrzyma możliwości wykonania operacji spoza zadania.

Przykład dla ekspertki sprzedającej konsultacje: automatyzacja pobiera formularze, klasyfikuje zgłoszenia i przygotowuje propozycję odpowiedzi. Daj jej odczyt wyłącznie do formularza i możliwość zapisania szkicu w osobnej tabeli. Nie dawaj dostępu do płatności, listy wszystkich klientów ani prawa wysyłki z głównej skrzynki. Gdy chcesz uruchomić follow-up, osobny krok powinien wymagać zatwierdzenia człowieka albo korzystać z konta, które może wysłać wiadomość tylko do wskazanego leada. Taki podział jest mniej efektowny niż „agent robi wszystko”, ale jest znacznie bezpieczniejszy.

Nie myl uprawnień z instrukcją w prompcie. Zdanie „nie usuwaj danych” jest przydatne, lecz nie blokuje endpointu delete, jeśli narzędzie go udostępnia. Granice trzeba egzekwować technicznie: przez role, scope tokenu OAuth, osobne klucze API, whitelistę narzędzi, walidację parametrów i progi akceptacji. W MCP klient i serwer powinny również jasno obsługiwać autoryzację. Specyfikacja zwraca uwagę na wiązanie tokenu z docelowym zasobem, aby token dla jednej usługi nie został użyty przy innej.

Zacznij od prostego audytu każdego workflow. Zapisz: jakie dane czyta, jakie systemy zmienia, czy operacja jest odwracalna i jaki minimalny zakres dostępu jest potrzebny. Usuń nieużywane integracje, rozdziel konto testowe od produkcyjnego i nie wkładaj sekretów do promptów ani plików dostępnych dla agenta. Dla publikacji, wysyłki, zmian cen, płatności i kasowania danych dodaj człowieka w pętli. Dopiero po takim ograniczeniu dostępu warto zwiększać autonomię automatyzacji.