Asking AI to help look up information and asking it to pay on your behalf involve very different levels of trust. If it gets an answer wrong, you can ask again; once money has been spent, fixing the mistake is often not so simple.
I’ve made paid service calls on Kite Passport: I got the service results and saw the corresponding payments in the activity log. I’ve also encountered requests being rejected for exceeding the per-transaction limit. Taken together, these two outcomes illustrate what Agent payments need to address better than a successful payment alone.
A successful payment shows that the process works; stopping when a limit is exceeded gives “I authorize it to act” a concrete boundary.
According to Kite’s payment documentation, users can set a total budget, a per-transaction limit, and an expiration period for a spending session, then approve it with a passkey. Here, a “session” can be understood as an authorization for a task with a set budget and time limit. The Agent can then call paid services within the approved scope, without asking for consent again for every transaction.
But the per-transaction limit and the total budget address two different kinds of failure.
Here’s a hypothetical example: you set a total budget of $10 for a research task, with a maximum of $2 per call. If the Agent selects an API that costs $3, it should stop—even if there’s still money left in the total budget. The per-transaction limit restricts the cost of a single bad choice.
If it spends only $1 each time but keeps making calls through repeated attempts, the per-transaction limit won’t stop the spending from adding up. That’s where the total budget limits how much more the task can spend. The expiration period ensures that old authorizations aren’t left in place indefinitely, waiting to be used.
Kite’s official error code documentation handles per-transaction limit violations, total budget overruns, and calls outside the authorized scope separately. It also explains that the backend checks a session’s budget and scope constraints. The recovery process requires showing the parameters and waiting for the user’s explicit confirmation before creating a new session.
This brings my attention to a very specific question: can the Agent acknowledge that “it doesn’t have enough permission” and hand the decision back to the user? If it expands the budget on its own to complete the task, the original limits lose their meaning.
Of course, there are things limits can’t control.
An API that costs $1 may comply with all the spending rules and still return outdated, duplicate, or irrelevant information. An approved payment only means it hasn’t crossed the set boundaries; it doesn’t prove the purchase was worthwhile.
So I see the value of Kite Passport in two layers: one is enabling the Agent to make payments with explicit authorization; the other is letting users review spending and make a fresh decision when broader permissions are needed. The quality of the service purchased still requires additional judgment and verification.
What I’d rather keep observing is how it performs on complex tasks: whether the budget remains accurate after multiple calls, whether it can clearly explain if a failed call incurred a charge, and whether the Agent stops to explain why when a limit is reached. My two experiences offer concrete observations, but they aren’t enough to prove that it’s reliable in every situation.
For the Agent economy to become part of everyday life, users need to know what it can do on their behalf—and when the boundaries they set will actually take effect. The aspects of Kite worth evaluating lie in these concrete details of how it operates.