Checklista uprawnień agenta AI w firmie

Krótka odpowiedź

Agentowi AI dajcie dostęp tak, jak nowemu pracownikowi na okresie próbnym: własne konto zamiast cudzego hasła, tylko te systemy i dane, których wymaga jedno konkretne zadanie, a na start najlepiej sam odczyt. Wysyłanie wiadomości, płatności, usuwanie i publikowanie zostawcie do zatwierdzenia przez człowieka. Włączcie zapis działań agenta i ustalcie, kto i jak odbiera mu dostęp, zanim będzie potrzebny.

To nie jest nasz wymysł. Te same zasady powtarzają się w źródłach, które przeczytaliśmy: OWASP opisuje nadmierną sprawczość agenta (Excessive Agency) jako podatność wynikającą ze zbyt wielu funkcji, uprawnień i zbyt dużej autonomii. NIST definiuje zasadę najmniejszych uprawnień, a dokumentacja Claude Code i Codex pokazuje, jak w praktyce ustawić zgody i blokady.

Poniżej jest pięć list kontrolnych: dostępy i konta, dane, akcje wymagające zgody człowieka, logi i nadzór, wyłączenie i odebranie dostępu. Na końcu wersja tekstowa do skopiowania i najczęstsze pytania. Tekst opiera się wyłącznie na źródłach podlinkowanych na dole, według stanu na 17.10.2026. Nie jest poradą prawną.

Skąd pomysł: agent zarządzany jak pracownik

Impulsem był komunikat Workday z 13 października 2026 r. o agentach działających w tle w HR, finansach i IT. Firma pisze, że jej agenci dziedziczą zasady, uprawnienia i reguły zatwierdzania obowiązujące w firmie klienta. To klient decyduje, które działania agent może wykonać sam, które wymagają przeglądu i kiedy ostatnie słowo należy do człowieka. Każde działanie agenta jest zapisywane: co zrobił, z jakich informacji skorzystał i kto je zatwierdził. W przykładzie z rekrutacji wyszukiwanie kandydatów działa w tle, ale wiadomość do kandydata wymaga zgody rekrutera, zanim cokolwiek zostanie wysłane.

Sam pomysł zarządzania agentami jak pracownikami Workday ogłosił już 11 lutego 2025 r., zapowiadając Agent System of Record: wdrażanie agentów ze zdefiniowaną rolą i bezpiecznym dostępem do danych, kontrolę dostępu i monitorowanie ich aktywności. Na stronie produktu Workday opisuje, że każdy agent ma własną tożsamość do uwierzytelniania, autoryzacji i audytu, a cykl życia agenta obejmuje rejestrację, konfigurację, aktywację, dezaktywację i archiwizację.

Mała firma nie potrzebuje do tego platformy dla korporacji. Potrzebuje tych samych pytań, które zadaje się przy zatrudnianiu: do czego ta osoba ma dostęp, czego nie może zrobić bez zgody, kto sprawdza jej pracę i co się dzieje w dniu odejścia. Nie testowaliśmy produktów Workday i nie oceniamy ich. Komunikat traktujemy jako punkt wyjścia.

Dlaczego agent potrzebuje ograniczeń, a nie tylko dobrego promptu

OWASP Top 10 dla aplikacji LLM (wersja 2025) opisuje ryzyko LLM06 Excessive Agency: szkodliwe działania wykonane w odpowiedzi na nieoczekiwane, niejednoznaczne lub zmanipulowane wyniki modelu, niezależnie od przyczyny błędu. Wśród przyczyn OWASP wymienia halucynacje i prompt injection, a jako źródło problemu: nadmiar funkcji, nadmiar uprawnień i nadmiar autonomii. Przykład z dokumentu: wtyczka miała tylko czytać dokumenty, ale pozwalała też je zmieniać i usuwać.

Drugie ryzyko to LLM01 Prompt Injection. W wariancie pośrednim polecenia trafiają do modelu z zewnętrznych treści, na przykład ze strony internetowej albo pliku. OWASP pisze, że nie jest jasne, czy istnieją niezawodne metody zapobiegania tej podatności. Dlatego wśród środków ograniczających skutki wymienia najmniejsze uprawnienia i zgodę człowieka na operacje wysokiego ryzyka. OpenAI w przewodniku o bezpieczeństwie agentów pisze podobnie: nawet z zabezpieczeniami agent może popełnić błąd albo dać się oszukać, więc trzeba ostrożnie decydować, jaki dostęp mu dajecie.

Wniosek praktyczny: instrukcja w prompcie to prośba, a uprawnienie to granica. Dokumentacja Claude Code mówi to wprost. Reguły uprawnień egzekwuje narzędzie, nie model, a instrukcje w prompcie czy pliku CLAUDE.md wpływają na to, co agent próbuje zrobić, ale nie zmieniają tego, na co narzędzie pozwala.

Prompt injection: kiedy dokument próbuje wydawać polecenia agentowi →

1. Dostępy i konta

Punkt wyjścia to definicja NIST: system powinien ograniczać uprawnienia użytkowników, a także procesów działających w ich imieniu, do minimum potrzebnego do wykonania przydzielonych zadań. Agent AI jest właśnie takim procesem. OWASP przekłada to na agentów: dawać tylko potrzebne rozszerzenia (narzędzia), w każdym tylko potrzebne funkcje, z minimalnymi uprawnieniami w systemach docelowych.

Przykład z OWASP: asystent, który ma streszczać pocztę, potrzebuje tylko odczytu wiadomości. Nie powinien mieć funkcji usuwania ani wysyłania, a do skrzynki powinien łączyć się przez OAuth z zakresem tylko do odczytu.

MCP w firmie: jak połączyć rozmowę z danymi o zamówieniu →

2. Dane

Jeśli agent widzi dane osobowe klientów albo pracowników, w grę wchodzi RODO. Art. 5 ust. 1 lit. c wymaga minimalizacji danych: dane mają być ograniczone do tego, co niezbędne do celu. Art. 25 ust. 2 mówi o domyślnej ochronie danych: domyślnie przetwarzane mają być tylko dane niezbędne do konkretnego celu, co dotyczy ich ilości, zakresu przetwarzania, okresu przechowywania i dostępności. Art. 32 wymaga środków bezpieczeństwa adekwatnych do ryzyka, w tym ochrony przed nieuprawnionym ujawnieniem i dostępem.

OpenAI zwraca uwagę na drugi problem: wyciek danych bez udziału atakującego. Model może wysłać do podłączonego narzędzia (MCP) więcej danych, niż użytkownik zamierzał, a nad tym, co model postanowi przekazać, nie ma się pełnej kontroli. Najprostsza ochrona to nie dawać agentowi dostępu do danych, których zadanie nie wymaga.

3. Akcje wymagające zgody człowieka

OWASP zaleca kontrolę typu human-in-the-loop: człowiek zatwierdza działania o dużym wpływie, zanim zostaną wykonane. Przykład z dokumentu: aplikacja, która tworzy i publikuje posty w mediach społecznościowych, powinna mieć krok zatwierdzenia w samej operacji publikacji. OWASP dodaje zasadę pełnej mediacji: o tym, czy działanie jest dozwolone, decyduje system docelowy, a nie model.

Narzędzia mają na to gotowe ustawienia. W Claude Code reguły dzielą się na allow, ask i deny, sprawdzane w kolejności: deny, potem ask, potem allow. Reguła ask wymusza pytanie o zgodę nawet wtedy, gdy węższa reguła allow pasuje do tego samego wywołania. W Codex tryb Auto, zalecany przy folderach z kontrolą wersji, pyta o zgodę przy edycji plików poza katalogiem roboczym i przy dostępie do sieci, a wywołania narzędzi aplikacji i MCP oznaczonych jako destrukcyjne zawsze wymagają zatwierdzenia. OpenAI w przewodniku o agentach zaleca włączone zatwierdzanie narzędzi MCP, tak żeby użytkownik mógł przejrzeć i potwierdzić każdą operację.

n8n: pokaż gotowego maila przed naciśnięciem „Wyślij” →

4. Logi i nadzór

OWASP zaznacza, że logowanie i monitorowanie nie zapobiega nadmiernej sprawczości, ale ogranicza szkody: pozwala zauważyć niepożądane działania i zareagować. To samo dotyczy limitów liczby operacji w czasie, które dają więcej czasu na wykrycie problemu, zanim szkoda urośnie.

W Codex telemetria OpenTelemetry jest domyślnie wyłączona. Po włączeniu zapisuje m.in. decyzje o zatwierdzeniu narzędzi (zatwierdzone lub odrzucone, z informacją, czy decyzja pochodziła z konfiguracji, czy od użytkownika) i wyniki wywołań narzędzi. Dokumentacja zaleca, żeby nie zapisywać treści promptów bez wyraźnej zgody polityki firmy, wysyłać dane tylko do własnych kolektorów i regularnie przeglądać zdarzenia pod kątem zmian w zgodach i nieoczekiwanych wywołań. NIST AI RMF w funkcji MANAGE zaleca m.in. monitorowanie systemu po wdrożeniu i prowadzenie rejestru błędów, incydentów i zmian w systemie.

5. Wyłączenie i odebranie dostępu

NIST AI RMF (MANAGE 2.4) zaleca, żeby istniały mechanizmy i przypisana odpowiedzialność za zastąpienie, odłączenie lub wyłączenie systemu AI, który działa niezgodnie z przeznaczeniem. Wśród sugerowanych działań są: ustalone progi, po których system się wyłącza, plan zapasowy na czas wyłączenia, zachowanie materiałów do analizy i przegląd przyczyn po każdym takim zdarzeniu. MANAGE 2.3 dodaje sprawdzenie procedur awaryjnych i wycofanie systemów, które przekraczają akceptowalny poziom ryzyka.

W Claude Code reguła deny z samą nazwą narzędzia usuwa je z kontekstu agenta, a reguł uprawnień z ustawień zarządzanych przez administratora nie da się nadpisać na żadnym innym poziomie. Te same ustawienia pozwalają zablokować tryb bypassPermissions, który pomija pytania o zgodę, i tryb auto, w którym zamiast pytań działa klasyfikator. Odebranie dostępu warto przećwiczyć na sucho, zanim będzie potrzebne naprawdę.

Jak to ustawić w Claude Code i Codex

Claude Code ma tryby uprawnień: default (w interfejsie nazywany „Manual”; pyta o zgodę przy pierwszym użyciu każdego narzędzia), acceptEdits, plan (tylko czytanie i polecenia tylko do odczytu), auto (bez rutynowych pytań; zamiast nich klasyfikator w tle sprawdza m.in. polecenia i żądania sieciowe), dontAsk i bypassPermissions. Dokumentacja zaleca bypassPermissions tylko w odizolowanych środowiskach, takich jak kontenery czy maszyny wirtualne. Reguły zapisuje się w pliku settings.json. Blok poniżej to połączenie dwóch przykładów z dokumentacji: reguły z pierwszego pozwalają bez pytania uruchamiać dowolne npm run (czyli każdy skrypt z package.json) i commity, a blokują git push; reguła z drugiego, Read(./.env), blokuje odczyt pliku .env wbudowanymi narzędziami i komendami, które Claude Code rozpoznaje, np. cat. Nie blokuje poleceń, które czytają pliki bez podania ich nazwy, np. grep -r, ani skryptów Python czy Node uruchomionych przez agenta. Do tego służy sandbox, egzekwowany przez system operacyjny i domyślnie wyłączony (włącza go /sandbox albo sandbox.enabled): Claude Code dołącza reguły deny dla Read do konfiguracji sandboxa, więc ten sam plik jest zablokowany także dla poleceń uruchamianych w sandboxie; to samo da się ustawić przez sandbox.filesystem.denyRead. Sam sandbox bez takiej reguły nie chroni .env, bo domyślnie pozwala czytać większość komputera, w tym pliki z danymi logowania. Katalog roboczy też nie jest granicą: polecenia tylko do odczytu, jak cat, czytają pliki poza nim bez pytania, chyba że włączycie permissions.blockReadsOutsideWorkingDirectories. Najbezpieczniej trzymać sekrety poza repozytorium i poza maszyną, na której działa agent. Dokumentacja dodaje, że reguła Bash dopasowuje tekst komendy, więc ten sam program wywołany inaczej może jej nie podlegać.

Codex łączy dwie warstwy: tryb piaskownicy (co agent może technicznie zrobić, np. gdzie pisać i czy ma sieć) i politykę zatwierdzania (kiedy musi zapytać). Lokalnie domyślnie nie ma dostępu do sieci, a zapis jest ograniczony do katalogu roboczego. Do samego czytania i planowania służy tryb read-only. Tryb --dangerously-bypass-approvals-and-sandbox (alias --yolo) wyłącza i piaskownicę, i zgody; dokumentacja go nie zaleca. Codex może też zapisywać transkrypty sesji lokalnie w pliku history.jsonl w katalogu CODEX_HOME; jeśli nie chcecie ich przechowywać, ustawcie history.persistence = "none".

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

RODO i AI Act: co z tego wynika dla małej firmy

RODO nie mówi nic o agentach, ale jego zasady pasują do nich wprost: minimalizacja danych (art. 5), domyślna ochrona danych (art. 25), bezpieczeństwo przetwarzania (art. 32) i umowa z podmiotem przetwarzającym (art. 28). Jeśli agent ma dostęp do danych osobowych, te artykuły są dobrym punktem wyjścia do rozmowy z osobą, która odpowiada w firmie za ochronę danych. Jeśli narzędzie agenta przekazuje dane osobowe do państwa trzeciego, czyli poza EOG, obowiązują warunki z rozdziału V RODO (art. 44 i następne), np. decyzja Komisji stwierdzająca odpowiedni stopień ochrony (art. 45).

Praktyczny punkt wyjścia daje UODO. 6 sierpnia 2026 r. urząd opublikował „Listy pytań inicjalnych”, w tym checklistę RODO dla małych i średnich firm korzystających z gotowych narzędzi AI. Są w niej m.in. pytania o umowę powierzenia z dostawcą (art. 28), o to, gdzie dostawca przechowuje dane i czy przekazuje je poza UE (art. 44–49), czy może trenować modele na wprowadzanych danych i jak długo przechowuje historię rozmów. UODO zaznacza, że listy nie są wiążącą wykładnią przepisów i nie zastępują analizy ryzyka ani oceny skutków dla ochrony danych.

AI Act rozróżnia obowiązki. Art. 4 o kompetencjach w zakresie AI stosuje się od 2 lutego 2025 r. (art. 113 lit. a) i dotyczy także podmiotów stosujących, czyli firm korzystających z gotowych narzędzi. Szczegółowe obowiązki z art. 26, takie jak nadzór człowieka z odpowiednimi kompetencjami i przechowywanie rejestrów zdarzeń przez co najmniej sześć miesięcy, dotyczą systemów AI wysokiego ryzyka. Do nich należy m.in. AI używana do rekrutacji i oceny kandydatów (załącznik III pkt 4). Według skonsolidowanego tekstu art. 113 przepisy o systemach wysokiego ryzyka z załącznika III stosuje się od 2 grudnia 2027 r. Agent, który porządkuje faktury albo szkicuje odpowiedzi na maile, zwykle nie jest systemem wysokiego ryzyka, ale ocenę warto zrobić dla każdego zastosowania osobno.

Terminy AI Act i polskiej ustawy o systemach sztucznej inteligencji opisaliśmy w osobnym tekście.

Ustawa o systemach sztucznej inteligencji: obowiązki firm. Checklista →

Checklista uprawnień agenta AI do skopiowania

Wersja tekstowa wszystkich list. Wklejcie ją do dokumentu, w którym opisujecie agenta, i odhaczajcie przed jego uruchomieniem oraz przy każdym przeglądzie. Źródła poszczególnych punktów są w sekcjach powyżej.

CHECKLISTA UPRAWNIEŃ AGENTA AI
Agent: ____________  Zadanie: ____________  Odpowiada: ____________  Data: ________

1. DOSTĘPY I KONTA
[ ] Osobne konto / klucz API / token agenta (nie konto pracownika)
[ ] Jedno zadanie i lista potrzebnych narzędzi; reszta wyłączona
[ ] Narzędzia tylko z potrzebnymi funkcjami (np. odczyt bez wysyłania)
[ ] OAuth z najwęższym zakresem (np. tylko odczyt)
[ ] Konta w systemach tylko z potrzebnymi prawami (bez usuwania)
[ ] Brak otwartych narzędzi (dowolna komenda, dowolny URL), jeśli wystarczy węższe
[ ] Usunięte narzędzia po testach
[ ] Start w trybie tylko do odczytu lub z pytaniem o zgodę

2. DANE
[ ] Dostęp tylko do potrzebnych folderów, tabel, skrzynek
[ ] Hasła, klucze, pliki .env najlepiej poza repozytorium i maszyną agenta
    (katalog roboczy nie jest granicą; sandbox domyślnie czyta większość dysku)
[ ] Claude Code: reguła deny Read(./.env) i włączony sandbox
    (sama reguła nie blokuje np. grep -r ani skryptów agenta;
    w sandboxie obejmuje też polecenia w terminalu)
[ ] Dane osobowe tylko, gdy są niezbędne; inaczej pseudonimizacja
[ ] Umowa powierzenia z dostawcą, jeśli przetwarza dane osobowe
[ ] Wiadomo, gdzie dostawca trzyma dane i czy przekazuje je poza EOG
[ ] Treści z zewnątrz traktowane jako niezaufane
[ ] Ustalony okres przechowywania rozmów i logów

3. AKCJE WYMAGAJĄCE ZGODY CZŁOWIEKA
[ ] Wysyłka maili i wiadomości: agent szkicuje, człowiek wysyła
[ ] Płatności, przelewy, zwroty: zgoda albo brak dostępu
[ ] Usuwanie danych: potwierdzenie człowieka
[ ] Publikacja na zewnątrz: krok akceptacji
[ ] Zmiana uprawnień i ustawień bezpieczeństwa: tylko człowiek
[ ] Blokady ustawione w systemie lub narzędziu, nie tylko w prompcie
[ ] Tryby bez pytania o zgodę wyłączone poza odizolowanym środowiskiem

4. LOGI I NADZÓR
[ ] Log: co agent zrobił, jakim narzędziem, kto zatwierdził
[ ] Logi u nas, z ograniczonym dostępem i okresem przechowywania
[ ] Treść promptów w logach domyślnie ukryta
[ ] Limity operacji w czasie, jeśli narzędzie pozwala
[ ] Osoba odpowiedzialna i regularny przegląd
[ ] Rejestr błędów i zmian w konfiguracji
[ ] Ocena, czy to system wysokiego ryzyka (AI Act, np. rekrutacja)

5. WYŁĄCZENIE I ODEBRANIE DOSTĘPU
[ ] Wiadomo, kto i jak wyłącza agenta
[ ] Lista kluczy, tokenów i kont do unieważnienia
[ ] Ustalone sytuacje, w których agent jest wyłączany
[ ] Proces działa ręcznie na czas wyłączenia
[ ] Logi zachowane do analizy po wyłączeniu
[ ] Regularny przegląd i odbieranie nieużywanych uprawnień
[ ] Wyłączenie i archiwizacja po zakończeniu projektu

Najczęstsze pytania

Jakie uprawnienia dać agentowi AI na start? Najmniejsze, które pozwalają wykonać jedno konkretne zadanie, najlepiej tylko odczyt. NIST definiuje zasadę najmniejszych uprawnień jako ograniczenie dostępu użytkowników i procesów działających w ich imieniu do minimum potrzebnego do zadania. OWASP zaleca minimalizowanie narzędzi, ich funkcji i uprawnień agenta.

Czy agent AI powinien mieć osobne konto? Tak. Osobne konto lub token pozwala ograniczyć zakres dostępu, odróżnić w logach działania agenta od działań ludzi i odebrać dostęp bez zmiany haseł pracowników. Workday opisuje w swojej platformie osobną tożsamość każdego agenta do uwierzytelniania, autoryzacji i audytu. OWASP odradza łączenie się agenta z systemami przez ogólne konto z szerokimi uprawnieniami.

Które działania agenta wymagają zgody człowieka? Te o dużym wpływie i trudne do cofnięcia: wysyłanie wiadomości na zewnątrz, płatności, usuwanie danych, publikacja i zmiana uprawnień. OWASP zaleca zatwierdzanie przez człowieka działań o dużym wpływie, a OpenAI zaleca włączone zatwierdzanie wywołań narzędzi MCP.

Czy wystarczy napisać w prompcie, czego agentowi nie wolno? Nie. Dokumentacja Claude Code mówi, że reguły uprawnień egzekwuje narzędzie, a nie model, a instrukcje w prompcie nie zmieniają tego, na co narzędzie pozwala. OWASP pisze, że nie jest jasne, czy istnieją niezawodne metody zapobiegania prompt injection, dlatego granice trzeba ustawić w systemach.

Co powinien zawierać log działań agenta? Co agent zrobił, jakim narzędziem, z jakim wynikiem i kto zatwierdził akcję. Workday opisuje taki zakres zapisu w swoim komunikacie, a Codex po włączeniu telemetrii zapisuje decyzje o zatwierdzeniu i wyniki wywołań narzędzi. Treści promptów lepiej domyślnie nie zapisywać, bo mogą zawierać dane wrażliwe.

Czy AI Act nakłada obowiązki na firmę, która używa agenta AI? Art. 4 o kompetencjach w zakresie AI dotyczy także podmiotów stosujących i stosuje się od 2 lutego 2025 r. Obowiązki z art. 26, w tym nadzór człowieka i przechowywanie rejestrów zdarzeń przez co najmniej sześć miesięcy, dotyczą systemów wysokiego ryzyka, np. w rekrutacji, i według art. 113 stosuje się je do systemów z załącznika III od 2 grudnia 2027 r. To nie jest porada prawna.

Jak szybko odebrać agentowi dostęp? Przygotujcie to przed uruchomieniem: listę kont, kluczy i tokenów agenta, osobę, która może go wyłączyć, i ręczny zastępczy sposób wykonania pracy. NIST AI RMF zaleca mechanizmy i przypisaną odpowiedzialność za wyłączenie systemu AI, który działa niezgodnie z przeznaczeniem.