小さなオンラインストアを経営している友人がいます。先月、彼は在庫を自動で再注文するスクリプトを動かしました。2日後、どこで止めるかを指示するものがなかったため、月の予算の大半を1つの仕入先に使い切っていたことに気づきました。今では、支払いをすべて手動で承認しています。@KITE AI (KITE)がエージェントの支払いをどう扱うのか詳しく見たとき、その話を思い出しました。

彼が直面したのと同じ問題です。すべて自分で承認してエージェントを待たせるか、完全なアクセス権を与えてうまくいくことを願うか。そのどちらかです。Kiteのドキュメントには、もう1つの方法が説明されています。合計予算と1回ごとの上限を設定した支出セッションを作成して、一度承認すれば、期限が切れるか予算を使い切るまで、エージェントは再承認を求めずにその範囲内で支出できます。

Kiteの仕組みが腑に落ちたのは、その処理の流れでした。エージェントがサービスを呼び出し、サービスが条件を添えて「402 Payment Required」を返すと、Passportエージェントは承認済みセッションから支払いを行い、サービスは何かを提供する前に支払いの証明を検証します。つまり、支払いは人間が別途付き添わなければならない手順ではなく、リクエスト自体の一部になります。

速度面も、よく考えられているようでした。オンチェーン取引は開始と終了の2回だけで、その間に何千ものオフチェーン署名済み更新が行われます。リクエスト100万件あたり$1で、レイテンシは100ミリ秒未満。エージェントによる少額決済が現実的になり始める水準です。

Kiteを軽視できなくなったのは、本人確認の層があるからです。セッションが侵害されても影響は1つの委任に限られ、エージェントが侵害されてもユーザーが設定した上限の範囲内にとどまり、ユーザーの鍵はローカルのエンクレーブ内に保管されます。友人のスクリプトには、こうした防壁が何もありませんでした。

ただ、たくさんのエージェントが実際のお金を同時に動かすようになったとき、Kiteがどう機能するのかはまだわかりません。セッションの上限と多層的な本人確認だけで、大規模なエージェント経済を本当に安全に保てるのでしょうか。それとも、リスクはそもそも人々が上限をどう設定するかという点に移るだけなのでしょうか。これから注目していきたい問いです。$KITE answer。
@KITE AI $KITE #KiteBBW