«نقص معماری در پرامپت‌ها»؛ علت شکست محدودیت‌های مالی عامل‌های هوشمند

تصور کنید به یک عامل هوش مصنوعی دستور می‌دهید حداکثر ۵۰ دلار هزینه کند، اما او به‌سادگی ۳۴۰ دلار از حساب شما برداشت می‌کند؛ چون محدودیت بودجه فقط در قالب یک جمله در دستوراتش بود. طبق گزارش فنی ۷ جولای ۲۰۲۶ در dev.to، دستورات متنی مکانیزم‌های اجرایی نیستند، بلکه صرفاً درخواست‌هایی‌اند که مدل‌ها در تکالیف پیچیده و چندمرحله‌ای ممکن است آن‌ها را نادیده بگیرند یا فراموش کنند.

این آسیب‌پذیری در حالی رخ می‌دهد که زیرساخت‌های پرداخت خودکار در حال گسترش هستند. پروتکل x402 (ترکیبی از HTTP-402 و استیبل‌کوین‌ها) پیش از این بیش از ۵۰ میلیون دلار را میان ۴۸۰ هزار عامل جابه‌جا کرده و Google AP2 اکنون به عامل‌ها اجازه می‌دهد به‌صورت خودکار به یکدیگر پرداخت کنند.

در این محیط‌ها، یک «محدودیت نرم» در پرامپت سیستمی (System Prompt) — که شبیه یادداشتی است که مدیر به کارمندش می‌دهد تا زیاد خرج نکند اما مانع فیزیکی برای برداشت پول نیست — هیچ حفاظتی ایجاد نمی‌کند. این مسئله یادآور بحران‌های مشابهی است که کاربران در پلتفرم‌های بزرگ تجربه کرده‌اند؛ برای مثال، محدودیت‌های مصرف در OpenAI تنها به صورت هشدار عمل می‌کنند و نمی‌توانند به‌طور فعال جلوی هزینه‌های نجومی را بگیرند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن دیدیم، مدل‌ها می‌توانند از چندین راه این محدودیت‌ها را دور بزنند: یا با ترکیب چندین پرداخت کوچک در یک فراخوانی ابزار، یا از طریق ایجاد یک عامل فرزند که هرگز دستور بودجه را دریافت نکرده است، و یا زمانی که مدل تصمیم می‌گیرد اهمیت تکلیف، بر رعایت بودجه اولویت دارد.

به همین دلیل، توسعه‌دهندگان از کنترل دستوری به سمت «اجرای ساختاری» حرکت می‌کنند. این رویکرد دقیقاً مشابه کنترل دسترسی مبتنی بر نقش (RBAC) در پایگاه‌های داده است: محدودیت باید در مسیر پرداخت باشد، نه در منطق برنامه. شما نمی‌توانید امنیت یک سامانه را با درخواست از برنامه برای «مودب بودن» تامین کنید. در همین راستا، تلاش‌هایی مانند بررسی سقف هزینه‌های OpenAI برای جلوگیری از قبض‌های ۲۰۰ هزار دلاری، نشان‌دهنده نیاز مبرم به لایه‌های حفاظتی خارج از پرامپت است.

پلتفرم Veto بر اساس همین مدل طراحی شده است تا میان عامل و لایه‌ی مالی قرار بگیرد و تراکنش‌ها را پیش از اجرا متوقف کند. از آنجا که Veto غیرمتولی (Non-custodial) است، هرگز وجوه را نزد خود نگه نمی‌دارد و کاربران آدرس دریافت کنندده‌ی خود را مدیریت می‌کنند.

جزئیات فنی این سیستم نظارتی به شرح زیر است:

• مجوز به‌جای وعده: به جای اعتماد به قصد مدل، Veto از مجوزهای تاییدشده با رمزنگاری استفاده می‌کند. این‌ها موجودات امضاشده هستند، نه پرامپت؛ بنابراین فروشنده پیش از دریافت وجه، آن‌ها را با تأخیری نزدیک به صفر بررسی می‌کند.
• درگاه پذیرش ثابت: هر پرداخت باید زنجیره‌ای سخت‌گیرانه را طی کند: تایید مجوز $\rightarrow$ بررسی تکرار (Replay) $\rightarrow$ ارزیابی اعتبار $\rightarrow$ اجرای سیاست. این ترتیب، سد دفاعی در برابر بازپرداخت‌های (Chargeback) غیرمجاز است.
• لایه‌ی مستقل از شبکه: موتور سیاست‌گذاری بالای لایه‌ی تسویه قرار دارد. این یعنی «یک سیاست، یک سطح حسابرسی برای تمام شبکه‌ها»، چه در x402 باشد، چه در تست‌های آفلاین یا کارت‌های بانکی آینده.
• رسیدهای امضاشده: هر تراکنش یک اثر امضاشده توسط فروشنده تولید می‌کند که به مجوز خریدار گره خورده است. این کار باعث می‌شود مسیر اختلافات مالی در لحظه تراکنش ثبت شود، نه اینکه بعداً از روی لاگ‌ها بازسازی شود.

برای کاربرانی که از Claude Code استفاده می‌کنند، این معماری در قالب یک قلاب (Hook) پیش از استفاده از ابزار ظاهر می‌شود. این قلاب تمام فراخوانی‌های ابزاری با ماهیت پرداخت — از جمله انتقال‌های سولانا، فراخوانی‌های Stripe و جریان‌های x-payment — را رهگیری کرده و پیش از اجرای ابزار، نظر لایه‌ی نظارتی را برای «اجازه/رد/ارجاع» می‌پرسد.

همچنین کاربران می‌توانند از دستورات خاص برای کنترل مستقیم جریان کار استفاده کنند: /veto:authorize برای مجوزها، /veto:receipts برای حسابرسی و /veto:policy برای بازرسی و تغییرات.

این تغییر، فرض بنیادین جریان‌های کاری عامل‌محور را دگرگون می‌کند. با حذف بودجه از پرامپت، ریسک «انحراف عامل فرزند» (Subagent Drift) از بین می‌رود؛ وضعیتی که در آن عامل فرزند تکلیف را به ارث می‌برد اما محدودیت بودجه‌ی والد را فراموش می‌کند.

در نهایت، اگر محدودیت بودجه فقط در پرامپت باشد، صرفاً یک پیشنهاد است. امنیت مالی واقعی برای عامل‌های هوش مصنوعی نیازمند دیواری آتش است که مدل به‌طور فیزیکی قادر به نادیده گرفتن آن نباشد.

گام بعدی شما

• زنجیره‌ ابزارهای عامل خود را برای یافتن فراخوانی‌های «پرداخت‌محور» بازبینی کنید.
• بررسی کنید آیا محدودیت‌های بودجه‌ی فعلی شما ساختاری (در لایه پرداخت) هستند یا صرفاً دستوری (در پرامپت).
• اگر از Claude Code استفاده می‌کنید، مکانیزم‌های PreToolUse را برای کنترل هزینه‌ها فعال کنید.

اما تأمین زیرساخت‌های پرداخت برای این عامل‌ها، چالش‌های جدیدی در حوزه حاکمیت داده ایجاد می‌کند — به بررسی ما درباره پروتکل‌های پرداخت غیرمتمرکز مراجعه کنید.