Wirtualne karty i kill switch — jak odciąć agenta od pieniędzy

Agent AI, który płaci, prędzej czy później zrobi coś nieprzewidzianego: kupi za dużo, kupi nie to, wpadnie w pętlę zamówień albo zostanie przejęty przez prompt injection. Pytanie nie brzmi „czy”, tylko „jak szybko to zatrzymasz i ile zdąży wydać, zanim zareagujesz”. Dlatego bezpieczeństwo płatności agenta opiera się na dwóch filarach: twardym limicie egzekwowanym poza kodem agenta oraz bezpieczniku, który odcina środki w sekundy.

W skrócie: wirtualna karta jednorazowa to twardy limit po stronie wydawcy — kwota, czas i akceptant są wpisane w samą kartę, więc agent fizycznie nie wyda więcej, niż mu przypisałeś. Kill switch to natychmiastowe odcięcie: unieważnienie karty lub tokenu i wstrzymanie mandatu jednym ruchem, niezależnie od tego, czy aplikacja agenta w ogóle działa. Pierwsze ogranicza maksymalną szkodę z góry, drugie skraca czas reakcji, gdy szkoda już się dzieje.

Dlaczego limit w kodzie agenta nie wystarcza?

Limit zaszyty w logice agenta to bariera miękka. Działa, dopóki agent działa zgodnie z założeniami — a cała pointa zabezpieczeń polega na tym, że czasem nie działa. Błąd w prompt, zatruta odpowiedź narzędzia, halucynacja kwoty, zapętlone wywołanie API: w każdym z tych przypadków „sprawdzenie limitu” w kodzie może zostać ominięte, bo to właśnie kod się myli.

Twardy limit musi siedzieć niżej w stosie — tam, gdzie agent nie ma władzy. W praktyce to warstwa wydawcy karty (issuing). Gdy autoryzacja kwoty zapada po stronie banku czy procesora, a nie w aplikacji, żadna pomyłka agenta nie przepuści transakcji ponad ustalony pułap. To różnica między „prosimy agenta, żeby nie wydał za dużo” a „agent nie ma jak wydać za dużo”.

Jak wirtualna karta egzekwuje limit po stronie wydawcy?

Wirtualna karta to numer karty wygenerowany programowo, z parametrami wpisanymi już na poziomie wydawcy. Przy podejściu typu issuing — opisanym m.in. w dokumentacji Stripe Issuing — do każdej karty można przypiąć reguły wydatkowania (spending controls): maksymalną kwotę, okno czasowe, dozwolone kategorie akceptanta (MCC), a często też konkretnego sprzedawcę. Autoryzacja, która łamie te reguły, jest odrzucana na poziomie sieci kartowej, zanim pieniądze opuszczą konto.

Dla agenta oznacza to kilka konkretnych właściwości:

• Karta jednorazowa (single-use) — ważna do jednej transakcji albo jednej kwoty. Po użyciu jest martwa, więc wyciek numeru nic nie daje napastnikowi.
• Limit jako twardy sufit — agent może poprosić o płatność na 1000 zł na karcie z limitem 200 zł i nic z tego nie wyjdzie. Szkoda jest ograniczona z góry, niezależnie od jakości kodu.
• Izolacja — osobna karta na zadanie, akceptanta albo budżet. Kompromitacja jednej karty nie dotyka pozostałych.

To uzupełnia, ale nie zastępuje mandatów i limitów na poziomie autoryzacji agenta. Mandat mówi „agentowi wolno wydać do X u tych sprzedawców”; wirtualna karta to fizyczny egzekutor tej reguły w sieci płatniczej.

Czym dokładnie jest kill switch i kiedy go użyć?

Kill switch to pojedyncza akcja, która natychmiast odbiera agentowi możliwość wydawania pieniędzy. Nie chodzi o eleganckie zamknięcie sesji — chodzi o twarde odcięcie środków, działające nawet wtedy, gdy sam agent jest niesprawny, zawieszony albo wrogi.

Sensownie zaprojektowany bezpiecznik składa się z kilku poziomów, uruchamianych łącznie:

1. Unieważnienie karty/tokenu po stronie wydawcy — natychmiast blokuje kolejne autoryzacje, niezależnie od tego, co robi aplikacja.
2. Wstrzymanie mandatu — cofnięcie zgody, na podstawie której agent w ogóle inicjuje płatności, żeby nie wystawił nowych instrumentów w miejsce odciętego.
3. Odebranie poświadczeń — unieważnienie kluczy API i tokenów dostępu agenta, by nie sięgnął po inne ścieżki płatności.

Kiedy go pociągnąć? Gdy wykryjesz anomalię (nagły skok liczby lub kwoty transakcji), gdy podejrzewasz kompromitację agenta, gdy dostawca zgłasza incydent, albo gdy zwyczajnie tracisz pewność, że agent działa zgodnie z intencją. Zasada jest prosta: w razie wątpliwości — tnij. Ponowne włączenie agenta jest tanie; odzyskanie wydanych pieniędzy bywa niemożliwe.

Jak zaprojektować szybki bezpiecznik?

Dobry kill switch ma kilka cech, które warto wymusić jeszcze na etapie projektu, a nie dokładać po incydencie.

Cecha	Dlaczego ma znaczenie
Działa poza procesem agenta	Bezpiecznik sterowany przez samego agenta jest bezużyteczny, gdy to agent jest problemem. Akcja musi iść przez API wydawcy, niezależną konsolę lub osobną usługę.
Jeden ruch, szeroki zasięg	Operator nie powinien ręcznie ubijać dwudziestu kart. Jeden przycisk = unieważnienie instrumentów + wstrzymanie mandatu + odebranie kluczy.
Granularność	Możliwość odcięcia jednego agenta, jednego zadania albo całej floty, zależnie od skali incydentu.
Wyzwalanie automatyczne i ręczne	Progi anomalii odpalają bezpiecznik bez czekania na człowieka; człowiek może go odpalić ręcznie w każdej chwili.
Domyślnie zamknięty (fail-safe)	Gdy warstwa kontroli traci łączność z agentem lub wydawcą, bezpieczniej jest wstrzymać płatności niż przepuszczać je w ciemno.
Pełny ślad	Każde uruchomienie i każda odrzucona autoryzacja trafiają do logu — do analizy po fakcie i do odtworzenia, co się stało.

Bezpiecznik bez obserwowalności jest ślepy: nie odpalisz go na czas, jeśli nie widzisz, że dzieje się coś złego. Dlatego kill switch projektuje się w parze z audytem i logiem transakcji agenta — to z logów biorą się progi alarmowe i to one decydują, jak szybko zauważysz anomalię.

Jak to składa się w całość?

Połącz oba filary w jedną architekturę: agent dostaje wirtualną kartę jednorazową z wąskim limitem, kwotą, oknem czasowym i listą dozwolonych akceptantów — to ogranicza maksymalną szkodę z każdego pojedynczego ruchu. Nad tym wisi kill switch, który w sekundy unieważnia kartę, wstrzymuje mandat i odbiera klucze, gdy coś idzie nie tak. Limit kontroluje, ile agent może wydać, zanim zareagujesz; bezpiecznik skraca czas reakcji do minimum.

Najsłabszym ogniwem nie jest zwykle sam model, lecz miejsce, w którym kontrola nad pieniędzmi zależy od poprawności kodu agenta. Mechanika single-use opisana szerzej w materiale o wirtualnych kartach jednorazowych dla agentów przesuwa tę kontrolę do warstwy wydawcy — tam, gdzie agent nie sięgnie. To właśnie czyni ją dobrym fundamentem bezpieczeństwa płatności agentowych: limit egzekwuje ktoś inny niż ten, kto może się pomylić.