اگر امروز به لاگ‌های یک عامل هوش مصنوعی برای اثبات صحت عملکردش اعتماد می‌کنید، احتمالاً در حال تماشای یک حقیقت دست‌کاری‌شده هستید. یک تست استرس امنیتی روی AIR Blackbox نشان داد که ۱۷ مورد از ۷۵ حمله هدفمند، توانسته‌اند سیستم را فریب دهند تا لاگ‌های جعلی را به‌عنوان داده‌های تأییدشده بپذیرد. سازنده این ابزار یک هفته را صرف تلاش برای «دروغ‌گویی» به سیستم ضبط وقایع کرد. نتیجه تکان‌دهنده بود: خطرناک‌ترین نقاط ضعف نه در رمزنگاری، بلکه در شکاف میان آنچه ابزار بررسی می‌کند و آنچه به کاربر گزارش می‌دهد نهفته است.
زمینه: فشار برای پاسخگویی در هوش مصنوعی
این آسیب‌پذیری در حالی رخ می‌دهد که آزمایشگاه‌های هوش مصنوعی تحت فشار شدید برای ارائه مسیرهای بازرسی شفاف هستند. در ۱۲ سپتامبر ۲۰۲۴، داریو آمودی (Dario Amodei) در مقاله‌ای تأکید کرد که شرکت‌ها و دولت‌ها باید سرعت پیشروی در مرزهای هوش مصنوعی را کنترل کنند (pace the frontier). او به‌طور مشخص استدلال کرد که آزمایشگاه‌ها باید ارزیابان شخص ثالثی را در ساختار خود جای دهند که حوادث را گزارش کنند. سم آلتمن (Sam Altman) نیز اعلام کرد که OpenAI از این رویکرد پیروی خواهد کرد.
آمودی به یک حادثه اخیر مربوط به «عامل‌های سرکش» (rogue-agent) به عنوان هشدار برای آینده اشاره کرد. برای هر شرکتی که یک عامل هوش مصنوعی را عرضه می‌کند، سؤال دیگر این نیست که آیا عامل اشتباه کرده است یا خیر، بلکه سؤال این است که آیا لاگ‌های اثبات‌کننده اقدامات او قابل اعتماد هستند؟ وقتی یک مشتری یا رگولاتور می‌پرسد چرا یک عامل تصمیمی خاص گرفته، پاسخ «به لاگ‌های ما اعتماد کنید» کافی نیست، چون لاگ‌ها در اختیار طرفی است که بیشترین انگیزه برای ویرایش آن‌ها را دارد.
تصور کنید یک عامل هوش مصنوعی مسئول بازپرداخت وجه مشتریان شرکت است. اگر عامل اشتباهی مرتکب شود، شرکت یک لاگ ارائه می‌دهد. اما اگر مالک لاگ‌ها خود شرکت باشد، انگیزه‌ای شدید برای ویرایش آن‌ها دارد تا خطاها را بپوشاند. AIR Blackbox سعی می‌کند این مشکل را با نوشتن اقدامات در یک زنجیره هش (Hash Chain) حل کند؛ به گونه‌ای که هر تصمیم، امضای Ed25519 مخصوص به خود را حمل می‌کند. این زنجیره توسط یک مرجع خارجی زمان‌بندی (Timestamp) می‌شود که کلید آن در اختیار سازنده ابزار نیست. این فرآیند یک فایل با پسوند .air-evidence ایجاد می‌کند که هر کسی می‌تواند آن را در مرورگر خود در آدرس airblackbox.ai/verify بررسی کند، بدون اینکه نیازی باشد به توسعه‌دهنده اعتماد کند.
کالبدشکافی شکست‌ها
۷۵ حمله انجام شده در ۶ محور یا لنز مختلف دسته‌بندی شدند: کانتینر ZIP، مانیفست امضا شده، رکوردها و زنجیره، رسیدها و شمارش‌ها، برچسب زمانی خارجی، و نحوه انتساب یافته‌ها. در حالی که ۲۳ حمله بلافاصله توسط کدهای موجود متوقف شدند، ۴۳ مورد به عنوان «شکست» (Break) ادعا شدند. پس از ارسال این موارد به یک بازبین مستقل که دستور داشت در صورت عدم امکان بازتولید دقیق شکست، آن را «رد» (Refuted) کند، ۱۷ مورد باقی ماندند. این ۱۷ مورد به ۸ علت ریشه‌ای متمایز بازمی‌گشتند.
یکی از شکست‌های اصلی مربوط به مدیریت فایل‌های ZIP بود. مهاجم یک رکورد جعلی را در ابتدا و یک رکورد واقعی را در جایگاه دوم در کانتینر ZIP قرار داد. به دلیل اینکه کتابخانه zipfile در پایتون آخرین ورودی را می‌خواند، در حالی که ابزارهای unzip، خواننده‌های استریم و اکثر ابزارهای دیگر اولین ورودی را می‌خوانند، سیستم اعتبارسنجی فایل را «سالم» می‌دید، اما هر بازرس انسانی که از ابزارهای استاندارد استفاده می‌کرد، نسخه جعلی را مشاهده می‌کرد. در نتیجه، سیستم پیام «OK - VERIFIED» می‌داد، در حالی که کاربر بازبینی انسانی‌ای را می‌دید که هرگز رخ نداده بود. همین ترفند روی خودِ مانیفست امضا شده نیز جواب داد. راه حل این مشکل، رد کردن نام‌های تکراری پیش از محاسبه هرگونه دایجست (Digest) بود. این نوع از حملات که بر اساس فریب دادن سیستم‌های نظارتی با استفاده از داده‌های پنهان یا متناقض است، یادآور رویکرد مشابهی در حملات مهندسی اجتماعی است که در آن از متون نامرئی برای دور زدن فیلترها استفاده شد تا داده‌های حساس استخراج شوند.
نقص بحرانی دیگر در شمارش‌های خلاصه مانیفست (Manifest Summary Counts) یافت شد. مانیفست حاوی شمارش‌هایی برای اقدامات، اقدامات مسدود شده و تصمیمات نامطلوب است. سیستم اعتبارسنجی ۵ مورد از ۸ شمارش را مجدداً محاسبه می‌کرد اما ۳ مورد را نادیده می‌گرفت: adverse_decisions (تصمیمات نامطلوب)، adverse_decisions_missing_reviewer (تصمیمات نامطلوب بدون بازبین) و engine_outputs_without_reviewer (خروجی‌های موتور بدون بازبین). این‌ها دقیقاً همان شمارش‌هایی هستند که برای شناسایی نبودِ بازبینی انسانی استفاده می‌شوند. یک بسته می‌توانست ادعا کند هیچ ردپایی از رد کردن‌های بدون بازبین وجود ندارد، در حالی که رکوردها صراحتاً یکی از آن‌ها را نشان می‌دادند؛ سپس آن را به‌درستی امضا کرده و تأییدیه «سالم» بگیرد. گزارش صراحتاً ذکر می‌کند: «امضا کردن یک خلاصهٔ دروغین، آن را تبدیل به حقیقت نمی‌کند؛ بلکه آن را به یک دروغِ مستند تبدیل می‌کند.»
سایر شکست‌های فنی عبارت بودند از:
- اعتبارسنجی امضاهای خالی: رکوردهایی که رسید نداشتند، نادیده گرفته می‌شدند. اگر یک بسته هیچ رسیدی نداشت، سیستم پیام «تمام امضاها معتبرند» را چاپ می‌کرد. این از نظر منطقی درست بود، همان‌طور که جمله «تمام تک‌شاخ‌های من سالم هستند» درست است (چون اصلاً تک‌شاخی وجود ندارد). راه حل فعلی این است که گزارش دهد: «۰ از N رکورد دارای رسید هستند - هیچ چیزی در اینجا بررسی نشد.»
- حفره استثنای دایرکتوری: برای مسدود کردن فایل‌های بدون امضا، یک گارد اضافه شده بود تا هر عضوی که در مانیفست امضا شده لیست نشده بود را رد کند، مگر ورودی‌های دایرکتوری (نام‌هایی که به / ختم می‌شوند). اما ZIP الزام نمی‌کند که نامی که به / ختم می‌شود حتماً خالی باشد. یک مهاجم می‌توانست فایلی را به نام
attachments/reviewer_signoff.pdf/نام‌گذاری کند تا گارد را دور بزند. اکنون این ورودی‌ها باید صفر بایت باشند. - جعل لنگر آفلاین: بسته‌ها می‌توانند در یک لاگ شفافیت عمومی (Public Transparency Log) لنگر انداز شوند. سیستم اعتبارسنجی، امضای رسیدِ لاگ را با کلید عمومی‌ای که خودِ رسید حمل می‌کرد، چک می‌کرد. در حالت آفلاین، این فقط ثابت می‌کرد که رسید با خودش همخوانی دارد. یک مهاجم می‌توانست کلید خودش را بسازد و برای هر سرِ زنجیره‌ای (Chain Head) یک رسید امضا کند. راه حل، معرفی پرچم
--rekor-verifyبود تا ورودی را واکشی کرده و وجود آن را در لاگ واقعی تأیید کند.
شکاف غیرقابل حل
سازنده ابزار اشاره کرد که یک مسئله بنیادین وجود دارد که نمی‌توان آن را به‌طور کامل حل کرد: هر کلیدی می‌تواند اعتبارسنجی کند. بسته، کلید عمومی خودش را حمل می‌کند. اگر مهاجم یک جفت کلید جدید بسازد، رکوردهای دلخواه خود را جمع‌آوری کرده و آن‌ها را امضا کند، نتیجه به‌طور کامل «تأیید شده» (Verified) خواهد بود. وضعیت VERIFIED فقط به این معناست که فایل دست‌نخورده است و از زمان امضا تغییر نکرده است؛ این وضعیت هویت نویسنده را ثابت نمی‌کند. یک فایل خود-توصیف‌گر نمی‌تواند هویت نویسنده خود را احراز کند.
برای کاهش این ریسک، اکنون پرچم --expect-key اضافه شده تا کاربر بتواند یک امضاکننده خاص را با استفاده از اثر انگشتی (Fingerprint) که به‌طور مستقل به دست آورده، پین کند. بدون این پرچم، حکم نهایی به‌طور صریح عبارت «VERIFIED (UNATTRIBUTED, UNWITNESSED)» را نمایش می‌دهد. همچنین یک پرچم --strict اضافه شد تا هر چیزی که پین نشده یا به‌طور خارجی لنگر انداز نشده است را رد کند. این حالت پیش‌فرض نیست، زیرا اگر ابزار اکثر فایل‌های دنیای واقعی را رد می‌کرد، کاربران احتمالاً بررسی را به‌طور کلی غیرفعال می‌کردند.
شکست‌های پس از گزارش
حتی پس از گزارش اولیه، دو باگ دیگر در این ماه ظاهر شد. یکی مربوط به سازگاری مرورگر بود. در مرورگرهایی که از Ed25519 پشتیبانی نمی‌کردند، صفحه پیام «امضا در این مرورگر قابل بررسی نیست» را چاپ می‌کرد، اما تیتر بالای آن همچنان می‌گفت: «اصیل... محتویات واقعی و دست‌نخورده هستند». این مورد اصلاح شد تا عبارت «در این مرورگر قابل تأیید نبود» را نشان دهد.
شکست دیگر در اجرای سیاست‌ها (Policy Enforcement) رخ داد. قانونی وجود داشت که استخراج ویژگی‌های محافظت‌شده مانند نژاد، سلامت یا مذهب را ممنوع می‌کرد. تغییری که اجازه یک اقدام جدید برای تگ‌گذاری ماشینی (Machine-tagging) را می‌داد، حاوی کامنتی بود که می‌گفت قانون مذکور همچنان اعمال می‌شود. اما قوانین بر اساس «نام اقدام» تطبیق می‌یابند، نه «محتوای تگ». یک پارسر که کسی را تحت نام جدید «احتمالاً بالای ۵۵ سال» تگ می‌کرد، مجاز شناخته شد. تستی که برای اثبات اینکه قانون «همچنان پابند است» نوشته شده بود، هم قبل و هم بعد از تغییر پاس شد، در حالی که عملاً هیچ چیزی را ثابت نمی‌کرد. اکنون تگ‌گذاری ماشینی ممنوع است مگر اینکه تولیدکننده یک واژگان کنترل‌شده (Controlled Vocabulary) را تأیید کند که خود این تأییدیه نیز ثبت می‌شود.
الگوی شکست
رشته مشترک در تمام این ۱۷ شکست، ضعف در رمزنگاری نبود؛ الگوریتم Ed25519 همچنان امن است. در عوض، شکست‌ها عبارت بودند از «جملات اطمینان‌بخش که روی بررسی‌هایی قرار داشتند که اصلاً آن جملات را پشتیبانی نمی‌کردند». ابزار به انسان می‌گفت همه چیز مرتب است، بدون اینکه واقعاً بررسی لازم را برای به دست آوردن آن جمله انجام داده باشد.
برای توسعه‌دهندگانی که ابزارهای پاسخگویی هوش مصنوعی می‌سازند، این یک درس است: ریسک در الگوریتم نیست، بلکه در رابط کاربریِ بازرسی (Audit UI) است. هر بار که ابزاری به کاربر می‌گوید فرآیند «تأیید شده» یا «ایمن» است، توسعه‌دهنده باید بپرسد دقیقاً چه چیزی بررسی شده تا این ادعا توجیه شود.
اگر امروز در حال استقرار عامل‌ها هستید، می‌توانید این را خودتان تست کنید: pip install air-blackbox. این ابزار به شما اجازه می‌دهد اقدامات را ثبت کنید — مثلاً rec.action("issue_refund", "order 991, $40", human_reviewer="[email protected]") — و آن‌ها را در airblackbox.ai/verify تأیید کنید. کد این پروژه تحت لایسنس Apache 2.0 در github.com/airblackbox/airblackbox در دسترس است.
گفتگو