Wiedza

Bezpieczna automatyzacja AI w firmie: agent nie powinien mieć więcej władzy, niż potrzebuje do zadania

Autor: Piotr AdamskiOpublikowano: 12 września 2026

Agent AI może wyszukać dane, przygotować zmianę, wywołać API i wykonać pracę, która wcześniej wymagała kilku ekranów oraz ręcznych kroków. To jest użyteczne. Ten sam mechanizm sprawia jednak, że źle zaprojektowany agent może szybciej wykonać również błędną operację.

Dlatego zaczynamy od prostego założenia: model może proponować i wykonywać działania tylko w granicach, które system potrafi sprawdzić niezależnie od modelu. Im większy skutek operacji, tym mniej powinniśmy polegać na samej ocenie modelu.

W praktyce oznacza to cztery pytania:

Do jakich narzędzi i danych agent naprawdę potrzebuje dostępu?
Które działania może wykonać sam, a które wymagają zatwierdzenia człowieka?
Jak sprawdzić, co agent faktycznie zrobił, a nie tylko co odpowiedział w rozmowie?
Jak odtworzyć decyzję po tygodniu lub pół roku bez szukania jej w logach pięciu systemów?

Ta część serwisu Brillnet opisuje nasze odpowiedzi na te pytania. Są to wzorce projektowe wynikające z własnej pracy z API, MCP, automatyzacją i systemami, w których potrzebny jest późniejszy dowód działania. Nie są certyfikatem ani uniwersalną receptą na każdy system agentowy.

Najpierw skutek działania, potem poziom autonomii

Nie klasyfikujemy ryzyka po tym, czy operacja brzmi „technicznie”. Odczyt skomplikowanego raportu może być bezpieczny. Jedno proste wywołanie DELETE może usunąć dane. Kliknięcie „enable” może uruchomić wydatek.

Praktyczny podział wygląda tak:

Klasa działania	Przykład	Domyślna kontrola
Odczyt o niskim ryzyku	pobranie statusu, raportu lub listy zasobów	agent może wykonać sam w zatwierdzonym zakresie
Przygotowanie zmiany	utworzenie draftu konfiguracji, planu lub treści	agent przygotowuje, człowiek widzi wynik przed publikacją
Zapis odwracalny	zmiana ustawienia z możliwością szybkiego cofnięcia	jawny zakres write, walidacja wejścia, zapis wyniku
Działanie zewnętrzne lub finansowe	publikacja, wysłanie wiadomości, uruchomienie kampanii, zwiększenie wydatku	jawne zatwierdzenie człowieka przed wykonaniem
Działanie destrukcyjne lub bezpieczeństwa	usunięcie danych, zmiana uprawnień, rotacja dostępu	osobny zakres, preview, zatwierdzenie i możliwie niezależna kontrola

To nie jest matematyczna klasyfikacja. Jest punktem startowym do określenia, gdzie błąd modelu staje się błędem biznesowym albo incydentem bezpieczeństwa.

Cztery warstwy, które rozdzielamy

1. Model rozumuje, ale nie nadaje sobie uprawnień

Model może wybrać narzędzie z dostępnego zestawu. Nie powinien sam rozszerzać tego zestawu ani decydować, że na potrzeby zadania „tym razem” potrzebuje administratora.

Uprawnienia powinny wynikać z tożsamości operatora, roli agenta, konkretnego narzędzia i zasobu. Decyzja autoryzacyjna należy do systemu, nie do tekstu wygenerowanego przez model.

Przeczytaj: Najmniejsze uprawnienia dla agentów AI

2. Działania wysokiego wpływu mają bramkę zatwierdzenia

„Human in the loop” nie powinien oznaczać, że człowiek klika OK przy każdym odczycie. Wtedy kontrola szybko zamienia się w rytuał.

Zatwierdzenie ma sens tam, gdzie operacja uruchamia wydatek, komunikuje się na zewnątrz, zmienia dostęp, usuwa dane albo tworzy skutek trudny do odwrócenia. Przed akceptacją człowiek powinien widzieć co ma się zmienić, gdzie, z jakiego powodu i jaki będzie skutek.

Przeczytaj: Kiedy agent AI wymaga zatwierdzenia człowieka?

3. Warstwa narzędziowa egzekwuje zasady niezależnie od promptu

Prompt jest częścią sterowania zachowaniem modelu. Nie jest mechanizmem bezpieczeństwa wystarczającym dla zapisu, wydatku czy operacji administracyjnej.

W naszym wewnętrznym narzędziu Brillnet Ads MCP ograniczenia są egzekwowane na gatewayu. Operacja jest klasyfikowana, sprawdzane są zakresy, a bezpieczne wartości domyślne blokują przypadkowe uruchomienie działania. Przykładowo nowa kampania pozostaje w stanie PAUSED, jeśli status nie został jawnie określony. Uruchomienie wydatku wymaga osobnego uprawnienia operacyjnego i jawnego potwierdzenia.

To jest dla nas ważniejszy wzorzec niż „napisz lepszy system prompt”.

Przeczytaj: MCP i agenci AI — jak projektować bezpieczne narzędzia

4. Audyt opisuje operację, nie zapisuje wszystkiego

Dobry ślad audytowy pozwala odpowiedzieć:

kto lub jaki agent zainicjował działanie;
które narzędzie zostało użyte;
jaki zasób był celem;
jaka decyzja autoryzacyjna zapadła;
czy wymagano zgody człowieka i kto ją wydał;
jaki był wynik wywołania;
jaki stan zasobu odczytano po zmianie.

Nie oznacza to zapisywania sekretów, tokenów, nagłówków autoryzacyjnych ani całych surowych danych „na wszelki wypadek”. Log, który staje się drugim magazynem danych wrażliwych, rozwiązuje jeden problem i tworzy następny.

Przeczytaj: Ślad audytowy agentów AI — co logować, a czego nie

Co sprawdzamy przed podłączeniem agenta do nowego systemu

Krótka checklista projektowa:

Cel: czy agent ma jednoznacznie zdefiniowaną pracę, czy dostał ogólny dostęp „do wszystkiego”?
Tożsamość: czy każde wywołanie można przypisać do operatora, agenta i sesji/zadania?
Narzędzia: czy agent widzi tylko funkcje potrzebne do zadania?
Zasoby: czy można ograniczyć konto, tenant, projekt, katalog lub rekordy, na których wolno działać?
Odczyt i zapis: czy uprawnienia read i write są rozdzielone?
Operacje wysokiego ryzyka: czy wymagają osobnej zgody lub scope?
Walidacja: czy gateway sprawdza format, identyfikatory i klasę operacji przed wywołaniem systemu docelowego?
Bezpieczne wartości domyślne: czy brak parametru prowadzi do bezpiecznego stanu, a nie do uruchomienia działania?
Powtórzenie: czy przypadkowy retry może wykonać tę samą operację dwa razy? Jeżeli tak, potrzebna jest idempotencja lub inny mechanizm kontroli.
Stan po operacji: czy system potrafi odczytać i pokazać stan po zapisie?
Audyt: czy zapisujemy decyzję i rezultat bez sekretów i nadmiaru danych osobowych?
Przerwanie: czy człowiek może zatrzymać proces, zanim kolejne kroki zwiększą szkodę?

Jeżeli na kilka z tych pytań odpowiedź brzmi „nie wiemy”, nie jest to argument za kolejnym promptem. To sygnał, że granica między modelem a systemem docelowym wymaga zaprojektowania.

Przykład: dlaczego retry i read-after-write mają znaczenie

Załóżmy, że agent ma utworzyć zasób przez API. Wysyła żądanie, ale odpowiedź ginie po drodze. Agent nie wie, czy zapis się udał. Najprostszy retry może utworzyć drugi identyczny zasób.

Dlatego w operacjach zapisu stosujemy identyfikator idempotency, a po zmianie odczytujemy wynikowy stan. Wtedy problem sieciowy nie musi zmieniać się w podwójną operację, a operator widzi stan systemu docelowego zamiast ufać komunikatowi „zrobione”.

To jest drobny szczegół implementacyjny, dopóki zapis nie dotyczy pieniędzy, odbiorców wiadomości albo konfiguracji bezpieczeństwa. Wtedy przestaje być drobny.

Czego nie obiecujemy

Nie istnieje jeden poziom autonomii dobry dla każdego procesu.
Sam MCP nie czyni narzędzia bezpiecznym.
Samo logowanie nie tworzy audytu, jeśli nie potrafimy połączyć zdarzeń z decyzją i rezultatem.
Obecność człowieka nie naprawia słabej kontroli dostępu.
Wzorce opisane tutaj nie zastępują threat modelingu, testów bezpieczeństwa ani analizy prawnej konkretnego wdrożenia.

Źródła referencyjne

Dalej

Jeżeli oceniasz Brillnet jako dostawcę, zacznij od publicznych informacji o bezpieczeństwie i zgodności oraz nadzorze nad AI.

Jeżeli masz konkretny proces, w którym agent ma czytać lub zmieniać dane w systemie zewnętrznym, opisz jedno działanie, które ma wykonywać, i jedno działanie, którego nie wolno mu wykonywać. To daje lepszy punkt startu niż ogólne „chcemy wdrożyć agentów AI”.