Bezpieczeństwo agenta AI polega na kontrolowaniu tego, co może odczytać i wykonać w połączonych systemach. Model może zaproponować działanie, ale prawo do jego realizacji powinno wynikać z zasad wymuszanych przez aplikację i system docelowy. To szczególnie ważne przy poczcie, CRM, plikach i automatyzacji procesów.
Agent różni się od prostego chatbota tym, że może wykonywać kolejne kroki za pomocą narzędzi. Wygodny dostęp do wielu integracji zwiększa też zakres możliwych skutków błędu. Artykuł pokazuje, jak zaprojektować granice i odbiór takiego procesu.
Oddziel możliwość modelu od uprawnienia w systemie
Lista narzędzi opisuje, jakie operacje agent potrafi zaproponować. Konto integracji określa, co może faktycznie wykonać. Zasady autoryzacji rozstrzygają, czy dana operacja jest dopuszczalna w konkretnym kontekście. Wszystkie trzy warstwy muszą być spójne.
Jeśli zadaniem jest podsumowanie zgłoszenia, nie udostępniaj narzędzia usuwania rekordów. Jeżeli integracja powinna pracować na jednym projekcie, nie nadawaj jej dostępu do całej organizacji. OWASP opisuje nadmiar funkcji, uprawnień i autonomii jako Excessive Agency. Źródło: OWASP LLM06.
Nie zakładaj, że odczyt jest zawsze mało ryzykowny. Odczyt poufnego dokumentu i przekazanie jego treści do niewłaściwego odbiorcy również może wyrządzić szkodę. Zasady danych powinny wynikać z odrębnej polityki korzystania z AI.
Przykład: od szkicu odpowiedzi do wysyłki oferty
Scenariusz modelowy: agent ma przygotowywać odpowiedzi na zapytania klientów. Początkowo czyta wybrane zgłoszenie i zapisuje projekt. Dopiero po sprawdzeniu tego etapu firma rozważa dodanie wysyłki oraz aktualizacji statusu w CRM.
Poniższa macierz jest propozycją zakresu pilotażu. Nie stanowi uniwersalnej klasyfikacji ryzyka: np. szkic zawierający poufne informacje także wymaga właściwej ochrony miejsca zapisu.
| Operacja | Zakres uprawnienia | Kontrola w pilotażu |
|---|---|---|
| Odczyt zgłoszenia | Tylko wskazany rekord dostępny użytkownikowi | Sprawdzenie użytkownika i rekordu przy każdym żądaniu |
| Utworzenie szkicu | Wydzielony folder lub status roboczy | Walidacja treści i potwierdzenie miejsca zapisu |
| Wysłanie odpowiedzi | Konkretny odbiorca i zatwierdzona treść | Zgoda uprawnionej osoby na tę operację |
| Zmiana statusu CRM | Dozwolone pola konkretnego rekordu | Sprawdzenie wersji rekordu i reguł procesu |
| Usunięcie lub masowy eksport | Poza zakresem pilotażu | Brak narzędzia i brak uprawnienia konta |
Na małym ekranie przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
W tym modelu przejście do kolejnego etapu wymaga świadomego rozszerzenia konfiguracji. Nie wynika z tego, że agent uzna wysyłkę za wygodny sposób ukończenia zadania.
Autoryzacja musi działać przy każdym wywołaniu
Logowanie potwierdza tożsamość; nie oznacza zgody na dowolną operację. Backend powinien oceniać połączenie użytkownika, zasobu, działania i warunków procesu. Dostęp do jednego zgłoszenia nie daje prawa do innego tylko dlatego, że jego identyfikator pojawił się w odpowiedzi modelu.
Stosuj odmowę domyślną i kontrolę dostępu po stronie serwera. Gdy brak wymaganych danych lub usługa autoryzacyjna nie odpowiada, nie rozszerzaj uprawnień w trybie awaryjnym. Zasady te są częścią ogólnego projektowania autoryzacji, niezależnie od wykorzystania AI. Źródło: OWASP Authorization Cheat Sheet.
Przykładowy dowód w teście: model proponuje zmianę rekordu innego zespołu, ale system odrzuca żądanie przed zapisem. W logu widać odmowę, a kontrola rekordu potwierdza brak modyfikacji.
Co dokładnie powinien zatwierdzać człowiek?
Ekran akceptacji powinien pokazywać odbiorcę, treść, załączniki i skutki. Ogólne pytanie „czy kontynuować?” nie wystarcza, jeśli użytkownik nie widzi, co zostanie wykonane.
Zwiąż zatwierdzenie z konkretnym zestawem parametrów, użytkownikiem oraz okresem ważności. Po zmianie odbiorcy lub treści sprawdź zgodę ponownie. Weryfikacja ma nastąpić po stronie serwera bezpośrednio przed wykonaniem. Zasady OWASP dotyczące autoryzacji transakcji podkreślają znaczenie weryfikacji istotnych danych i niezależnego wymuszania kontroli. Źródło: OWASP Transaction Authorization.
Przykład odbioru: zaakceptowano wysyłkę fikcyjnej oferty do odbiorcy testowego A. Zmiana parametrów na odbiorcę B nie może korzystać z tej samej zgody. Test należy przeprowadzić na kontrolowanych adresach i fikcyjnej treści.
Ponowienia, limity i zatrzymanie działania
Błąd sieci może nastąpić po wykonaniu operacji, lecz przed odebraniem potwierdzenia. Ponowienie wysyłki bez sprawdzenia stanu grozi duplikatem. Projekt powinien określać identyfikator operacji, sposób rozpoznawania ponowień i zachowanie przy niepewnym wyniku. Nie wolno obiecywać cofnięcia wysłanej wiadomości tak, jakby była lokalnym szkicem.
Ustal limity czasu, kroków, wywołań i kosztu zadania oraz możliwość zatrzymania agenta. Ogranicz również dostęp narzędzi do sieci i środowiska wykonawczego. OWASP zaleca granice autonomii, podgląd działań i możliwość przerwania pracy agenta. Źródło: OWASP AI Agent Security.
Po awarii proces powinien przejść do zrozumiałego stanu: wykonane, niewykonane albo wymagające sprawdzenia. Właściciel procesu musi wiedzieć, kto podejmuje decyzję o ponowieniu. Te ustalenia warto wpisać również do dokumentacji automatyzacji w n8n.
Sześć pytań przed uruchomieniem agenta
- Czy każde dostępne narzędzie jest potrzebne do określonego zadania?
- Czy konto integracji ma tylko niezbędne prawa do danych i operacji?
- Czy zmiana identyfikatora rekordu jest sprawdzana po stronie serwera?
- Czy zgoda dotyczy dokładnej treści i parametrów, które zostaną wykonane?
- Czy ponowienie po błędzie sieci nie wywoła niekontrolowanego duplikatu?
- Czy operator potrafi zatrzymać pracę i ustalić rzeczywisty stan zadania?
Dla każdego pytania zachowaj wynik testu lub zapis konfiguracji. Nie oceniaj wyłącznie opisu możliwości narzędzia. Zestaw dowodów i kryteria decyzji opisujemy w checkliście testów bezpieczeństwa AI.
Jak wdrażać kolejne uprawnienia?
Rozpocznij od jednego procesu, niewielkiej grupy i jasno ograniczonego zakresu. Rozszerzenie dostępu powinno mieć właściciela, uzasadnienie i test. Jeśli pojawia się nieoczekiwane zachowanie po przeczytaniu dokumentu, sprawdź także ochronę przed prompt injection.
Partnerhosted wspiera firmy w porządkowaniu cyberbezpieczeństwa i wdrożeniach IT. Przed ustaleniem zakresu prac warto przygotować listę narzędzi agenta, połączonych systemów oraz operacji, które ma wykonywać.
Najczęstsze pytania
Czy agent AI powinien mieć konto administratora?
Zakres dostępu powinien wynikać z potrzeb procesu i być możliwie ograniczony. Szerokie konto administracyjne zwiększa możliwe skutki błędu lub manipulacji.
Czy zgoda na przygotowanie szkicu pozwala agentowi go wysłać?
Nie. Przygotowanie szkicu i wysyłka to odrębne operacje. Aplikacja musi wymuszać wymagane uprawnienia oraz zasady akceptacji każdej z nich.
Co zrobić, gdy po błędzie nie wiadomo, czy operacja została wykonana?
Najpierw ustalić stan w systemie docelowym. Niepewnego wyniku nie należy automatycznie traktować jako niewykonania, ponieważ ponowienie może spowodować duplikat.
Źródła i zakres opracowania
Źródła pierwotne podlinkowano przy odpowiednich zagadnieniach; sprawdzono je 23 września 2026 r. Macierze, scenariusze i kryteria odbioru są propozycjami praktycznego zastosowania zasad. Przykłady nie opisują rzeczywistych klientów ani wyników audytu konkretnego produktu.
Porozmawiaj o bezpiecznym korzystaniu z AI
Opisz używane narzędzie, źródła danych i połączone systemy. Ustalimy zakres potrzebnych prac i zasady współpracy.
Skontaktuj się z Partnerhosted