Baza wiedzy
Jak ustalić limity wydatków dla agenta AI?
Jak bezpiecznie przekazać agentowi AI możliwość wykonywania drobnych płatności: limity kwot, zatwierdzanie wyjątków, ochrona danych dostępowych i ślad audytowy.
Jak bezpiecznie pozwolić agentowi AI wykonywać płatności w imieniu firmy?
Agent powinien otrzymać osobny, minimalny zakres uprawnień oraz limity kwoty, czasu, liczby transakcji i dozwolonych odbiorców. Płatności o większym wpływie wymagają zatwierdzenia człowieka, a każda próba i jej wynik powinny pozostawiać czytelny ślad audytowy.
Agent AI, który potrafi kupić dostęp do danych, opłacić usługę albo uruchomić płatną operację, może skrócić proces. Jednocześnie wykonuje działanie, którego skutki są finansowe i czasem trudne do cofnięcia.
Dlatego samo polecenie „nie wydawaj za dużo” nie jest zabezpieczeniem. Limity muszą działać poza modelem i zatrzymać transakcję nawet wtedy, gdy agent błędnie zinterpretuje odpowiedź, ponowi operację albo wybierze niewłaściwe narzędzie.
Oddziel cel zakupu od zgody na płatność
Agent może rozpoznać, że płatny zasób jest potrzebny do ukończenia zadania. Nie oznacza to jeszcze, że powinien samodzielnie zatwierdzić każdą cenę, każdego odbiorcę i każdy rodzaj zobowiązania.
W procesie warto rozdzielić trzy elementy:
- uzasadnienie, dlaczego zakup jest potrzebny;
- sprawdzenie, czy mieści się w ustalonych zasadach;
- wykonanie i zapisanie wyniku płatności.
Dzięki temu firma może automatyzować drobne, przewidywalne wydatki, pozostawiając człowiekowi decyzje o większym wpływie.
Ustaw więcej niż jeden limit
Sam limit pojedynczej transakcji nie chroni przed serią małych płatności. Potrzebny jest zestaw ograniczeń odpowiadający sposobowi pracy firmy.
Najczęściej warto określić:
- maksymalną kwotę jednej płatności;
- łączny budżet na sesję, zadanie, dzień lub miesiąc;
- czas wygaśnięcia zgody;
- maksymalną liczbę transakcji;
- dozwolone waluty;
- listę odbiorców, usług albo kategorii wydatków;
- zakaz płatności cyklicznych lub zobowiązań długoterminowych bez osobnej zgody.
AWS opisuje sesję płatniczą z limitem łącznej kwoty i czasem wygaśnięcia. Kontrola działa na poziomie infrastruktury i odrzuca żądanie, które przekroczyłoby budżet sesji. To dobry przykład zasady ogólnej: limit powinien być sprawdzany przez warstwę wykonującą płatność, a nie tylko przez instrukcję przekazaną agentowi.
Zacznij od minimalnych uprawnień
Agent nie potrzebuje dostępu do głównego rachunku firmy ani wszystkich sposobów płatności.
Bezpieczniejszy punkt wyjścia to osobny portfel, konto techniczne albo metoda płatnicza z ograniczonym saldem i zakresem użycia. Uprawnienia powinny obejmować wyłącznie czynności potrzebne w konkretnym procesie.
OWASP zaleca ograniczanie funkcji, uprawnień i autonomii rozszerzeń używanych przez modele. W praktyce oznacza to, że agent przeznaczony do kupowania dostępu do pojedynczych źródeł nie powinien jednocześnie móc zmieniać odbiorców, podnosić własnych limitów ani tworzyć nowych płatności cyklicznych.
Nie przekazuj agentowi surowych danych dostępowych
Model nie powinien otrzymywać numerów kart, kluczy portfela ani długoterminowych danych uwierzytelniających w treści rozmowy lub narzędzia.
Warstwa płatnicza powinna przechowywać te dane poza kontekstem agenta i udostępniać jedynie wąską operację potrzebną do wykonania zatwierdzonej transakcji. W rozwiązaniu opisywanym przez AWS agent nie widzi surowych danych uwierzytelniających, a operacje są zlecane przy użyciu krótkotrwałych tokenów.
To nie usuwa wszystkich zagrożeń, ale ogranicza skutki błędu i utrudnia wykorzystanie danych poza przewidzianym procesem.
Określ, kiedy potrzebna jest zgoda człowieka
Nie każda płatność wymaga ręcznego kliknięcia. Zatwierdzenie powinno pojawiać się tam, gdzie konsekwencje są większe albo sytuacja odbiega od przewidzianych zasad.
Do ręcznej decyzji warto kierować między innymi:
- pierwszą płatność do nowego odbiorcy;
- kwotę przekraczającą ustalony próg;
- zakup poza dozwoloną kategorią;
- płatność cykliczną lub zobowiązanie odnawialne;
- zmianę waluty albo kraju odbiorcy;
- sytuację, w której opis usługi, cena lub dane odbiorcy są niepełne;
- ponowienie po niejasnym wyniku poprzedniej próby.
OWASP rekomenduje udział człowieka przed działaniami o dużym wpływie. Ważne, aby zatwierdzający widział odbiorcę, kwotę, cel, źródło ceny i warunki zobowiązania, a nie tylko ogólny komunikat „agent chce zapłacić”.
Zabezpiecz proces przed podwójną płatnością
Agent może ponowić wywołanie, gdy odpowiedź przyjdzie z opóźnieniem albo wynik będzie niejednoznaczny. Warstwa wykonawcza powinna więc rozpoznawać, że dane zobowiązanie zostało już opłacone.
Przed ponowieniem należy sprawdzić stan wcześniejszej próby. Pomaga w tym unikalny identyfikator zamówienia lub zadania, który pozwala powiązać wszystkie wywołania z jedną płatnością biznesową.
Limit kwoty nie wystarczy, jeśli ten sam wydatek może zostać wykonany kilka razy.
Zapisuj cały przebieg, nie tylko sukces
Ślad audytowy powinien umożliwiać odtworzenie decyzji. Dla każdej próby warto zapisać:
- jakie zadanie wykonywał agent;
- kto lub jaki proces uruchomił działanie;
- odbiorcę, kwotę i walutę;
- zastosowaną regułę lub limit;
- informację o zatwierdzeniu człowieka;
- wynik operacji i identyfikator transakcji;
- powód odrzucenia albo ponowienia.
AWS wskazuje na dzienniki, ślady transakcji i metryki, takie jak skuteczność oraz średnia wartość transakcji. OWASP również zaleca monitorowanie działań narzędzi i systemów wykonawczych. Dla firmy ważne są dodatkowo alerty o przekroczeniach, nowych odbiorcach i nietypowej liczbie prób.
Przygotuj możliwość natychmiastowego zatrzymania
Firma powinna wiedzieć, jak szybko odebrać agentowi możliwość płacenia bez wyłączania całego systemu.
Potrzebne mogą być:
- wyłączenie konkretnego narzędzia;
- unieważnienie aktywnych sesji;
- zablokowanie portfela lub metody płatniczej;
- cofnięcie danych dostępowych;
- obniżenie limitu do zera;
- zatrzymanie wybranego odbiorcy albo kategorii.
Procedurę warto przetestować przed uruchomieniem produkcyjnym. Awaryjne wyłączenie, którego nikt wcześniej nie sprawdził, może zadziałać zbyt późno.
Jak zacząć bezpieczny pilotaż?
Pierwszy test powinien obejmować ograniczony proces, mały budżet i niewielką grupę użytkowników.
Przed rozszerzeniem zakresu sprawdź co najmniej:
- próbę przekroczenia limitu pojedynczej i łącznej kwoty;
- wygaśnięcie zgody w trakcie zadania;
- płatność do niedozwolonego odbiorcy;
- powtórzenie tego samego żądania;
- brak lub opóźnienie odpowiedzi systemu płatniczego;
- ręczne zatwierdzenie wyjątku;
- odebranie agentowi uprawnienia podczas aktywnej sesji;
- zgodność dziennika z rzeczywistym wynikiem transakcji.
Dopiero po tych kontrolach warto podnosić budżet, zwiększać liczbę odbiorców lub ograniczać udział człowieka.
Najważniejsza zasada
Agent może proponować i wykonywać płatności, ale nie powinien sam określać granic własnego działania.
Limity, uprawnienia, reguły zatwierdzania i awaryjne zatrzymanie muszą należeć do warstwy kontrolowanej przez firmę. Dzięki temu automatyzacja przyspiesza drobne transakcje, nie zamieniając pojedynczego błędu modelu w nieograniczone zobowiązanie finansowe.