# Portfele agentów AI: przechowywanie, budżety i limity wydatków

Autor: Pawnie. Data publikacji: 2026-10-30. Strona kanoniczna: https://www.w3match.com/pl/blog/portfele-agentow-ai-przechowywanie-budzety-i-limity-wydatkow

Jak portfele agentów AI rozdzielają model, podpisującego i właściciela. Poznaj limity wydatków, zarezerwowane środki, równoczesne wywołania i niezamknięte autoryzacje.

Portfel agenta AI pozwala oprogramowaniu zlecać działania finansowe za pośrednictwem komponentu podpisującego. W praktyce liczy się to, kto ma uprawnienia do podpisu, jakie działania są dozwolone i jak ogranicza się wydatki w ramach całego zadania.

Udostępnienie oprogramowaniu portfela wymaga więc czegoś więcej niż wyboru miejsca przechowywania klucza. Potrzebne są zasady określające, jakie działania może ono autoryzować, jak kumulują się wydatki i kto może je zatrzymać. Wnioskowanie modelu i egzekwowanie zasad przez portfel to odrębne elementy systemu.

Oceniałbym portfel agenta, próbując przekroczyć jego uprawnienia za pomocą zwykłych wywołań narzędzi. Produkt, który twierdzi, że „agent rozumie budżet”, nie dowiódł jeszcze, że budżet jest egzekwowany.

## Określ role właściciela, operatora i osoby podpisującej

Osoba lub organizacja finansuje portfel i ustala zasady. Agent wybiera działania w ramach zadania. Komponent podpisujący przekształca dozwolone działanie w prawidłową autoryzację lub transakcję. Jeden produkt może łączyć część tych ról, ale zakres uprawnień powinien być jasny.

Komponent podpisujący może działać lokalnie, w zarządzanej usłudze portfela lub w specjalistycznej odizolowanej infrastrukturze. Smart account może egzekwować dodatkowe zasady za pośrednictwem kontraktów. Te rozwiązania wiążą się z odmiennymi założeniami dotyczącymi przechowywania i odzyskiwania dostępu.

Produkt Agentic Wallets Coinbase opisuje izolację klucza prywatnego i zabezpieczenia wydatków. To konkretna architektura produktu do sprawdzenia, a nie uniwersalna cecha każdego portfela połączonego z modelem AI. [Agentic Wallets Coinbase](https://www.coinbase.com/developer-platform/products/agentic-wallets).

Ustal, kto może zmienić zasady i co się stanie, jeśli ktoś ukradnie dane dostępowe agenta. System chroniący klucz podpisujący może nadal przyjmować złośliwe polecenia zakupów przez autoryzowane dane dostępowe API. Izolacja klucza i autoryzacja działań rozwiązują różne problemy.

## Umieść zasady między agentem a pieniędzmi

Żądanie powinno przejść kontrolę wydatków, zanim portfel je podpisze.

Autoryzacja płatności

**Żądanie agenta**Wskazuje zasób, odbiorcę i kwotę

**Kontrole zasad**Dozwolone aktywo, sprzedawca, budżet i termin ważności

**Podpis portfela**Tylko jeśli żądanie spełnia skonfigurowane zasady

**Zgodne z zasadami**

Autoryzuj zakup w ramach limitu i zapisz wynik.

**Niezgodne z zasadami**

Odrzuć żądanie lub przed podpisaniem skieruj je do zatwierdzenia przez człowieka.

Mała płatność nie może po cichu przyznawać nieograniczonych uprawnień do przyszłych wydatków.

Źródła sprawdzone 13 października 2026 r.  
[Uprawnienia do wydatków](https://docs.cdp.coinbase.com/api-reference/v2/rest-api/evm-smart-accounts/create-a-spend-permission)[Zarządzany portfel agenta](https://www.coinbase.com/developer-platform/products/agentic-wallets)[Budżety MPP](https://mpp.dev/guides/managing-agent-spend)

## Precyzyjnie określ uprawnienia

Przydatne uprawnienie do wydawania środków wskazuje wydającego, aktywo i limit oraz określa czas obowiązywania. Aplikacja może też wymagać ograniczeń dotyczących sprzedawcy lub kontraktu oraz kontroli działań, które może wykonać wydający.

Udokumentowane interfejsy uprawnień do wydatków Coinbase obejmują limit, okres cykliczny i okno ważności. Dokładny sposób egzekwowania zależy od danego konta i implementacji kontraktu. [API uprawnień do wydatków](https://docs.cdp.coinbase.com/api-reference/v2/rest-api/evm-smart-accounts/create-a-spend-permission).

Uprawnienia powinny odpowiadać zadaniu. Zakup odpowiedzi z danymi wymaga mniejszych uprawnień niż handel dowolnymi tokenami. Zapłata znanemu sprzedawcy wymaga mniejszych uprawnień niż zezwolenie na każde wywołanie kontraktu w transakcji wygenerowanej przez narzędzie.

Połączenie portfela, zatwierdzenie wydatków w tokenach i delegowanie działań konta to odrębne etapy. Użytkownik może sprawdzić saldo bez zamiaru autoryzowania wypłaty. Istniejące zgody na tokeny mogą nadal mieć znaczenie po zmianie integracji agenta. [Uprawnienia i zgody portfela](https://help.coinbase.com/en/wallet/security/dapp-permissions-token-approvals).

## Limit transakcji nie uwzględnia ponawiania prób

Rozważ hipotetycznego agenta z maksymalną kwotą zakupu $1 i budżetem zadania $5\. Zleca odpowiedź API za $0.50, otrzymuje niejednoznaczny komunikat o przekroczeniu czasu i próbuje ponownie. Każdy zakup mieści się w limicie transakcji. Powtarzanie żądań może jednak zużyć cały budżet zadania.

Kontrola budżetu musi uwzględniać skumulowane wydatki i oczekujące autoryzacje. Jeśli kilka wywołań działa równocześnie, każde może zobaczyć to samo niewydane saldo, zanim zostanie rozliczona transakcja. Jednoczesne sprawdzenie i rezerwacja budżetu w jednej niepodzielnej operacji zapobiega zatwierdzeniu tych samych środków przez równoległe wywołania.

Poniższa demonstracja zasad traktuje wydane i zarezerwowane środki jako niedostępne dla nowych żądań. Wykorzystuje fikcyjne ceny i uproszczony lokalny automat stanów. Rzeczywista implementacja wymaga trwałego zapisu i egzekwowania zasad, które przetrwa restart procesu.

To samo księgowanie powinno obejmować anulowane lub nieudane wywołanie. Zwolnij rezerwację, gdy autoryzacja nie może już zostać rozliczona, zamiast zakładać, że przekroczenie czasu zwróciło środki. Nierozstrzygnięta płatność nadal jest stanem finansowym wymagającym uzgodnienia.

## Oddziel budżety zadań od salda portfela

Portfel może przechowywać więcej środków, niż konkretny agent może wydać. Umożliwia to wspólne finansowanie kilku zadań bez przyznawania każdemu całego salda. Zapobiega też traktowaniu „dostępnego salda” jako domyślnej granicy uprawnień.

Ustal budżet zadania, łączny limit okresowy i limit pojedynczej transakcji, jeśli wymaga tego proces. Każdy służy czemuś innemu: jeden ogranicza skutki pojedynczej pomyłki, drugi pętlę ponawiania, a kolejny łączne koszty operacyjne.

Przewodnik MPP dotyczący wydatków agenta umieszcza zarządzanie budżetem wokół klienta płatniczego. Skonfigurowane zasady stają się dzięki temu elementem do sprawdzenia, a nie założeniem dotyczącym decyzji modelu. [Zarządzanie wydatkami agenta](https://mpp.dev/guides/managing-agent-spend).

W systemie produkcyjnym zapisz właściciela budżetu i źródło każdego limitu. Odpowiedź narzędzia może zaproponować cenę, ale nie powinna móc zmienić maksimum tylko dlatego, że zasób jest „wymagany” do kontynuowania zadania.

## Sprawdź też odbiorcę

Dozwolone aktywo i kwota nie gwarantują, że płatność trafi do właściwego sprzedawcy. Transakcja może być w poprawnej walucie, a mimo to wskazywać niezamierzony adres lub kontrakt.

Jeśli mechanizm płatności na to pozwala, powiąż zakup ze sprzedawcą i zasobem. Weryfikuj zmiany adresu docelowego, zamiast akceptować nowy adres z dowolnej treści. Materiały badawcze agenta i żądanie płatnicze usługi to dane wejściowe do sprawdzenia, a nie instrukcje uprawnione do zarządzania portfelem.

W przypadku interakcji z kontraktem sprawdź całe podpisywane działanie. Pozornie niewielki transfer tokena może być częścią szerszego wywołania z dodatkowymi uprawnieniami. Polityka sprawdzająca tylko widoczną kwotę może przeoczyć resztę.

[Przewodnik x402](https://www.w3match.com/blog/x402-explained-ai-agent-api-payments) wyjaśnia ofertę płatniczą. Artykuł o tożsamości agenta objaśnia, dlaczego zidentyfikowanie sprzedawcy nie dowodzi jeszcze jakości ani bezpieczeństwa każdej oferty.

## Odwołanie uprawnień wiąże się z problemem czasu

Zatrzymanie agenta, aby nie składał nowych podpisów, nie musi unieważniać podpisów już utworzonych. Transakcja rozesłana do sieci może też zostać rozliczona po naciśnięciu przycisku zatrzymania przez właściciela. Interfejs powinien wyjaśniać, którego etapu dotyczy odwołanie uprawnień.

Limity on-chain lub delegowane uprawnienia wymagają własnego procesu unieważnienia. Blokada konta w zarządzanej usłudze może działać na innej warstwie. Sprawdź, czy zatrzymanie usuwa nadal obowiązujące uprawnienia, wygasza nowe sesje czy tylko rozłącza interfejs.

Różnica wychodzi na jaw podczas incydentu. Operator potrzebuje listy niezamkniętych autoryzacji, oczekujących transakcji i aktywnych zgód. Bez niej „agent zatrzymany” można pomylić z „cała ekspozycja finansowa zatrzymana”.

Ćwiczenie odzyskiwania powinno obejmować opóźnione rozliczenie po uruchomieniu wyłącznika awaryjnego. Wynik mówi o granicy uprawnień znacznie więcej niż demonstracja zwykłych płatności.

## Zapisuj zakup, nie sekret

Przydatne potwierdzenie zapisuje zadanie, sprzedawcę, podaną kwotę, autoryzowane maksimum i wynik. Powinno pozwalać właścicielowi odróżnić rozliczoną płatność od dostarczonego zasobu. Dzienniki nie potrzebują klucza podpisującego, by dostarczyć takich dowodów.

Przy zmiennym wykorzystaniu zapisuj zarezerwowaną kwotę i ostateczne obciążenie. Zadanie może mieścić się w limicie, wybierając zasoby o słabej relacji wartości do ceny; dziennik wydatków pozwala właścicielowi porównać wyniki z kosztami.

Zapisuj również odrzucone działania. Powtarzane zablokowane zakupy mogą ujawnić wadliwą pętlę lub zadanie z budżetem niedopasowanym do wymagań. Ciche ponawianie odrzuconej czynności zmienia zrozumiały limit w trudny do zdiagnozowania błąd.

## Test, który przeprowadziłbym przed zasileniem portfela

Przydziel agentowi niewielki hipotetyczny budżet w środowisku testowym. Spróbuj wykonać kilka zakupów jednocześnie, ponów żądanie po przekroczeniu czasu i zmień adres płatności. Następnie odbierz agentowi uprawnienia, gdy jedna płatność nadal oczekuje na rozliczenie.

Portfel powinien jasno pokazywać właścicielowi każdy wynik. Dozwolone, zarezerwowane, wydane, odrzucone i nierozstrzygnięte środki nie powinny wyglądać jak jedno zmieniające się saldo.

Gdy te kontrole działają, dobierz protokół płatniczy do modelu rozliczania za zasób. [x402 a MPP](https://www.w3match.com/blog/x402-vs-mpp-agent-payments) to porównanie tej warstwy. Zasady portfela muszą działać niezależnie od obsługiwanej trasy wybranej przez agenta.

## Dwa agenty mogą korzystać ze wspólnych środków, ale mieć odrębne budżety

Wyobraź sobie jeden portfel finansujący dwa agenty badawcze. Każde zadanie ma limit $5, ale operator dopuszcza łącznie tylko $8 dziennych wydatków. Jeśli pierwsze zadanie wyda $5, drugie może wykorzystać najwyżej pozostałe $3 zgodnie ze wspólną zasadą. Niewykorzystany limit $5 drugiego zadania nie pozwala ominąć dziennego pułapu.

Przed zatwierdzeniem równoczesnego zakupu komponent podpisujący musi zarezerwować środki w ramach każdego obowiązującego limitu. W przeciwnym razie dwa osobno prawidłowe żądania zadań mogą przekroczyć wspólny budżet. To hipotetyczny projekt zasad, a nie twierdzenie, że każdy portfel obsługuje budżety zagnieżdżone.