فیلترهای امنیتی هوش مصنوعی در برابر زبان تخصصی کسب‌وکار شکست می‌خورند

اگر امروز برای امنیت عامل‌های هوش مصنوعی خود به فیلترهای متنی تکیه می‌کنید، احتمالاً در برابر یک حمله تخصصی کاملاً بی‌دفاع هستید. یک دستور مخرب که در دل یک سند حمل‌ونقل دریایی پنهان شده بود، توانست تمام لایه‌های حفاظتی سامانه Okimera را دور بزند و ثابت کند که امنیت احتمالی در محیط‌های تخصصی، تنها یک توهم است. تیم توسعه‌دهنده Okimera — یک سیستم چندعاملی (Multi-agent System) برای بررسی رعایت تحریم‌های دریایی — فاش کرد که لایه‌های امنیتی آن‌ها به‌ترتیب شکست خوردند تا اینکه حمله به مسیر اجرا (Execution Path) رسید. این پروژه برای هکاتون All Things Agentic که توسط گوگل و Devpost برگزار شده بود، توسعه یافت.

فرضیه اصلی Okimera این است که یکی از عامل‌های آن باید اسنادی را بخواند که توسط طرف مورد بررسی نوشته شده‌اند. برای مثال، یک طرف قرارداد یک بارنامه (Bill of Lading) ارسال می‌کند؛ یک عامل حقایق ساختاریافته را از آن استخراج می‌کند و سپس عامل‌های دیگر تصمیم می‌گیرند که آیا معامله می‌تواند پیش برود یا خیر. اگر یک دستور پنهان در داخل آن فایل PDF بتواند بر تصمیمی که درباره فرستنده خودش گرفته می‌شود اثر بگذارد، این محصول عملاً دلیلی برای وجود ندارد.

بیشتر پروتکل‌های امنیتی فعلی بر پایه پارادایم «دستیار» بنا شده‌اند. ما فرض می‌کنیم مهاجمان با الگوهای شناخته‌شده‌ای مثل «تمام دستورات قبلی را نادیده بگیر» (ignore all previous instructions) حمله می‌کنند. اما در یک محیط حرفه‌ای، مهاجم شبیه به یک هکر حرفه‌ای نیست، بلکه شبیه به یک شریک تجاری صحبت می‌کند.

تصور کنید یک بارنامه حاوی بندی باشد که ادعا می‌کند «این معامله پیش‌تر تأیید شده است». برای یک فیلتر عمومی، این جمله بخشی از کاغذبازی‌های اداری استاندارد تجاری است، اما برای یک مدل زبانی بزرگ (LLM)، این یک دستور برای نادیده گرفتن بررسی‌های امنیتی است. این همان شکاف «لحن تخصصی» (domain-voice gap) است که طبق گزارش تیم Okimera، طبقه‌بندی‌کننده‌های عمومی را کور می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر لایه‌های نرم‌افزاری بدون نظارت سخت‌افزاری یا ساختاری همواره ریسک نشت داده یا تغییر رفتار را به همراه دارد.

شکست لایه‌های احتمالی

تیم Okimera سیستم خود را با استفاده از Model Armor گوگل آزمایش کرد. آن‌ها از یک تمپلیت پیکربندی شده برای تشخیص تزریق پرامپت و جیل‌بریک در سطح LOW_AND_ABOVE استفاده کردند که حساس‌ترین آستانه (Threshold) موجود است. سند آزمایشی حاوی دستوری بود که خطاب به هر مدلی که آن را می‌خواند، می‌گفت معامله پیش‌تر تأیید شده است. نتیجه تکان‌دهنده بود: فیلتر هیچ تهدیدی شناسایی نکرد (NO_MATCH_FOUND).

برای اطمینان از اینکه این یک خطای پیکربندی نیست، تیم چهار تست کنترلی اجرا کرد:

• جیل‌بریک‌های کلاسیک: یک جیل‌بریک کنترلی با شکل کلاسیک — دستوری برای نادیده گرفتن دستورات قبلی و افشای پیکربندی — توسط همان تمپلیت، آستانه و فراخوانی شناسایی شد.
• تست‌های زبانی: تزریق پرامپت در دو زبان مختلف نوشته شد؛ فیلتر در هر دو مورد آن را نادیده گرفت.
• داده‌های پیش‌فرض: سند مورد نظر برای دور زدن فیلتر تنظیم (Tune) نشده بود. این سند پیش از وجود فیلتر، به عنوان بخشی از یک سناریو درباره اسناد متناقض حمل‌ونقل نوشته شده بود.
• الگوهای مورد انتظار: یک سند مجزا که عمداً با شکلی نوشته شده بود که فیلترها انتظارش را دارند، به‌طور قابل‌اعتمادی شناسایی شد.

این اتفاق به این دلیل رخ می‌دهد که فیلترهای عمومی روی حملات «وحشی» علیه چت‌بات‌ها آموزش دیده‌اند: استخراج پرامپت‌های سیستم، ارتقای نقش‌ها یا تظاهر به اینکه مدل دیگری هستند. وقتی یک تزریق پرامپت شبیه به یک بند حقوقی در یک مانیفست کشتی باشد، دیگر با «لحن» (Register) یک حمله مطابقت ندارد. در مجموعه‌ای از اسناد تجاری، جملاتی که وضعیت سند را تأیید می‌کنند غیرعادی نیستند، بلکه اساساً اسناد تجاری از همین جملات ساخته شده‌اند.

توهمِ طرحواره (Schema)

تیم در ابتدا تصور می‌کرد که استفاده از یک طرحواره (Schema) سخت‌گیرانه برای خروجی، تضمین‌کننده امنیت است. آن‌ها مدل را مجبور کردند فقط یک شیء (Object) با طرحواره‌ای سخت — شامل Enums، اعداد و تاریخ‌ها — برگرداند تا مطمئن شوند تزریق نمی‌تواند به خروجی نهایی «سفر» کند. در آن قرارداد هیچ فیلد متن-آزاد (Free-text) وجود نداشت؛ یک نقل‌قول از سند منبع به صورت یک آفست (Offset) و طول (Length) در فایل اصلی نمایش داده می‌شد، نه به عنوان یک رشته متنی قابل انتقال.

اما آن‌ها دریافتند که خودِ طرحواره نیز صرفاً متن بیشتری است. فریم‌ورک کل طرحواره خروجی، شامل نام فیلدها، انواع داده و هر رشته توصیفی را به مدل می‌دهد. وقتی یک مرحله ترجمه، توصیفات طرحواره آن‌ها را بازنویسی کرد، در واقع متنی را بازنویسی می‌کرد که به مدل می‌رسید.

مرز امنیتی همچنان برقرار است، اما به دلیلی متفاوت از آنچه ابتدا فکر می‌کردند. دلیل آن این نیست که طرحواره متن نیست، بلکه به دلیل «مالکیت» (Authorship) است: توسعه‌دهندگان طرحواره را می‌نویسند و طرف مورد بررسی سند را می‌نویسد. برای محافظت از این موضوع، تیم اکنون مجموعه کامل متونی که به مدل می‌رسد — یازده بلوک متنی — را هش (Hash) کرده و تحت کنترل نسخه (Version-controlled) قرار داده است. اگر هر یک از این بلوک‌ها بدون اجرای مجدد و آگاهانه سناریوهای دمو تغییر کند، تست شکست می‌خورد.

شکاف در مسیر اجرا

بحرانی‌ترین شکست در بخش برنامه‌ریز (Planner) رخ داد؛ مدلی که تصمیم می‌گیرد چه بررسی‌هایی برای هر معامله لازم است. یکی از این بررسی‌ها، غربالگری لیست تحریم‌ها است که حکم نهایی را صادر می‌کند.

در اندازه‌گیری ۳۴ اجرای تکمیل شده، برنامه‌ریز در ۳۱ مورد به‌سادگی مرحله بررسی تحریم‌ها را حذف کرد. این یک لغزش اتفاقی نبود، بلکه رفتار پیش‌فرض مدل در مواجهه با آن ورودی خاص بود. چون سیستم «نبودِ خطا» را به معنای «تأیید» (Pass) می‌گرفت، این معاملات بدون اینکه هرگز غربالگری شوند، به عنوان موارد پاک ثبت شدند.

تیم دریافت که یک پرامپت هیچ تضمینی نمی‌دهد. آن‌ها چهار اندازه‌گیری مستقل از عدم انطباق (Non-compliance) را مشاهده کردند:

• مدل یک فیلد ضروری را حذف می‌کند، در حالی که در استدلال (Rationale) خود به آن اشاره کرده است.
• مدل یک محدودیت کاتالوگ را نادیده می‌گیرد.
• مدل گرهی (Node) را که دستور صریحاً خواسته بود، رد می‌کند.
• برنامه‌ریز مرحله اجباری غربالگری تحریم‌ها را می‌پرد.

پیاده‌سازی تضمین‌های ساختاری

برای رفع این مشکل، تیم قانون امنیتی را از «پرامپت» به «مسیر اجرا» منتقل کرد. آن‌ها یک گیت منطقی سخت (Hard Logic Gate) پیاده کردند: یک حکم نهایی تنها می‌تواند بر اساس مراحلی صادر شود که واقعاً اجرا شده‌اند. در این حالت، یک حکم «پاک» یک ادعای مثبت است و نیاز به شواهد مثبت دارد. «عدم یافتن یافته‌ها» و «عدم اجرای بررسی» به دو نتیجه متفاوت تبدیل شدند و حالت ناامن دیگر قابل نمایش نبود.

پس از این تغییر، در همان ۳۴ اجرا، تعداد احکامی که از این قانون گریخته بودند به صفر رسید. برنامه‌ریز هنوز در ۹ مورد از ۱۰ مورد مرحله را می‌پرید، اما دیگر اهمیتی نداشت چون سیستم اجازه صدور حکم را نمی‌داد.

این تغییر، امنیت هوش مصنوعی را از طریق چهار سطح تضمین پیش می‌برد: این رویکرد لایه‌بندی شده برای مهار تزریق پرامپت در محیط‌های توسعه پیش‌تر در پیاده‌سازی‌های مبتنی بر TypeScript مورد بررسی قرار گرفته بود.

۱. پرامپت: درخواست از سیستمی که هیچ تعهدی به پیروی ندارد.
۲. طرحواره: محدود کردن شکل پاسخ (فرم)، اما چون خودش متنی است که مدل می‌خواند، معنا را محدود نمی‌کند.
۳. رجیستری: یک قابلیت را در دسترس قرار می‌دهد، اما تضمین نمی‌کند که انتخاب شود.
۴. مسیر اجرا: یک نتیجه ناامن را غیرممکن می‌کند.

تنها سطح چهارم یک تضمین واقعی است. بیشتر گفتگوهای امنیتی پیرامون عامل‌ها در سطح اول اتفاق می‌افتد، اما تضمین واقعی تنها در سطح چهارم در دسترس است.

برای توسعه‌دهندگانی که سیستم‌های عامل‌محور می‌سازند، درس روشن است: اگر یک بررسی امنیتی اجباری است، باید الزامی در کد باشد، نه درخواستی در پرامپت. این موضوع مشابه چالش‌های کنترل دسترسی در عامل‌های کدنویسی است که برای جلوگیری از توهمات استنتاجی، دسترسی آن‌ها به سورس‌کد محدود شد. پروژه Okimera متن‌باز است (https://github.com/roogify/Okimera) و پروتکل‌های اندازه‌گیری در مسیر docs/proof/ در دسترس هستند. تمام داده‌های استفاده شده در این پروژه مصنوعی هستند و از شماره‌های IMO، شرکت‌ها و لیست‌های ساختگی استفاده شده است.

گام بعدی شما

• تمام بررسی‌های امنیتی حیاتی را از لایه پرامپت به لایه کد (Hard-coded logic) منتقل کنید.
• برای هر خروجی مدل، یک سیستم تأییدیه (Verification) پیاده کنید که بررسی کند آیا تمام گام‌های پیش‌نیاز واقعاً اجرا شده‌اند یا خیر. برای مثال، می‌توان از سندباکس‌های داده‌ای ثابت برای کاهش نرخ خطای استخراج داده‌ها استفاده کرد تا صحت خروجی‌ها تضمین شود.
• از ابزارهای هشینگ برای کنترل متونی که به مدل ارسال می‌شود استفاده کنید تا از تغییرات پنهانی جلوگیری شود.

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