Agent zaczyna od odczytu jednej kolekcji, a po kilku integracjach ma zapis, publikację, eksport i administratora. Nikt nie pamięta, kiedy dodał prawa. Działa, więc nikt nie pyta. Minimalny zakres powinien odpowiadać rzeczywistemu zadaniu i skutkowi błędu, a nie wygodzie konfiguracji.
Uprawnienia agentów są procesem: rola, źródło, działanie, odbiór i odmowa. Model może proponować kroki, ale system powinien ograniczać skutki niezależnie od intencji promptu.
Zacznij od zadania i skutku
Zapisz, co agent robi i co może zepsuć. Odczyt publicznej dokumentacji jest inny niż zapis w CRM lub wysyłka klientowi. Nie przypisuj jednej roli „AI” dla wszystkiego.
Opisz źródła, narzędzia i decyzje. Nie każdy etap wymaga automatyzacji. Człowiek może wykonywać skutek, a agent przygotowuje propozycję.
Przy mapie stosuj zasady z artykułu o bezpiecznych uprawnieniach agentów. Minimalizacja powinna odpowiadać skutkowi.
Rozdziel odczyt, zapis i publikację
Nadaj osobne prawa dla każdej operacji. Odczyt nie oznacza zgody na zmianę. Przygotowanie szkicu nie oznacza publikacji. Każda operacja powinna mieć właściciela.
Przy zapisie pokaż różnice i źródło. Przy publikacji wymagaj odbioru publicznego adresu. Nie zastępuj odbioru samego statusu 200.
Przy publikacjach stosuj zasady z artykułu o odbiorze CMS AI. Uprawnienia powinny ograniczać skutki.
Tokeny techniczne z małym zakresem
Zapisz właściciela, cel, kolekcję, datę wygaśnięcia i sposób odwołania. Nie przechowuj wartości. Token nie powinien być wspólnym kluczem dla wszystkiego.
Przy nowej funkcji oceń, czy wymaga nowych praw. Nie dodawaj ich automatycznie dla demo. Test powinien potwierdzać odmowę przy innych kolekcjach.
Przy tokenach stosuj zasady z artykułu o administratorze AI. Rotacja i offboarding należą do procesu.
Odmowa przed poprawnym działaniem
Przygotuj fikcyjne zadanie, w którym dokument poleca agentowi otworzyć obcą kolekcję lub zmienić ustawienie. Sprawdź, czy narzędzie odmówi operacji bez wymaganej roli, a następnie wykonaj zwykły odczyt dozwolonego źródła.
W ścieżce wyszukiwania obejrzyj materiał przekazany do modelu, nie tylko końcową odpowiedź. Źródło spoza uprawnień nie powinno zostać pobrane ani zapisane w dostępnej agentowi historii lub raporcie diagnostycznym.
Przy odmowie zapisz status i skutek. Test powinien pokazywać brak operacji, a nie tylko komunikat błędu.
Odbiór człowieka przy skutku
Opisz, kiedy człowiek zatwierdza operację i co widzi: źródło, wersję, różnice, odbiorcę i ryzyko. Nie ograniczaj do ogólnego „sprawdź”. Odbiór powinien mieć kompetencje i czas.
Nie przenoś odpowiedzialności na przycisk akceptacji przy wielkim tekście. Przy krytycznych operacjach wymagaj osobnej decyzji i testu skutku.
Przy odbiorze stosuj zasady z artykułu o człowieku w pętli AI. Uprawnienia powinny być realne, a nie tylko zapisane.
Logi i historia bez pełnych danych
Zapisz identyfikator operacji, wersję, rolę, status i skutek. Nie loguj sekretów i pełnych treści. Historia powinna pozwalać odtworzyć działanie bez nowego wycieku.
Przy zmianie roli oceń, co zrobić ze starymi odpowiedziami i cache. Odebranie dostępu nie usuwa automatycznie pochodnych. Retencja wymaga osobnej decyzji.
Przy monitoringu stosuj zasady z artykułu o obserwacji błędów AI. Odmowa powinna być widoczna bez ujawniania treści.
Zastępstwo i nieobecność
Osoba zastępująca właściciela może potrzebować prawa do zatrzymania kolejki i odbioru wyników. Nadaj jej te działania oddzielnie od publikacji oraz sprawdź na fikcyjnym zadaniu, czy może wykonać swoją rolę.
Wykonaj test nieobecności. Zgłoszenie powinno trafić do zastępcy, a nie wracać do niedostępnego właściciela. Po powrocie zdecyduj o przekazaniu pracy.
Ogranicz czas dodatkowego dostępu. Po zakończeniu zastępstwa odbierz go i potwierdź odmowę.
Przykład: raport bez prawa zapisu
Wyobraź sobie agenta, który ma odpowiedzieć na pytanie na podstawie instrukcji z jednej kolekcji. Jeżeli jego narzędzie potrafi również zmieniać dokumenty, polecenie ukryte w źródle może doprowadzić do niezamierzonego zapisu.
Nadaj narzędziu wyłącznie odczyt wskazanej kolekcji. W próbie sprawdź zwykłe pytanie, żądanie edycji oraz dostęp do innego zbioru. Obejrzyj rzeczywisty stan dokumentów po każdym wywołaniu.
Przy takim przeglądzie pomocne są zasady z artykułu o przeglądzie uprawnień AI. Prawa powinny odpowiadać skutkowi.
Przykład: stary debug omija rolę
Wyobraź sobie, że po migracji agent zachował tryb podglądu wszystkich znalezionych dokumentów. Nawet jeśli odpowiedź końcowa jest ograniczona, panel diagnostyczny może ujawnić źródło osobie bez dostępu. Sprawdź tę ścieżkę przed ponownym uruchomieniem.
W kontrolowanej próbie użyj konta bez dostępu do źródła. Sprawdź zarówno treść odpowiedzi agenta, jak i podgląd dokumentu przekazany narzędziu. Po wyłączeniu trybu diagnostycznego powtórz oba kroki i zapisz wynik.
Jeżeli diagnostyka wymaga szerszego zakresu, przypisz ją konkretnej osobie i ustal czas wygaśnięcia. Po zakończeniu sprawdź, czy agent nie odziedziczył tych praw w kolejnych sesjach.
Przegląd według ryzyka
Zacznij od narzędzi pozwalających agentowi wysyłać wiadomości, publikować albo modyfikować dane. Dla każdego działania wskaż zasób oraz warunek zatwierdzenia. Odczyt źródeł także ogranicz do dokumentów potrzebnych w zadaniu.
W karcie agenta oddziel polecenia dozwolone od zabronionych i podaj właściciela zatwierdzenia. Sprawdź odmowę na obcym dokumencie oraz prawidłowy odczyt materiału, do którego agent ma dostęp.
Nowe narzędzie może inaczej rozumieć zakres jednego uprawnienia. Przed podłączeniem porównaj dostępne operacje z zadaniem agenta, a następnie przetestuj jego uprawnienia bez użycia rzeczywistych danych klientów.
Kiedy zatrzymać agenta
Zatrzymaj przy wycieku, nieznanym skutku, duplikatach zapisu i konflikcie ról. Nie czekaj na kolejny raport. Ogranicz nowe operacje.
Zatrzymując agenta, zapisz identyfikatory wywołań narzędzi, wersję konfiguracji i stan zadań. Osoba prowadząca incydent powinna ustalić, które działania już się wykonały, zanim podejmie decyzję o wznowieniu kolejki.
Po naprawie uruchom mały wolumen i sprawdź skutek. Wznowienie powinno być kontrolowane.
Zmiana roli człowieka to także zmiana uprawnień automatu
Kiedy opiekun agenta zmienia zadania, przejrzyj powiązane z nim integracje oraz kolejki zatwierdzeń. Ustal, kto przejmuje decyzje i czy wcześniejsza osoba nadal potrzebuje dostępu do narzędzi wykonujących działania w jej imieniu.
Nowy opiekun może odpowiadać za wstrzymanie kolejki bez prawa do publikowania szkiców. Przydziel te czynności osobno, jeżeli system to umożliwia. Na fikcyjnym zadaniu sprawdź dozwolony odbiór oraz odmowę publikacji. Ustal też, kto odwołuje poprzedni klucz i kiedy uprawnienie przestaje działać we wszystkich powiązanych narzędziach.
Dostęp awaryjny z datą wygaśnięcia
Do naprawy agenta przygotuj oddzielny, ograniczony czasowo dostęp. Zapisz, jakie narzędzie wolno uruchomić, kto zatwierdza wyjątek i kiedy trzeba go wyłączyć. Konto awaryjne nie powinno zastępować zwykłej roli w codziennej pracy.
Po zakończeniu pracy odwołaj dodatkowy dostęp i sprawdź log działań. Oceń, czy naprawa nie pozostawiła nowych tokenów lub publicznych eksportów. Przy kolejnym przeglądzie potwierdź, że konto nadal jest potrzebne i zabezpieczone.
Eksport i link publiczny omijają role
Przetestuj udostępnianie z konta osoby, która widzi wynik, ale nie ma dostępu do dokumentu źródłowego. Otwórz cytowanie, pobierz raport i sprawdź odnośnik w prywatnym oknie przeglądarki. Jeżeli kopia została już pobrana poza system, samo zamknięcie konta nie odzyska pliku; zapisz tę granicę w planie reakcji.
Przy raportach z modelem zobacz, czy odpowiedź zawiera dane z dokumentów niedostępnych dla odbiorcy. Uprawnienie do raportu nie powinno otwierać źródeł. Do testu użyj roli bez dostępu do oryginału i spróbuj przejść do cytowania.
Cache i historia konwersacji
Historia rozmowy może przechowywać odpowiedź wygenerowaną przed odebraniem uprawnienia. Sprawdź odrębnie nowe zapytanie, zapisany wątek i wcześniej udostępniony wynik. Ustal z właścicielem danych, kto może zachować te kopie i jak długo. Jeśli dostawca nie pozwala ograniczyć starej historii, zanotuj tę lukę przed użyciem wrażliwych źródeł.
Sprawdź oddzielnie świeże zapytanie oraz odpowiedź zapamiętaną przed zmianą roli. Jeśli system pozwala unieważnić zapisany wynik, wykonaj próbę po tej operacji. Ograniczenia historii przekaż właścicielowi danych wraz ze sposobem dalszego postępowania.
Przegląd z właścicielem procesu, nie tylko IT
Właściciel procesu określa, jaki wynik ma przygotować agent, a osoba techniczna sprawdza dostępne operacje narzędzia. Omówcie każdy zapis i eksport, którego potrzeby nie da się wskazać w zadaniu, zanim zostanie włączony.
Dla każdej operacji wpisz potrzebę biznesową, zakres zasobów, zatwierdzającego oraz dowód ostatniej próby. Przykładowy zapis brzmi: „odczyt tylko kolekcji instrukcji; publikacja wyłączona; odmowa zapisu sprawdzona na koncie testowym”. Nie umieszczaj wartości klucza w karcie. Właściciel procesu potwierdza potrzebę, a technik sprawdza ustawienie.
Mały scenariusz audytu od początku do końca
Weź przykładowego asystenta redakcji. Jego zadaniem jest utworzenie szkicu we wskazanym projekcie, a nie zarządzanie całym CMS. Przygotuj dwa testowe projekty i osobne konto bez uprawnień administratora. Spróbuj odczytać dozwolony artykuł, zapisać szkic oraz wskazać identyfikator obcego projektu w tym samym żądaniu.
Sprawdzenie tożsamości i upoważnienia po stronie narzędzia powinno następować przed działaniem. Dokument znaleziony przez agenta może zawierać polecenie zmiany roli, ale nie nadaje dostępu. NIST omawia tożsamość, delegowanie i autoryzację agentów jako obszary wymagające wspólnych praktyk bezpieczeństwa.
Po każdej próbie obejrzyj rzeczywisty stan obu projektów. Odmowa w odpowiedzi nie wystarcza, jeśli zapis nastąpił wcześniej. Następnie odwołaj testowy klucz i powtórz odczyt oraz zapis. Odnotuj opóźnienie, jeśli dostęp znika dopiero po pewnym czasie; nie zakładaj natychmiastowego unieważnienia wszystkich sesji.
Harmonogram zależny od zdarzeń
Datę kolejnego przeglądu dobierz do wrażliwości źródła i skutku działania. Dodatkowy przegląd uruchamia nowy dostęp do narzędzia, zmiana zakresu kolekcji lub przekazanie obowiązków. Zanotuj zmianę oraz osobę podejmującą decyzję. Harmonogram jest przypomnieniem, a nie dowodem, że konkretne uprawnienie pozostało potrzebne.
Po zmianie roli sprawdź poprawną operację, próbę na obcym zasobie i odmowę po odwołaniu klucza. Powtarzające się przywrócenie dostępu może wskazywać na synchronizację grup lub stary skrypt wdrożeniowy. Znajdź mechanizm, który go nadaje, i popraw źródło konfiguracji. Samo ręczne odebranie roli usuwa wtedy jedynie objaw.
Dowód ograniczenia dostępu
Dla każdej odebranej roli zachowaj zakres zmiany, datę, właściciela i wynik testu. Nie zapisuj sekretu ani pełnych danych, do których konto miało dostęp. Wystarczy identyfikator operacji i informacja, że próba zapisu lub odczytu została odrzucona. Przy następnym przeglądzie sprawdź, czy uprawnienie nie wróciło przez synchronizację albo nową integrację.
To ważny szczegół: odmowa dzisiaj nie jest wiecznym zabezpieczeniem. Systemy lubią przywracać stare konfiguracje z równym entuzjazmem co dokumenty z kosza. Jeżeli dostęp wrócił, sprawdź źródło synchronizacji i zatrzymaj regułę, zamiast ręcznie odbierać tę samą rolę co tydzień. Powtarzalny problem wymaga poprawki procesu, nie coraz szybszego klikania w panelu.
Minimalna karta roli agenta
Zapisz zadanie, źródła, operacje dozwolone, operacje zabronione, odbiór i właściciela. Dodaj datę wygaśnięcia tokenu i test odmowy. Nie przechowuj wartości sekretów ani pełnych dokumentów. Karta ma prowadzić do konkretnego zachowania.
Przy nowej funkcji zaktualizuj ją przed uruchomieniem. Jeżeli agent nie potrzebuje zapisu, zostaw go wyłączony. Odbiór powinien potwierdzać, że ograniczenie działa, a nie tylko jest zapisane.
Zakres działań agenta można przeanalizować z Aeneia Audit. Przykłady pytań o dostęp do narzędzi zawiera także przewodnik Aeneia Signal.
Dobre uprawnienia pozwalają wykonać zadanie i nic ponad to. Agent nie potrzebuje administratora dla każdego dokumentu. Odmowa jest częścią procesu, nie awarią.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
