تصور کنید یک عامل هوش مصنوعی به شما اطمینان می‌دهد که قطعه‌ای از کد را بررسی کرده و آن را «تأیید شده» می‌نامد. شما یک رسید دیجیتال با یک هش و حکم «درست» می‌بینید، اما در واقعیت، این رسید هیچ دلیلی بر بررسی کد نیست و فقط ثابت می‌کند که عامل ادعا کرده است کد بررسی شده است.
در ۶ اکتبر ۲۰۲۶، یک توسعه‌دهنده با استفاده از یک اسکریپت ۴۰ خطی ثابت کرد که اکثر رسیدهای تأیید فعلی عملاً بی‌فایده هستند. او از یک تأییدکننده «no-op» — یعنی سیستمی که هیچ بررسی واقعی انجام نمی‌دهد — استفاده کرد تا رسیدی تولید کند که دقیقاً با ساختار یک بررسی سخت‌گیرانه و واقعی مطابقت داشت.
به نقل از تحلیل فنی منتشر شده در dev.to، این نقص در نحوه اتصال (Binding) داده‌ها نهفته است. اکثر طرح‌ها، حکم نهایی را به بایت‌های یک اثر متصل می‌کنند، اما نمی‌توانند آن بایت‌ها را به یک شرط تغییرناپذیر و مشخص گره بزنند. این یعنی یک تأییدکننده صوری می‌تواند بدون اجرای حتی یک خط کد تست، رکورد «تأیید شده: درست» را صادر کند. این چالش با شکاف‌های خطرناک در حاکمیت هوش مصنوعی که پیش‌تر در مورد عدم تطابق شناسه‌ی مدل با خروجی بررسی کرده بودیم، هم‌سو است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی‌های مدل بدون لایه‌ی نظارتی مستقل، ریسک‌های امنیتی بزرگی ایجاد می‌کند. در این مورد، مشکل از خودِ مدل نیست، بلکه از معماری سیستم تأیید است.
برای درک این شکست، نویسنده سه سطح از رسیدها را بررسی می‌کند:
- رسید سطح ۱ (سوراخ امنیتی): یک رکورد ساده شامل هش اثر و حکم نهایی. در این حالت، خروجی یک تأییدکننده واقعی و یک تأییدکننده جعلی کاملاً یکسان است.
- رسید سطح ۲ (اصلاح کاذب): اضافه کردن یک شناسه بررسی (
check_id) و امضای نام بررسی. این روش شکست می‌خورد چون اگر همان فرآیندی که حکم را صادر می‌کند، کلید امضا را هم داشته باشد، می‌تواند نام بررسی‌ای را امضا کند که هرگز اجرا نکرده است. - رسید سطح ۳ (راهکار نهایی): انتقال کلید امضا به یک اوراکل (Oracle) — شبیه به یک داور مستقل که در اتاق جداگانه نشسته و فقط نتایج واقعی را امضا می‌کند. در اینجا، کاربر اثر و شناسه بررسی را می‌فرستد و اوراکل کد ثبت‌شده را اجرا کرده و نتیجه را امضا می‌کند. این رویکرد در واقع تکامل‌یافته‌ی قفل هش اوراکل است که برای جلوگیری از تقلب عامل‌های هوش مصنوعی در آزمون‌ها پیشنهاد شده بود.
این تغییر باعث می‌شود که یک تأییدکننده صوری نتواند حکم «درست» بگیرد، چون هیچ کنترلی روی منطق اجرای داخل اوراکل ندارد. امنیت در اینجا از یک طرح که سعی می‌کند جعل را «منع» کند، به یک معماری کلید منتقل می‌شود که جعل را از نظر ریاضی غیرممکن می‌کند.
طبق گزارش کاربر @slabb، تأییدکننده‌ای که همیشه حکم «درست» صادر می‌کند، هیچ اطلاعات مفیدی ارائه نمی‌دهد. برای تست خط لوله (Pipeline) خود، باید یک تست را عمداً شکست دهید؛ اگر رسید «غلط» صادر نشد، یعنی سیستم تأیید شما صرفاً یک تزیین است.
گام بعدی شما
- اگر از سیستم‌های تأیید خودکار در CI/CD استفاده می‌کنید، یک تست شکست‌خورده (Failing Probe) را به جریان کاری خود اضافه کنید تا صحت رسیدها را بسنجید.
- بررسی کنید که آیا کلید امضای رسیدهای شما در همان محیط اجرای کد است یا در یک سرویس اوراکل مجزا.
- معماری سیستم‌های عامل‌محور خود را از مدل «اعتماد به گزارش» به مدل «اعتماد به اجرای مستقل» تغییر دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو