Security and limits
Spendkit checks a payment request before the wallet sends it. The onchain Router checks the Spending Policy again when the wallet submits the transaction. Your Payment Wallet remains the source of the funds.
Who controls what?
Hold test USDG, approve the Router's token permission, sign Policy changes, and keep the wallet key in a trusted local wallet or Runtime.
Authenticates the Agent, reads its bound Policy, previews requests, signs exact short-lived authorizations, and reconciles recorded transactions. It does not hold your funds or submit Agent payments.
Requires the bound Payment Wallet as sender and token source. It checks Policy state, amount, recipient, expiry, signature, and replay protection before a transfer.
Receives USDG only after a payment submitted through the Router passes those checks.
Two different kinds of limit
Each Agent has its own daily and per-payment limits, plus optional recipient rules. The Router checks these rules onchain. The daily budget renews automatically at 00:00 UTC.
During setup, the dashboard clearly asks the wallet owner to approve ongoing Router access; an older limited approval may need one upgrade. The wallet may describe this as an unlimited USDG approval. It does not renew daily and remains until revoked. Every Router payment still requires the bound wallet as sender, a valid exact authorization, and a Policy check. Revoking the approval stops Router payments until the wallet owner approves again.
The Router's limits apply to payments sent through Spendkit. The local Runtime holds the Payment Wallet key to sign transactions; anyone who compromises that Runtime or key store could send tokens directly outside the Router. Keep the key outside model context and Spendkit Server, and secure the Runtime host.
How an authorized payment stays specific
The server signs the bound Agent, Policy, Payment Wallet, token, recipient, amount, and deadline. The Router rejects a different sender, changed payment details, an expired or replayed authorization, or a Policy that is paused, revoked, or over its limit. The Payment Wallet pays gas and supplies the USDG; Spendkit Server does neither.
What you can do if something looks wrong
- Pause the Agent's Policy in AI Agents to block new Spendkit payments under that Policy.
- Revoke the Router's USDG token allowance in your wallet if you want to stop that wallet's Router payments.
- Rotate or revoke Agent connection credentials if the Runtime's access may be exposed.
- Inspect Payment Activity and the transaction status before trying another payment.
The current public environment is a testnet demo using Paxos Test USDG on Arbitrum Sepolia. The published historical successful payment predates the currently registered signed-authorization-v3 Router; it is not proof of a new payment on this Router version.