چرا اعتبارنامه‌های ذخیره‌شده ابتدایی اشتباهی هستند
کارتی که روی فایل ذخیره شده است یک ابزار حامل است. هر کسی که شماره را در اختیار داشته باشد می‌تواند به‌طور مکرر از آن خرج کند، تا زمانی که صادرکننده یا فروشنده تصمیم دیگری بگیرد. هیچ system prompt، هیچ دستور سطح ابزار، و هیچ مقدار استدلال زنجیره‌ای این ویژگی را تغییر نمی‌دهد. ایجنتی که یک کارت ذخیره‌شده به آن سپرده شده است بودجه ندارد؛ یک قابلیت دارد. این تمایز مهم است چون قابلیت‌ها با نیت محدود نمی‌شوند. آن‌ها با رمزنگاری، نقاط اجرای سیاست، و تمایل صادرکننده به رد یک تراکنش محدود می‌شوند.
وقتی ایجنت یک اعتبارنامه‌ی قابل‌استفاده‌ی مجدد را در دست دارد، ابطال تنها کنترل باقی‌مانده است. ابطال درشت است. نمی‌تواند بین یک تلاش مجدد مشروع و یک تراکنش تکراری، بین یک فروشنده‌ی مجاز و یک فروشنده‌ی جایگزین‌شده، یا بین یک خرید بزرگ واحد و بیست خرید کوچک تمایز قائل شود. همچنین نسبت به اجرای ایجنت کند است. یک حلقه‌ی ابطال که با دقیقه اندازه‌گیری می‌شود، حلقه‌ای را که فراخوانی‌ها را در میلی‌ثانیه صادر می‌کند کنترل نمی‌کند.
توکن‌های هزینه‌ی محدود و تک‌منظوره
جایگزین این است که اعتبارنامه‌ای صادر شود که خودش سیاست است. توکن هزینه‌ی محدود یک مصنوع امضاشده با مجموعه‌ای کوچک و صریح از ادعاهاست:
{
"issuer": "studio-payments",
"subject": "agent-run-8f3a",
"task_id": "replenish-inventory-2026-04-11",
"merchant_category": "office_supplies",
"merchant_id": "supplier-4421",
"amount_ceiling_minor": 25000,
"currency": "EUR",
"not_before": "2026-04-11T09:00:00Z",
"not_after": "2026-04-11T09:15:00Z",
"max_uses": 1,
"nonce": "b7c1...",
"signature": "..."
}
سه ویژگی کار را انجام می‌دهند. اول، توکن به یک شناسه‌ی وظیفه‌ی مشخص مقید است، بنابراین مسیر مجوزدهی قابل‌بازیابی است: هزینه به اجرایی که آن را درخواست کرده نگاشت می‌شود، نه صرفاً به یک حساب کاربری. دوم، توکن تک‌مصرف یا کوتاه‌عمر است، بنابراین یک مصنوع لو‌رفته ارزش محدودی دارد. یک شماره‌ی کارت دزدیده‌شده تا زمانی که صادرکننده اقدام کند یک بدهی است؛ یک توکن تک‌مصرف دزدیده‌شده با پنجره‌ی پانزده‌دقیقه‌ای و قفل فروشنده، تا زمانی که مهاجم آن را مسیریابی کند یک رشته‌ی مرده است. سوم، سقف به واحدهای خرد بیان شده و در ریل اجرا می‌شود، نه توسط ایجنت. ایجنت نمی‌تواند حد خود را بالا ببرد چون حد یک ادعای امضاشده است، نه یک متغیر در یک prompt.
مبادله واقعی است: صدور توکن یک رفت‌وبرگشت و یک وابستگی امضا را قبل از هر خریدی اضافه می‌کند. برای فراخوانی‌های کم‌ارزش و پرتکرار این سربار ناچیز نیست، و سرویس صادرکننده را مجبور می‌کند به‌اندازه‌ی خود ایجنت در دسترس باشد. طراحی‌ای که به‌ازای هر فراخوانی صادر می‌کند کندتر از طراحی‌ای خواهد بود که به‌ازای هر نشست صادر می‌کند؛ طراحی‌ای که به‌ازای هر نشست صادر می‌کند استفاده‌ی مجدد را بازمی‌گرداند. پاسخ صادقانه این است که به‌ازای هر وظیفه با پنجره‌ای کوتاه و سقفی پایین صادر کنیم، و بپذیریم که وظیفه‌ای که به خریدهای زیادی نیاز دارد به توکن‌های زیادی نیاز دارد.
مجوزدهی و تسویه
تصمیم به خرج کردن و سازوکار پرداخت قابل‌تفکیک هستند و باید تفکیک شوند. تصمیم به سیاست تعلق دارد: یک موتور قواعد که زمینه‌ی وظیفه، فروشنده، مبلغ و سابقه را در برابر یک بودجه ارزیابی می‌کند و یک مجوز امضاشده یا یک رد صادر می‌کند. سازوکار به ریل تعلق دارد: یک شبکه‌ی کارت، یک انتقال حساب‌به‌حساب، یا یک لایه‌ی تسویه‌ی استیبل‌کوین. جدا نگه‌داشتن این دو یعنی سیاست می‌تواند بدون دست زدن به ریل حسابرسی، نسخه‌بندی و آزمایش شود، و ریل می‌تواند بدون بازنویسی سیاست عوض شود.
ریل‌های تسویه‌ای که از micropayment برنامه‌نویسی‌پذیر پشتیبانی می‌کنند برای خرید ماشین‌به‌ماشین مناسب‌تر از جریان‌های کارت مصرف‌کننده هستند. جریان‌های کارت مصرف‌کننده برای حل اختلاف و حقوق chargeback بهینه شده‌اند، که برای انسان‌ها ارزشمند و برای فراخوانی به‌ازای هر تماس پرهزینه است. ریلی که به‌صورت قطعی تسویه می‌کند، با قطعیتی که در ثانیه اندازه‌گیری می‌شود و کارمزدی که بر مبالغ کوچک غالب نمی‌شود، برای ایجنتی که یک فراخوانی API واحد یا یک افزایش داده‌ی کوچک می‌خرد مناسب‌تر است. جایی که از کارت استفاده می‌شود، توکن باید یک کارت مجازی تک‌مصرف صادرشده توسط شبکه باشد نه یک شماره‌ی اصلی ذخیره‌شده، تا سقف و قفل فروشنده توسط صادرکننده اجرا شوند.
تطبیق باید خودکار باشد. بازبینی انسانی برای خریدهای به‌ازای هر فراخوانی مقیاس نمی‌گیرد، و صفی از تراکنش‌های در انتظار هدف تفویض را از بین می‌برد. هر توکن باید شناسه‌ی وظیفه و nonce را حمل کند، و سابقه‌ی تسویه‌ی ریل باید با سابقه‌ی مجوزدهی بر اساس آن فیلدها تطبیق داده شود. عدم‌تطابق‌ها — تراکنشی بدون مجوز منطبق، مجوزی بدون تراکنش، تراکنشی خارج از پنجره — باید یک استثنا ایجاد کنند، نه یک تیکت.
حالت‌های شکستی که باید در برابرشان طراحی کرد
خریدهای تقسیم‌شده. ایجنتی که به یک سقف برمی‌خورد، اگر مجاز باشد، یک خرید را به چند تراکنش تقسیم می‌کند که هر کدام زیر آن باقی می‌مانند. دفاع، یک بودجه‌ی تجمعی به‌ازای هر وظیفه است، نه فقط یک سقف به‌ازای هر تراکنش: سرویس مجوزدهی کل هزینه را در برابر شناسه‌ی وظیفه ردیابی می‌کند و توکنی را که از نیت فراتر می‌رود رد می‌کند. سقف به‌ازای هر تراکنش به‌تنهایی یک پیشنهاد است.
جایگزینی فروشنده. توکنی که برای فروشنده‌ی A مجاز شده نباید نزد فروشنده‌ی B تسویه شود. توکن را به یک شناسه‌ی فروشنده مقید کنید، نه فقط به یک دسته، و در زمان تسویه تأیید کنید. قفل‌های دسته ضعیف‌تر از قفل‌های فروشنده هستند و باید به‌عنوان جایگزین در
حلقه‌های تلاش مجدد. یک پاسخ گم‌شده از یک درخواست ناموفق قابل‌تفکیک نیست مگر اینکه عملیات idempotent باشد. به هر توکن یک nonce بدهید و از ریل بخواهید تسویه‌ی دوم با همان nonce را رد کند. تلاش مجدد ایجنت سپس نتیجه‌ی اصلی را برمی‌گرداند نه اینکه دو بار هزینه بگیرد. این همان انضباط کلیدهای idempotency در APIهای پرداخت است که بر هزینه‌ی تفویض‌شده اعمال می‌شود.
این چه چیزی را تغییر می‌دهد
اعتبارنامه‌های هزینه‌ی محدود نقطه‌ی کنترل را از ابطال به صدور منتقل می‌کنند. سؤال دیگر «چگونه ایجنت را متوقف کنیم» نیست، بلکه «دقیقاً چه چیزی را مجاز کردیم، برای کدام وظیفه، نزد کدام فروشنده، تا چه زمانی» است. این سؤالی است که یک حسابرسی می‌تواند پاسخ دهد. یک کارت ذخیره‌شده نمی‌تواند.
پرسش‌های متداول
پ: آیا توکن محدود فقط یک کارت مجازی است؟ پ: می‌تواند به‌عنوان یکی پیاده‌سازی شود، اما ویژگی مهم مجموعه‌ی ادعاهای امضاشده است — شناسه‌ی وظیفه، قفل فروشنده، سقف، انقضا، nonce — نه قالب کارت.
پ: چه چیزی مانع از این می‌شود که ایجنت وقتی به سقف می‌رسد توکن جدیدی درخواست کند؟ پ: سرویس مجوزدهی، نه ایجنت. بودجه‌ی تجمعی به‌ازای هر وظیفه و هر فروشنده در زمان صدور اجرا می‌شود، بنابراین درخواست‌های مکرر علیه همان وظیفه رد می‌شوند.
پ: این چگونه با تسویه‌ی استیبل‌کوین تعامل دارد؟ پ: توکن اختیار است؛ انتقال استیبل‌کوین ریل است. ادعاهای توکن قبل از امضای انتقال بررسی می‌شوند، و مرجع انتقال nonce را برای تطبیق حمل می‌کند.
پ: هزینه‌ی اصلی چیست؟ پ: تأخیر صدور و یک سرویس صادرکننده که باید به‌اندازه‌ی خود ایجنت در دسترس باشد. صدور به‌ازای هر وظیفه با پنجره‌های کوتاه مصالحه‌ی معمول است؛ صدور به‌ازای هر نشست استفاده‌ی مجدد را بازمی‌گرداند.