تصور کنید یک عامل هوش مصنوعی با بودجه‌ای محدود، در یک میلی‌ثانیه ده‌ها درخواست پرداخت موازی ارسال کند و پیش از آنکه سیستم متوجه شود، چندین برابر بودجه‌اش را خرج کند. این سناریوی ترسناک، یک واقعیت فنی در معماری فعلی عامل‌های هوش مصنوعی است که می‌تواند منجر به خسارات مالی پیش‌بینی‌نشده شود.
یک تست استرس که توسط PinkWallet انجام شد، یک آسیب‌پذیری بحرانی در نحوه مدیریت محدودیت‌های مالی توسط عامل‌های هوش مصنوعی را آشکار کرد. در این آزمایش، ۴۰ درخواست پرداخت ۷ دلاری به‌طور همزمان علیه یک سقف بودجه روزانه ۲۰۰ دلاری ارسال شد. نتیجه این بود که ۲۸ درخواست پذیرفته و ۱۲ درخواست مسدود شدند؛ به این ترتیب بودجه دقیقاً بدون حتی یک سنت هزینه اضافی حفظ شد. لازم به ذکر است که این تست توسط یکی از کارکنان PinkWallet در محیط Sandbox عمومی آن‌ها انجام شده و از طریق یک اسکریپت ارائه شده، قابل بازتولید است.
طبق گزارش PinkWallet، اکثر معماری‌های فعلی عامل (Agent) — شبیه دستیاری که دستورات شما را اجرا می‌کند اما گاهی در حساب‌وکتاب‌ها گیج می‌شود — محدودیت‌های هزینه را بیشتر به عنوان یک «پیشنهاد» می‌بینند تا یک قانون سخت‌گیرانه. در حالت معمول، عامل ابتدا موجودی را می‌خواند، آن را با سقف بودجه مقایسه می‌کند و سپس پرداخت را اجرا می‌کند. همین فاصله زمانی کوتاه بین «بررسی» و «اجرا»، شکافی خطرناک ایجاد می‌کند؛ به‌ویژه حالا که برای کاهش تأخیر، عامل‌ها از فراخوانی‌های ابزار به‌صورت موازی استفاده می‌کنند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به منطق داخلی مدل برای مدیریت منابع حساس، همواره ریسک بالایی دارد. اگر عاملی ۱۰ دلار بودجه داشته باشد و ۱۰ فرآیند موازی هر کدام ۷ دلار درخواست کنند، هر ۱۰ فرآیند در همان میلی‌ثانیه موجودی ۱۰ دلار را می‌بینند. هر فرآیند به این نتیجه می‌رسد که ۷ دلار کمتر از ۱۰ دلار است و تراکنش را تأیید می‌کند. نتیجه این است که عامل ۷۰ دلار هزینه می‌کند، در حالی که سقف بودجه تنها ۱۰ دلار بود؛ چون عملیات بررسی و پرداخت به‌صورت «اتمیک» یا یکپارچه انجام نشده است. این چالش دقیقاً مشابه همان مشکلاتی است که در بررسی تفاوت کنترل اعتبار در لایه دیتابیس در برابر منطق برنامه به آن پرداختیم، جایی که نبود عملیات اتمیک منجر به نشت اعتبار می‌شود.
معماری شکست
بر اساس مستندات PinkWallet، دو حالت اصلی شکست در پرداخت‌های عامل‌محور وجود دارد:
- شرایط مسابقه (Race Condition): این همان خطای کلاسیک «اول بررسی، بعد اجرا» است. منطق سیستم در طول اجرای موازی — چه به دلیل وجود مجموعه‌ای از عامل‌ها (Swarm) و چه به دلیل تلاش‌های مجدد برای فراخوانی ابزار — شکست می‌خورد. این امر اجازه می‌دهد درخواست‌ها از سد بودجه عبور کنند چون بررسی و پرداخت در یک گام واحد و اتمیک نیستند. این ناکارآمدی در مدیریت منابع، به‌ویژه در سیستم‌های پیچیده، یادآور هزینه‌های هماهنگی در ارتش‌های هوش مصنوعی است که در آن توکن‌ها بدون افزایش کیفیت مصرف می‌شوند.
- افشای اعتبار: در بسیاری از سیستم‌ها، خودِ فرآیند عامل، کلید API واقعی، شماره کارت یا اعتبار کیف پول را در اختیار دارد. در این حالت، «محدودیت هزینه» تنها تکه‌ای از منطق کد است که در همان فرآیند اجرا می‌شود و همان حافظه را چک می‌کند.
- ریسک تزریق پرامپت (Prompt Injection): چون کد بررسی بودجه و اعتبار پرداخت در کنار هم قرار دارند و از طریق یک پرامپت قابل دسترسی هستند، آسیب‌پذیرند. متنی از یک وب‌سایت، سند یا نتیجه‌ی یک ابزار که به عنوان دستور طراحی شده باشد، می‌تواند عامل را متقاعد کند که بررسی بودجه را نادیده بگیرد یا مستقیماً اعتبار پرداخت خام را فراخوانی کند.
راهکار PinkWallet برای پرداخت‌های ایمن
شرکت PinkWallet مرز نظارتی را به لایه پروتکل زمینهٔ مدل (MCP) — که مثل یک گیت‌بان یا نگهبان سخت‌گیر بین مدل و ابزارها عمل می‌کند — منتقل کرده است تا پیش از اجرای هر پرداخت، نظارت صورت گیرد. در این معماری، عامل هرگز به اعتبار واقعی پرداخت دسترسی ندارد و فقط یک کلید مخصوص Pink Agent در اختیار دارد. این کلید می‌تواند از Pink بخواهد که یک سیاست را بررسی کند، درخواست پرداخت دهد یا بودجه فعلی را بخواند، اما به‌تنهایی قادر به جابه‌جایی پول نیست.
وقتی درخواستی تأیید می‌شود، سیستم یک اعتبار تک‌بار مصرف (مانند یک کارت مجازی آزمایشی در محیط Sandbox) صادر می‌کند که فقط برای یک گیرنده و مبلغ مشخص قفل شده است. این اعتبارها پس از ۱۵ دقیقه منقضی می‌شوند. اگر مبلغ یک پرداخت از حد مجاز فراتر رود، سیستم وضعیت pending_human را برمی‌گرداند و تراکنش تا زمانی که یک انسان به‌صورت دستی آن را تأیید کند، مسدود می‌ماند.
مکانیزم‌های اجرای یکپارچه
برای حذف «شرایط مسابقه»، PinkWallet تضمین می‌کند که تصمیم‌گیری درباره سیاست‌ها و ثبت هزینه در یک گام واحد در سمت سرور Pink انجام شود. این یعنی توالی «خواندن موجودی، مقایسه با سقف و تصمیم‌گیری»، بخشی از خودِ ارزیابی درخواست پرداخت است. این رویکرد شکافی را که در آن دو درخواست موازی بتوانند هر دو وضعیت «زیر سقف بودجه» را بخوانند، از بین می‌برد.
علاوه بر این، سیستم از «کلیدهای یکتایی» (Idempotency Keys) استفاده می‌کند. درخواست‌های تکراری با یک کلید یکتایی یکسان، همان تصمیم اولیه را برمی‌گردانند. این کار مانع از آن می‌شود که یک عامل با تکرار یک پرداخت تأییدشده (Replay) با مبلغی متفاوت تحت همان کلید، یک پرداخت را به دو پرداخت تبدیل کند، فارغ از اینکه شبکه ناپایدار باشد یا منطق داخلی عامل دستور تلاش مجدد (Retry) داده باشد.
نتایج تست استرس
تیم توسعه برای اثبات کارایی این رویکرد، اسکریپتی را روی محیط Sandbox عمومی خود با استفاده از یک فضای کاری قالب استارتاپی اجرا کرد. آن‌ها عاملی به نام «Eng Infra AI» (با شناسه a_eng) را تعریف کردند که تحت این قانون بود: «اعتبارات API: ۲۰۰ دلار در روز برای هر عامل، سپس توقف».
آن‌ها ۴۰ درخواست پرداخت ۷ دلاری را به‌طور موازی و در یک لحظه به یک گیرنده ارسال کردند. نتایج در چندین اجرا کاملاً سازگار بود:
- اجرای اول: ۴۰ درخواست ۷ دلاری منجر به ۲۸ مورد تأیید و ۱۲ مورد مسدود شد، در حالی که مجموع
spent_todayبرابر با ۱۹۶ دلار بود. - اجرای دوم: باز هم ۴۰ درخواست ۷ دلاری منجر به ۲۸ تأیید و ۱۲ مسدود شد و مجموعاً ۱۹۶ دلار هزینه شد.
- تست مبالغ بالا: ۱۲ درخواست موازی ۲۵ دلاری علیه همان قانون ۲۰۰ دلار در روز، منجر به ۸ تأیید و ۴ مسدود شد و دقیقاً ۲۰۰ دلار هزینه کرد.
در هیچ‌یک از این موارد، هیچ درخواستی پس از رسیدن به سقف بودجه، پاسخ قدیمی و اشتباه «شما هنوز زیر سقف بودجه هستید» دریافت نکرد.
محدودیت‌های فعلی
تیم PinkWallet برای جلوگیری از ادعاهای بیش از حد، درباره مواردی که سیستم هنوز قادر به انجام آن‌ها نیست، شفاف بود:
- عدم پشتیبانی از سقف تعداد: کاربران می‌توانند سقف‌های دلاری (روزانه/ماهانه)، سقف هر پرداخت، لیست سفید گیرندگان، بازه‌های زمانی و آستانه‌های تأیید انسانی را تعیین کنند، اما هنوز نمی‌توانند تعداد دفعات پرداخت (مثلاً N پرداخت در روز) را مستقل از مبلغ محدود کنند.
- عدم پوشش ابزارهای شخص ثالث: Pink ابزارهای پرداخت MCP سایر ارائه‌دهندگان را پوشش نمی‌دهد. اگر یک عامل مستقیماً سرور پرداخت MCP فروشنده دیگری را فراخوانی کند، قوانین Pink اعمال نمی‌شود.
- وضعیت Sandbox: این سیستم فعلاً فقط در محیط آزمایشی (
agentic-sandbox.pinkwallet.com) و با استفاده از اعتبارات تست فعال است. دسترسی به محیط تولید (Production) در حال حاضر محدود به کاربران دسترسی زودهنگام است. - همگام‌سازی ساعت: سیستم از ساعت UTC سرور استفاده می‌کند. اگرچه فیلد
local_hourبه کاربران اجازه می‌دهد زمانی را که پرداخت در آن رخ می‌دهد مشخص کنند، اما نادیده گرفتن این فیلد می‌تواند در تست‌های مربوط به بازه‌های زمانی تأیید، منجر به نتایج غیرمنتظره شود.
این تغییر معماری، مرز امنیت را از منطق داخلی عامل به لایه زیرساخت منتقل می‌کند. برای توسعه‌دهندگان، این یعنی دیگر نمی‌توان با «فریب دادن» پرامپت عامل، باعث هزینه اضافی شد؛ چون عامل اساساً کلید گاوصندوق را در اختیار ندارد.
این تحول، این فرض بنیادین را تغییر می‌دهد که ایمنی مالی عامل‌ها را می‌توان با پرامپت‌های سیستمی یا بررسی‌های داخلی مدیریت کرد. حفاظ‌های مالی واقعی نیازمند یک محیط اجرای مجزا (Decoupled) هستند که در آن، موجودیتی که پول را درخواست می‌کند، همان موجودیتی نباشد که انتقال را تأیید می‌کند.
توسعه‌دهندگان در حال حاضر می‌توانند این شرایط مسابقه را در Sandbox شرکت PinkWallet تست کنند. این محیط مجموعه‌ای از هفت ابزار را فراهم می‌کند: pink.check_policy ،pink.request_payment ،pink.get_credential ،pink.get_budget ،pink.list_payees ،pink.list_rules و pink.report_receipt. اسکریپت دقیق مورد استفاده برای تست مسابقه، یعنی race_test.sh در گیت‌هاب موجود است تا توسعه‌دهندگان بتوانند با اجرای دستور ./race_test.sh 40 7 نتایج را بازتولید کنند.
گام بعدی شما
- اگر از عامل‌های هوش مصنوعی برای پرداخت یا مدیریت API استفاده می‌کنید، حتماً تست‌های موازی (Parallel Requests) روی سیستم خود اجرا کنید تا از نبود «شرایط مسابقه» مطمئن شوید.
- برای تجربه عملی این معماری، از محیط Sandbox شرکت PinkWallet و ابزارهایی مثل
pink.request_paymentاستفاده کنید. - اسکریپت
race_test.shرا از گیت‌هاب این شرکت دریافت کرده و با دستور./race_test.sh 40 7ریسک‌های بودجه خود را شبیه‌سازی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو