Wiedza
Najmniejsze uprawnienia dla agentów AI: agent nie potrzebuje „dostępu do API”. Potrzebuje dostępu do konkretnej pracy
Najczęstszy skrót w prototypie brzmi: dajmy agentowi token, pokażmy wszystkie narzędzia i ograniczmy go promptem. To przyspiesza demo. W produkcji tworzy jednak problem: intencja opisana w promptach staje się jedyną barierą między błędem modelu a pełnymi możliwościami konta.
Zasada najmniejszych uprawnień dla agenta nie kończy się na roli read-only. Trzeba ograniczyć co najmniej pięć rzeczy: narzędzia, typ operacji, zasób, dane oraz czas/tożsamość dostępu.
1. Ogranicz zestaw narzędzi
Agent analizujący kampanie reklamowe nie potrzebuje funkcji zarządzania użytkownikami. Agent przygotowujący raport zgodności nie potrzebuje arbitralnego shell access. Agent porządkujący pliki w jednym katalogu nie potrzebuje całego filesystemu.
Im szerszy katalog funkcji, tym większa powierzchnia:
- błędnego wyboru narzędzia;
- prompt injection prowadzącego do niepożądanej akcji;
- trudnej do zauważenia kombinacji narzędzi;
- przypadkowego ujawnienia danych;
- błędu konfiguracji po stronie modelu.
Dlatego pierwsze pytanie nie brzmi „co API potrafi?”, tylko:
które trzy lub pięć operacji są agentowi potrzebne do tej konkretnej pracy?
Reszta może być niewidoczna.
2. Rozdziel odczyt, zapis, uruchomienie skutku i destrukcję
Samo „ma dostęp do kampanii” jest zbyt szerokie.
W naszych narzędziach sensowniejszy jest model operacyjny:
| Zakres | Znaczenie | Przykład |
|---|---|---|
read |
odczyt stanu i raportów | pobierz koszt, status, listę zasobów |
write |
przygotuj lub zmień konfigurację | utwórz draft, zmień nazwę, ustaw parametr |
operate |
uruchom skutek biznesowy | włącz kampanię, opublikuj, rozpocznij synchronizację |
destructive |
usuń, odłącz, unieważnij | usuń zasób, odbierz dostęp, wykonaj nieodwracalną zmianę |
Dzięki temu agent może przygotować konfigurację bez prawa do jej aktywowania. Może odczytać billing bez prawa do zmiany ustawień płatności. Może utworzyć draft wiadomości bez prawa do wysłania.
To właśnie w tej granicy zwykle mieści się najbardziej użyteczna autonomia.
3. Scope narzędzia to za mało — ogranicz również zasób
Uprawnienie:
campaign.write
jest nadal szerokie, jeśli operator ma dziesięć kont, a agent powinien działać tylko na jednym.
Tam, gdzie to możliwe, autoryzacja powinna uwzględniać:
kto
+ który agent
+ jaka funkcja
+ jaki typ operacji
+ jaki tenant/konto/projekt
+ jaki zasób
+ w jakim kontekście zadania
W wewnętrznym Brillnet Ads MCP wywołania wymagają jawnego identyfikatora klienta/konta w dozwolonym zakresie. Ogólne zapytanie nie powinno samo „zgadywać”, na którym koncie ma pracować.
Taki model jest szczególnie ważny w SaaS multi-tenant. Błąd wyboru tenanta może być poważniejszy niż błąd merytoryczny samego modelu.
4. Ogranicz dane wejściowe i wyjściowe
Najmniejsze uprawnienia dotyczą również danych.
Agent może potrzebować:
- sumy kosztów, ale nie pełnej listy danych użytkowników;
- statusu zadania, ale nie załączników;
- informacji, czy credential istnieje, ale nie jego wartości;
- identyfikatora osoby, ale nie pełnego profilu;
- wybranych pól dokumentu, a nie całego repozytorium.
Jeżeli narzędzie może zwrócić minimalny obiekt, zwracaj minimalny obiekt. Nie dostarczaj modelowi pełnego payloadu tylko dlatego, że API go udostępnia.
Ta sama zasada działa przy logach: audyt ma zawierać wystarczający dowód, nie kopię całych danych.
Więcej: Ślad audytowy agentów AI
5. Credential nie powinien żyć dłużej i szerzej, niż musi
Długowieczny token administratora w zmiennej środowiskowej każdego komponentu jest prosty. Jest też bardzo trudny do bezpiecznego ograniczenia.
Preferujemy wzorzec:
agent nie dostaje sekretu
↓
gateway potwierdza tożsamość + scope + zasób
↓
dopiero wtedy pobiera/uzyskuje krótkotrwały credential
↓
wykonuje jedno dozwolone wywołanie
↓
sekret nie trafia do odpowiedzi ani audytu
Wewnętrzny Ads MCP korzysta z krótkotrwałych tokenów dostawcy uzyskiwanych przy wywołaniu. Credential material jest obsługiwany poza kontekstem modelu i nie jest zapisywany w logach aplikacji.
Uprawnienie powinno być sprawdzane przy każdym żądaniu
Agent mógł rozpocząć zadanie, gdy operator miał określoną rolę. Dziesięć minut później rola mogła zostać odebrana. Długie workflow nie powinno zakładać, że uprawnienie z początku sesji nadal obowiązuje.
Dla operacji istotnych sprawdzamy aktualną decyzję autoryzacyjną przy wywołaniu narzędzia.
To samo dotyczy approval. Zgoda na jedno działanie nie jest uprawnieniem do dowolnych następnych działań.
Prompt nie jest ACL-em
Instrukcja:
możesz tylko czytać dane i nigdy niczego nie usuwaj
może być użyteczną regułą zachowania. Nie zastępuje jednak kontroli, która technicznie blokuje DELETE.
Jeżeli model ma dostęp do narzędzia destrukcyjnego i credentiala z prawem usuwania, to możliwość istnieje. Prompt jedynie prosi, żeby jej nie używać.
Dlatego praktyczny podział jest następujący:
- prompt: co agent powinien robić;
- authorization/policy: co agent może zrobić;
- provider/API role: co konto technicznie może zrobić u dostawcy.
Najbezpieczniej, gdy wszystkie trzy warstwy są spójne, ale nie zależą od siebie jak od jednego punktu kontroli.
Profile zamiast jednego super-agenta
W naszym wewnętrznym narzędziu reklamowym rozdzielamy profile: odczyt/planowanie, zarządzanie kampanią i zakres właścicielski dla rzadkich operacji administracyjnych.
Nie chodzi o nazwy. Chodzi o to, żeby zwykła analiza nie działała stale z najwyższym poziomem uprawnień.
Analogiczny układ w innym systemie może wyglądać tak:
research-agent
- search
- read
- summarize
operations-agent
- read
- create draft
- update approved fields
admin workflow
- separate invocation
- separate identity/scope
- mandatory approval
- narrow time window
Wtedy kompromitacja lub błąd jednego agenta nie automatycznie daje dostęp do wszystkich klas operacji.
Ogranicz filesystem i „uniwersalne” narzędzia
Dwa typy narzędzi wymagają szczególnej uwagi:
Shell / command execution
Pełny shell omija większość modelu narzędziowego. Jeżeli agent może uruchomić dowolną komendę jako użytkownik z szerokim dostępem, precyzyjne scopes innych narzędzi mają ograniczoną wartość.
Lepsze są narzędzia celowe albo allowlisty komend/operacji, uruchamiane w ograniczonym środowisku.
Filesystem
Agent, który ma zapisać raport do /workspace/reports, nie potrzebuje /etc, katalogu domowego operatora i sekretów CI.
W wewnętrznym Ads MCP ścieżki plików są ograniczane do zatwierdzonych lokalizacji lub bounded payloads. Arbitralna ścieżka systemowa jest odrzucana.
Niskopoziomowy gateway też musi mieć scope
Czasem potrzebujemy ogólnego gatewayu do nowych endpointów, zanim powstanie dedykowane narzędzie. Taka funkcja nie może być „escape hatchem”.
Powinna klasyfikować:
- HTTP method;
- endpoint;
- resource;
- charakter payloadu;
- to, czy operacja jest zapisem lub destrukcją.
Dopiero potem dopasowuje wymagane zakresy.
Jeśli raw_request ma pełny token i nie sprawdza polityki, jest de facto uprawnieniem administratorskim niezależnie od tego, jak dobrze ograniczyliśmy resztę narzędzi.
Dostęp tymczasowy do operacji wysokiego ryzyka
Zamiast stale przyznawać szeroki scope można zastosować wzorzec podniesienia uprawnień:
- agent przygotowuje operację;
- gateway wykrywa wymagany wyższy poziom;
- człowiek zatwierdza dokładne parametry;
- system wydaje ograniczone uprawnienie tylko do tej operacji lub na krótki czas;
- po wykonaniu uprawnienie wygasa;
- audyt zapisuje approval i rezultat.
To nie zawsze jest potrzebne. Dla operacji krytycznych ogranicza jednak czas, w którym szerokie uprawnienie jest aktywne.
Więcej: Kiedy agent AI wymaga zatwierdzenia człowieka?
Szablon inwentaryzacji capabilities
Przed produkcją warto rozpisać tabelę:
| Agent / workflow | Narzędzie | Operacja | Zasób | Dane | Approval | Credential | Audit |
|---|---|---|---|---|---|---|---|
| raport kampanii | Ads report | read | konto A | metryki bez PII | nie | short-lived | tak |
| przygotowanie kampanii | campaign tool | write | konto A | konfiguracja | nie/warunkowo | short-lived | tak |
| uruchomienie kampanii | campaign operate | operate | kampania X | budżet + status | tak | short-lived | tak |
| usunięcie zasobu | admin tool | destructive | konkretny zasób | minimum | tak | elevated | tak |
Ta tabela jest znacznie bardziej użyteczna niż ogólny zapis „agent ma dostęp do Google Ads”.
Antywzorce
Jeden klucz API dla całego systemu
Brak rozdzielenia ról i trudne odwołanie dostępu konkretnego workflow.
Ten sam zestaw narzędzi dla wszystkich agentów
Najszersza funkcja dostępna w katalogu staje się częścią powierzchni ryzyka każdego agenta.
„Read-only” po stronie promptu
Jeżeli backend nadal przyjmie zapis, read-only jest życzeniem, nie kontrolą.
Automatyczne rozszerzenie scope przy błędzie 403
Brak uprawnienia jest sygnałem do zatrzymania i decyzji, nie do „spróbuj z adminem”.
Credential w kontekście modelu
Model nie potrzebuje wartości sekretu, żeby poprosić zaufany gateway o dozwolone wywołanie.
Checklista least privilege dla agenta
- Agent widzi tylko narzędzia potrzebne do swojej roli.
- Read i write są rozdzielone.
- Skutek operacyjny ma osobny scope od przygotowania konfiguracji.
- Operacje destrukcyjne mają dodatkową barierę.
- Uprawnienie jest ograniczone do tenant/konta/projektu/zasobu.
- Nie ma automatycznego „zgadywania” zasobu przy niejednoznaczności.
- Narzędzia zwracają minimalny potrzebny zakres danych.
- Credentiale są poza kontekstem modelu.
- Tokeny są możliwie krótkotrwałe.
- Scope jest sprawdzany przy wykonaniu, nie tylko na początku sesji.
- Filesystem i shell są ograniczone lub zastąpione celowymi narzędziami.
- Raw gateway nie omija polityki.
- Podniesienie uprawnień jest jawne i audytowalne.
- Dostęp da się centralnie odwołać.
Źródła
- OWASP AI Agent Security Cheat Sheet
- OWASP MCP Top 10 — Insufficient Authentication & Authorization
- Model Context Protocol — 2026-07-28 Specification
Granica
Zasada najmniejszych uprawnień zmniejsza możliwy skutek błędu lub nadużycia. Nie gwarantuje, że dozwolona operacja będzie merytorycznie poprawna. Dlatego łączymy ją z walidacją danych, kontrolą operacji wysokiego ryzyka i śladem audytowym.
Wróć do przewodnika o bezpiecznych agentach AI albo zobacz Bezpieczeństwo Brillnet.