تأییدیهٔ جعلی عامل‌های هوش مصنوعی؛ چرا تیک سبز کافی نیست؟

تصور کنید به یک گواهینامه نگاه می‌کنید که تیک سبز تأیید دارد، اما تنها راه بررسی آن، بازگشت به وب‌سایت همان شرکتی است که گواهینامه را صادر کرده است. در این حالت شما چیزی را تأیید نمی‌کنید، بلکه فقط از صادرکننده می‌خواهید برای دومین بار خودش را تأیید کند. این نقص ساختاری در سیستم‌های اعتماد به عامل‌ها (Agents) — که مانند کارمندانی دیجیتال هستند که می‌توانند به‌جای شما کارهای پیچیده را انجام دهند — توسط ColonistOne، مدیر بازاریابی The Colony افشا شد. این پروژه توسط یک عامل هوش مصنوعی (مدل Claude Opus 4.8) هدایت می‌شود که تخصصش در تأیید متقابل بین-عاملی (cross-agent attestation)، اصالت (provenance) و به حداقل رساندن نیاز به اعتماد است.

طبق اعلام این پروژه، بیشتر سیستم‌های فعلی بر پایه «خود-تأیید» (Self-attestation) کار می‌کنند. در این مدل، صادرکننده گواهینامه را امضا می‌کند، سرور همان صادرکننده کد تأیید را اجرا می‌کند و در نهایت همان صادرکننده حکم نهایی را صادر می‌نماید. به نقل از مستندات این پروژه، این روند در واقع «خود-تأیید با مراحل اضافی» است و نه یک تأیید واقعی. در دنیای عامل‌های هوش مصنوعی با ریسک بالا، این وضعیت شبیه به دانش‌آموزی است که برگه امتحان خودش را تصحیح می‌کند و سپس نمره را به عنوان یک حقیقت تأییدشده ارائه می‌دهد. این مسئله برای نخستین بار در مقاله نظری مکمل با عنوان «N تیک سبز می‌توانند یک بیت باشند» (N Green Checks Can Be One Bit) به تفصیل شرح داده شده است. استدلال این مقاله آن است که یک ویژگی تنها زمانی واقعاً قابل تأیید است که به طرفی غیر از کسی که ادعا می‌کند، متصل باشد.

برای حل این مشکل، The Colony مجموعه‌ای از تأییدکننده‌های مستقل، مجزا و متن‌باز را توسعه داد. این ابزارها به عنوان «غریبه» عمل می‌کنند؛ یعنی کدهایی هستند که ادعاهای صادرکننده را کاملاً نادیده می‌گیرند و حقیقت را فقط از طریق بازسازی آثار رمزنگاری‌شده (cryptographic artifacts) استخراج می‌کنند. در این دیدگاه، یک سامانه تنها زمانی «واقعاً قابل تأیید» است که بتوانید بدون اجرای کد صادرکننده یا اعتماد به حرف او، حکم نهایی را بازتولید کنید. این تغییر رویکرد، صنعت را از اتکا به «اعتبار و شهرت» (Reputation) به سمت اتکا به «اثبات ریاضی» (Mathematical Proof) سوق می‌دهد.

مورد اول: شکست پیوند تبار

برخی سیستم‌ها «گواهینامه‌های تولد» امضا شده برای عامل‌های مشتق‌شده ارائه می‌دهند. این سیستم‌ها یک «بسته تبار» (lineage bundle) قابل دانلود فراهم می‌کنند که شامل گواهینامه‌های کامل تمام اجداد است تا امکان پیمایش کل درخت تبار فراهم شود. با اینکه این بسته صادقانه است و شامل یک بلوک تأیید با یک یادداشت مشورتی است که پیشنهاد می‌کند تأیید خارجی انجام شود، اما هیچ ابزاری برای اجرای واقعی این تأیید ارائه نمی‌دهد. تنها تأییدکننده موجود، همان سرور صادرکننده بود؛ به این معنی که یادداشت «فقط مشورتی» عملاً هیچ قدرت اجرایی نداشت.

ColonistOne یک تأییدکننده مستقل با استفاده از امضاهای ed25519 نوشت تا هر نسل از درخت عامل را بررسی کند. این «غریبه‌ی گمشده» به هیچ چیزی از جانب صادرکننده وابسته نیست؛ تنها به خودِ بسته داده‌ها و یک کتابخانه کوچک امضا نیاز دارد تا در هر محیطی اجرا شود. این ابزار به‌طور مشخص حکم مشورتی صادرکننده را نادیده می‌گیرد و در عوض بر مکانیسم‌های زیر تمرکز دارد:

• بازسازی امضا (Signature Re-derivation): استخراج نتایج پذیرش یا رد مستقیماً و صرفاً از طریق امضاهای ed25519.
• پیوند بین‌نسلی (Cross-Generation Linkage): تأیید اینکه هش (Hash) هر جد مجدداً در فرزندش ظاهر شده است تا از سلامت زنجیره تبار اطمینان حاصل شود.
• بررسی ابطال (Revocation Checks): شناسایی و علامت‌گذاری هرگونه گواهینامه ابطال‌شده در داخل بسته.

در یک آزمون فشار حیاتی، پژوهشگر یک گواهینامه واقعی را گرفت و تنها یک بایت از امضای آن را تغییر داد، در حالی که بلوک مشورتی همچنان عبارت «ok» را نشان می‌داد. صفحه تأیید صادرکننده همچنان تیک سبز را نمایش می‌داد، اما تأییدکننده خارجی فوراً عبارت «DIVERGENCE» (واگرایی) را چاپ کرد. این شکاف ثابت می‌کند تیک سبز صادرکننده صرفاً یک تزئین بود و نه یک تضمین رمزنگاری. هنگامی که این ابزار را روی یک گواهینامه زنده مستقیماً از یک API عمومی از طریق URL متمرکز کردند، تأییدیه پاک صادر شد؛ این امر ثابت کرد که می‌توان بدون حضور هیچ‌کدام از کدهای صادرکننده در چرخه، به حکم نهایی رسید.

مورد دوم: توهم شاهدان متعدد

اشتباه رایج دیگر، خطای «تعداد شاهدان» (witness count) است. بسیاری از سیستم‌ها ادعا می‌کنند چون یک رکورد توسط چندین بازرس (مثلاً سه امضاکننده مختلف) امضا شده است، امنیت بالایی دارد. اما یک زنجیره امضا با N امضا، به معنای N شاهد مستقل نیست. اگر دو امضاکننده نتیجه خود را از طریق بازسازی شواهد از یک منبع بالادستی یکسان به دست آورده باشند، آن‌ها در واقع یک شاهد هستند که دو کلاه مختلف سر گذاشته است. توافق آن‌ها اطلاعاتی بسیار اندک بیشتر از یک امضاکننده واحد ارائه می‌دهد.

این یک مشکل شناخته شده در قابلیت اطمینان نرم‌افزار است، به‌ویژه آنچه «مشکل شکست همزمان» (coincident-failure problem) نامیده می‌شود. آزمایش‌های «نایت-لووسون» (Knight–Leveson) نشان داد که نسخه‌های مختلف یک برنامه که به‌طور مستقل توسعه یافته‌اند، اغلب بسیار بیشتر از آنچه پیش‌بینی می‌شد، به‌صورت همزمان شکست می‌خورند. این موضوع بعدها توسط «لیتل‌وود» و «میلر» مدل‌سازی شد. تلاش‌های مدرن در زمینه «تنوع ساخت» (build-diversity) — مانند آنچه در مقاله arXiv:1409.7324 دیده می‌شود و از زنجیره‌های ابزاری و زیرساخت‌های مختلف استفاده می‌کند — در واقع عملیاتی کردن همین بینش است. این همان منطقی است که شرکت SolarWinds پس از به 타협 (compromise) شدن خط لوله ساخت خود، به آن روی آورد. این رویکرد به ویژه در شناسایی خطاهای سیستمی کاربرد دارد؛ برای مثال، رویکرد شرکت 137Foundry در شناسایی سریع توهمات کدنویسی بر همین اصلِ نیاز به بررسی‌های چندگانه و دقیق استوار است.

برای مقابله با این توهم، تأییدکننده جدید از یک الگوریتم union-find استفاده می‌کند که کلید آن «هش محتوایی» (content-hash) شواهدی است که توسط امضاکنندگان ذکر شده است:

• تفکیک شواهد (Evidence Resolution): اگر دو امضاکننده به شواهدی ارجاع دهند که به یک هش یکسان ختم می‌شود، ابزار آن‌ها را به یک شاهد واحد تقلیل می‌دهد.
• اصالت اعلام‌نشده (Undeclared Provenance): هر امضاکننده‌ای که به هیچ شواهدی با آدرس محتوایی ارجاع ندهد، هیچ امتیازی برای استقلال دریافت نمی‌کند. چنین برچسب‌هایی به عنوان «همبسته-مفروض» (assumed-correlated) تلقی می‌شوند، زیرا برچسبی که قابل بررسی نیست، برچسبی است که یک مهاجم می‌تواند به‌راحتی و رایگان جعل کند. این آسیب‌پذیری‌ها دقیقاً همان جایی هستند که حملات از طریق اسکریپت‌های غیرفعال در اتوماسیون‌های هوشمند رخ می‌دهند، جایی که اعتماد به محتوای اعلام‌شده بدون بررسی اصالت، منجر به رخنه در سیستم می‌شود.
• مخرج صادقانه (Honest Denominator): خروجی ابزار، تعداد واقعی و صادقانه‌ای را ارائه می‌دهد؛ مثلاً «۳ امضا $\rightarrow$ ۲ شاهد مستقل واقعی»، که هر کسی با داشتن پاکت داده‌ها می‌تواند آن را مجدداً محاسبه کند.

مشخصات تکمیلی در مخزن کد (Repository) به این موضوع می‌پردازند که چگونه «استقلال» را به جای یک مقدار اعلام‌شده، به یک مقدار اندازه‌گیری‌شده تبدیل کنند؛ این کار با استفاده از بردارهای خطا از یک اندازه‌گیر مستقل صورت می‌گیرد که بر اساس پروب‌های منتخب توسط «بیکن» (beacon) امتیازدهی می‌شوند. دلیل این کار آن است که ادعاهای «استفاده از مدل‌های مختلف» را می‌توان به‌راحتی از طریق حساب‌های جعلی (sock-puppets) جعل کرد. این تلاش برای حذف لایه‌های غیرقابل اعتماد، مشابه روشی است که برخی موتورهای آزمون برای متوقف کردن توهمات هوش مصنوعی بخش‌های زائد و گمراه‌کننده محتوا را حذف می‌کنند تا دقت خروجی افزایش یابد.

دستورالعمل سه مرحله‌ای برای تأیید

برای رهایی از اعتماد کورکورانه، The Colony این دستورالعمل جهانی را برای هر سیستم اصالتی پیشنهاد می‌کند:

۱. بازیابی اثر (Artifact Retrieval): دریافت اثر (گواهینامه، بسته، رسید یا لنگر/anchor) از سطح عمومی صادرکننده — یعنی هر چیزی که آن‌ها به یک غریبه تحویل می‌دهند.
۲. بازتولید مستقل (Independent Re-derivation): بازسازی حکم با استفاده از کدی که متعلق به صادرکننده نیست. بررسی امضاها، محاسبه مجدد هش‌ها و حل لنگرهای خارجی. نکته حیاتی این است که هرگز فیلد «حکم» صادرکننده را نخوانید؛ خودتان آن را محاسبه کنید.
۳. مقایسه (Comparison): مقایسه نتیجه مستقل با ادعای صادرکننده. هرگونه واگرایی یا تفاوت را به عنوان یک «سیگنال» (خطای واقعی) تلقی کنید، نه «نویز».

این تأییدکننده‌ها عمداً کوچک هستند و تنها از چند صد خط کد کتابخانه استاندارد و یک ابزار اولیه امضا تشکیل شده‌اند. این طراحی مانع از آن می‌شود که کاربران در تله اعتماد به یک وابستگی (Dependency) سنگین که توسط صادرکننده ارائه شده می‌افتند، زیرا این کار صرفاً مشکل اعتماد را به لایه دیگری از پشته (stack) منتقل می‌کند. یک نتیجه‌گیری مهم این است که یک «خود-آزمایی» (self-test) که مقداری را که اثبات ادعا می‌کند می‌خواند (به جای محاسبه مجدد آن)، می‌تواند روی اثباتی پاس شود که یک بازسازی مستقل آن را رد می‌کند. خواندن پاسخ، با بررسی پاسخ متفاوت است.

این رویکرد، کل دیسیپلین نظارت بر عامل‌ها را تغییر می‌دهد. The Colony با انتقال مرحله مورد اعتماد به جایی دور از طرف ادعاکننده، قصد دارد نحوه مدیریت دروازه‌های انتشار (release gates)، نظارت چند-مدلی، حافظه عامل‌ها و گزارش‌های حسابرسی را استاندارد کند. این روش، مفهوم مبهم «اعتبار ارائه‌دهنده» را با یک استاندارد حقیقتِ سخت‌گیرانه و باز-محاسبه‌پذیر جایگزین می‌کند. برای کسانی که جریان‌های کاری عاملی (agentic workflows) را مستقر می‌کنند، درس روشن است: تیک سبزی که با رمزنگاری در تضاد است، مفیدترین اطلاعاتی است که می‌توانید پیدا کنید. هدف این است که اطمینان حاصل شود یک سیستم می‌تواند از تمرینات داخلی خود پاس شود، اما همچنان در برابر تدقیق و بررسی یک «غریبه» تاب بیاورد.

گام بعدی شما

• اگر از عامل‌های هوش مصنوعی در محیط عملیاتی استفاده می‌کنید، بررسی کنید آیا گواهینامه‌های آن‌ها توسط شخص ثالث یا کد مستقل قابل بازبینی است یا فقط یک API «تأیید شد» برمی‌گرداند.
• برای توسعه‌دهندگان: هنگام طراحی سیستم‌های Trust-minimization، از امضاهای استاندارد مثل ed25519 استفاده کنید تا کاربران بتوانند بدون کد شما، صحت داده را بفهمند.
• به دنبال ابزارهای متن‌باز تأییدکننده در GitHub برای بررسی اصالت مدل‌های مشتق‌شده باشید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.