تصور کنید یک خط متن پنهان در صفحهٔ تأمین‌کننده، عامل هوش مصنوعی شما را فریب دهد تا ۵۰۰ یورو هزینه مشاوره به خرید ۱۰۰۰ یورویی سرور اضافه کند. برای جلوگیری از این فاجعه، برند دیزاین (Brand Design) یک جریان تجاری B2A (کسب‌وکار به عامل) طراحی کرده است که قدرت جست‌وجوی پیشنهادها را از اختیار پرداخت پول کاملاً جدا می‌کند. در این معماری، حتی اگر فایل JSON خروجی معتبر باشد، اگر خریدار هزینه اضافی را تأیید نکرده باشد، تراکنش نباید انجام شود.
بسیاری از عامل‌های فعلی یا قدرت بیش از حد دارند — مثل داشتن یک کارت اعتباری شرکتی بدون نظارت — یا قدرت بسیار کمی دارند و برای هر کلیک به انسان نیاز دارند. این شکاف امنیتی باعث می‌شود عامل‌ها متن‌های غیرقابل‌اعتماد در صفحات وب را به عنوان دستوری برای افزایش سقف هزینه تفسیر کنند و این یک ریسک امنیتی جدی است.
زمینه و بستر صنعتی
به گزارش منابع صنعتی، در ۲۲ سپتامبر ۲۰۲۴، شش بانک بزرگ از جمله بنک آمریکا (Bank of America) و نت‌وست (NatWest) اصولی را برای تجارت عامل‌محورِ قابل‌اعتماد منتشر کردند تا همین ریسک‌ها را مدیریت کنند.
پیش از آن، در همان ماه، W3C و GS1 کارگاه‌هایی را برای بررسی هویت عامل‌ها، مجوزهای دسترسی و اعتبارنامه‌های پرداخت برگزار کردند. برای یک فروشنده، این نگرانی‌ها باید به بررسی‌های اجباری در هر مرحله از خرید تبدیل شوند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های زبانی اشاره کردیم، تکیه بر تفسیر مدل از یک صفحه وب برای تراکنش‌های مالی، ریسک بالایی دارد. این چالش‌ها نشان می‌دهد که چرا در بازارهای مدرن هوش مصنوعی، جایگزینی توصیفات انسانی با قراردادهای ماشین‌خوان برای تضمین تحویل خدمات به یک ضرورت تبدیل شده است. به همین دلیل، طبق گزارش dev.to، مسیر خرید در سیستم برند دیزاین از یک توالی سخت‌گیرانهٔ پنج‌مرحله‌ای پیروی می‌کند تا یکپارچگی تراکنش تضمین شود:
جزئیات مسیر خرید
- catalog.read: عامل خدمات فعلی، قوانین قیمت‌گذاری، نوع ارز و شرایط خدمات را بازیابی می‌کند.
- order.create: سیستم پیشنهاد خاص را ثبت و صفحه خدمات را آرشیو می‌کند. یک هش (Hash) — شبیه به اثر انگشت دیجیتالی که هر تغییر کوچک در متن را فاش می‌کند — از نوع SHA-256 برای شناسایی این بایت‌های آرشیو شده ایجاد می‌شود.
- order.accept: سیستم نسخه پیشنهاد و هش شرایط را تأیید می‌کند؛ هرگونه تغییر در این مراحل باعث می‌شود عامل مجبور شود پیشنهاد جدیدی دریافت کرده و مجدداً آن را بپذیرد.
- payment.start: سرویس پرداخت، مبلغ دقیق قابل پرداخت و ارز را با پیشنهاد پذیرفته‌شده و قابلیت پرداخت مجاز خریدار (شامل سقف هزینه و تاریخ انقضا) تطبیق می‌دهد.
- order.read: وضعیت نهایی سفارش و پرداخت بازگردانده می‌شود.
سرویس پرداخت این بررسی‌ها را بر اساس وضعیت ثبت‌شده در دیتابیس انجام می‌دهد. این سیستم هرگز از «توضیحات» مدل هوش مصنوعی درباره صفحه تأمین‌کننده به عنوان مدرکی برای تأیید اینکه خریدار قیمت جدید را پذیرفته است، استفاده نمی‌کند.
کنترل دامنه در مقابل اختیار پرداخت
برای جلوگیری از جعل هویت، این سیستم از یک چالش DNS TXT برای تأیید دامنهٔ اعلام‌شده توسط عامل استفاده می‌کند. در حال حاضر، تأیید دامنه برای دسترسی احراز شده به UCP و پرداخت‌های توکن-مشترک خودمختار توسط عامل‌های خودثبت‌شده الزامی است. این کار کمک می‌کند تا ادعاهای غیرمعتبر برای نمایندگی یک دامنه رد شوند.
با این حال، این کنترل دامنه با «اختیار پرداخت» متفاوت است. حق پرداخت از یک مجوز مجزا می‌آید که توسط خریدار صادر شده است. بنابراین حتی یک عامل تأییدشده هم نمی‌تواند با خواندن یک خط متن غیرقابل‌اعتماد در یک صفحه وب، سقف هزینه خود را بالا ببرد.
تأیید فنی
در لایه فنی، این پیاده‌سازی شامل یک مانیفست سفارش مصنوعی و یک تأییدکننده Node.js کوتاه است. این ابزار مجموعه‌ای از فیلدهای ثابت پیشنهاد را هش کرده و نتیجه را با یک هش مورد اعتماد که به‌طور جداگانه از مانیفست ارسال شده، مقایسه می‌کند. اگر مهاجمی هم مبلغ و هم هش را در یک فایل JSON غیرقابل‌اعتماد تغییر دهد، باز هم در مرحله تطبیق با تعهد مجزا شکست می‌خورد.
باید توجه داشت که نمونه quote_hash صرفاً یک تصویر برای نمایش است و یک امضای دیجیتال یا فیلد عملیاتی در شبکه نیست. پیاده‌سازی واقعی از pageHash، نسخه‌های پیشنهاد و هش‌های شرایط استفاده می‌کند. احراز هویت درخواست‌های HTTP و شواهد مسیرهای امضا شده، کنترل‌های جداگانه‌ای هستند. هیچ‌یک از این هش‌ها به تنهایی ثابت نمی‌کند که خریدار رضایت داده است.
یکپارچگی پروتکل
این سیستم آداپتورهایی برای ACP و دو نسخه قدیمی از UCP مستقر کرده است. این آداپتورها از همان سوابق کاتالوگ و سفارشات مسیر مستقیم استفاده می‌کنند. طبق مستندات، مسیر استفاده‌شده برای هر تراکنش باید ثبت شود؛ صرفاً داشتن یک آداپتور ثابت نمی‌کند که خرید از طریق درگاه بومی پلتفرم انجام شده است.
محدودیت‌های پلتفرمی نیز وجود دارد. OpenAI اعلام کرده ساخت با ACP باز است، اما پرداخت سریع (Instant Checkout) در ChatGPT فعلاً فقط برای شرکای تأییدشده در دسترس است. در مشخصات UCP، برای نهایی کردن خرید به یک رابط کاربری مورد اعتماد نیاز است، مگر اینکه افزونه AP2 Mandates پشتیبانی شود. پشتیبانی از پروتکل به معنای اجازه برای نادیده گرفتن مراحل ثبت‌نام در پلتفرم یا مجوز خریدار نیست.
نتایج اثبات شده
در ۲۱ سپتامبر ۲۰۲۴، یک تست خارجی کارآمدی این سیستم را ثابت کرد. به یک عامل مأموریت خنثی داده شد تا بدون داشتن نام، دامنه یا لینک پرداخت، یک سرویس تست را بخرد. عامل توانست سرویس 101Ts3t را پیدا کرده و مبلغ ۰.۹۹ یورو را با موفقیت از کیف پول مجاز خود پرداخت کند.
یک تأییدکننده عمومی برای مراحل اکتشاف، یکپارچگی شواهد، شواهد تراکنش و اجرای کامل تجارت عامل‌محور، وضعیت «PASS» را صادر کرد. بسته شواهد در رکورد نسخه ۱.۳ Zenodo موجود است. این مورد مدرکی برای یک خرید واقعی است، نه یک مطالعه قابلیت اطمینان یا تست استرس برای تزریق پرامپت.
رکورد نسخه ۱.۴ مسیرهای پروتکل اضافه شده، بررسی‌های DNS، شواهد مسیر امضا شده و بررسی‌های رگرسیون مصنوعی را مستند می‌کند، هرچند خرید زنده جدیدی را گزارش نمی‌کند.
این سازوکار، اعتماد را از «تفسیر مدل هوش مصنوعی» به «سوابق رمزنگاری‌شده» منتقل می‌کند. با این روش، مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — فقط نقش کاوشگر را دارند و لایه پرداخت به یک دروازه‌بان سخت‌گیر و قانون‌مند تبدیل می‌شود که فقط بر اساس وضعیت ثبت‌شده تصمیم می‌گیرد.
برای کاربر، این بدان معناست که عامل‌ها می‌توانند به‌طور خودمختار گزینه‌ها را جست‌وجو و مقایسه کنند، بدون اینکه ریسک هزینه‌های «توهم‌زده» (Hallucinated) یا تزریق‌های مخرب تأمین‌کننده وجود داشته باشد.
البته این سیستم هنوز مشکل پرداخت‌های تکراری ناشی از پاسخ‌های مبهم را حل نکرده است که برای رفع آن به قابلیت Idempotency و تطبیق وضعیت پرداخت نیاز است. مثال هش منتشر شده و وضعیت PASS نسخه ۱.۳، تضمین‌های مربوط به تلاش مجدد (Retry) را ایجاد نمی‌کنند.
توسعه‌دهندگان می‌توانند مسیر کامل و تأییدکننده Node.js را در مخزن مرجع پروژه بررسی کنند.
گام بعدی شما
- بررسی مخزن مرجع پروژه برای مطالعه کد تأییدکننده Node.js
- تحلیل استانداردهای ACP و UCP برای یکپارچه‌سازی عامل‌های تجاری
- ارزیابی ریسک‌های تزریق پرامپت در جریان‌های پرداخت فعلی سازمانتان
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو