یک بلوک کد ساده از هوش مصنوعی میتواند در چند ثانیه ۸۰۰ گیگابایت داده را از سیستم شما پاک کند. این اتفاق که برای کاربری با مدل Gemini 3 و محیط توسعه CursorAI رخ داد، هشداری جدی است: خروجی مدل هرگز نباید مجوز اجرای خودکار داشته باشد. در این مورد خاص، یک توسعهدهنده کدی را که با کمک Gemini 3 در محیط IDE CursorAI تولید شده بود اجرا کرد و نتیجه آن حذف تقریباً ۸۰۰ گیگابایت فایل، از جمله خودِ اپلیکیشن CursorAI بود. اگرچه این مورد یک گزارش کاربر است و نه یک کالبدشکافی فنی تأییدشده، اما درس مهندسی آن جهانی است: کدهای پاکسازی تولیدشده توسط AI هرگز نباید دسترسی نامحدود به سیستم داشته باشند.
همانطور که در تحلیل قبلی ما دربارهی درِ پشتی کتابخانه LiteLLM اشاره کردیم، جایی که یک پنجره زمانی کوتاه در PyPI باعث افشای کلیدهای ایجنتها شد، ریسکها اکنون از حملات زنجیره تأمین خارجی به سمت شکستهای اجرایی داخلی تغییر کردهاند. برای اکثر برنامهنویسان، خطر اصلی یک هکر بدخواه نیست، بلکه یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — است که با اعتمادبهنفس کامل، دستور rm -rf را در یک تسک سادهی پاکسازی پیشنهاد میدهد. باور کنید که توضیحات متقاعدکننده مدل و کدهای بهظاهر منطقی، دلیلی بر ایمن بودن مدیریت مسیرهای دسترسی به فایل نیست.
سه لایه ریسک اجرایی
کنترلهای امنیتی باید «حذف کدهای مخفی» را به جای یک تسک پاکسازی متنی، به عنوان یک مسئله امنیتی اجرا ببینند. این امر مستلزم تعیین این است که یک آرتیفکت چه کارهایی میتواند انجام دهد، شناسایی منبع دستورات آن و محدود کردن قابلیتها پیش از زمان اجرا است. طبق گزارشی که در ۲۲ سپتامبر ۲۰۲۶ در dev.to منتشر شد، سیستمهای امنیتی باید با سه دسته تهدید متمایز مقابله کنند:
- دستورات خصمانه (Adversarial Instructions): دستوراتی که در صفحات وب بازیابیشده، فایلهای PDF، پاسخهای پلاگینها، کامنتها، حاشیهنویسیها یا متادیتای اسناد نهفتهاند. این موارد زمانی به «تزریق پرامپت غیرمستقیم» تبدیل میشوند که محتوای خارجی تلاش کند مسیر مدل را منحرف کند. این موضوع یادآور آن است که چگونه مستندات وبسایتها میتوانند به درگاهی برای نفوذ عاملهای هوش مصنوعی تبدیل شوند و کدهای ناخواسته را وارد سیستم کنند. OWASP تزریق پرامپت را به عنوان یک دسته رسمی از ریسکهای LLM به رسمیت شناخته است.
- محتوای پنهان (Concealed Content): استفاده از کاراکترهای با عرض صفر (zero-width)، همشکلها (homoglyphs)، بارهای دادهای base64 یا hex، رشتههای فشرده، HTML/JS مخفی و محتوای جاسازی شده در تصاویر یا لایههای سند. گزارشهای تهدید سال ۲۰۲۵، جریانهای کاری «مبهمسازی با کمک AI» را توصیف میکنند که در آن مدلها را برای تولید و تبدیل این بارهای مخرب به صورت زنجیرهای به کار میگیرند.
- رفتارهای ناایمن (Unsafe Behavior): اجرای پویا، ایجاد زیرپردازشها (subprocess)، دسترسی به شبکه، نصب وابستگیها یا عملیات تخریبی در سیستم فایل. این موارد برای ایجاد خسارت نیازی به پنهان شدن یا قصد بدخواهانه ندارند. یک درخواست ساده برای «پاکسازی» میتواند بدون دخالت هیچ مهاجمی، دستور
rm -rf /path/to/dirیاshutil.rmtree()تولید کند. این نوع رفتارهای پیشبینینشده بخشی از ۵ حفرهٔ امنیتی رایج در کدهای تولیدشده توسط AI هستند که نیازمند روشهای اصلاحی دقیقاند.
پیادهسازی دروازه امنیتی
برای جلوگیری از تخریب تصادفی، توسعهدهندگان باید یک خط لوله (Pipeline) سختگیرانه بین تولید کد و اجرای آن ایجاد کنند. این فرآیند باید در سیاستهای CI/CD و سیاستهای اجرای ایجنتها نهادینه شود، نه اینکه صرفاً یک یادآوری کنار دکمه اجرا باشد.
این مسیر با حفظ و ثبت پاسخ اصلی، تاریخچه گفتگو، پرامپت سیستمی، اسناد بازیابیشده و نتایج پلاگینها آغاز میشود. ثبت جداگانه منبع استخراجشده، به همراه هر تغییر و تصمیم تأیید، یک «سلسله مراتب منشأ» (Provenance) ایجاد میکند. این کار به بازرسان کمک میکند تا تشخیص دهند آیا رفتار مشکوک پس از ورود یک سند خاص یا پاسخ یک ابزار به کانتکست مدل ظاهر شده است یا خیر.
کدها باید با استفاده از مدیریتهای آگاه به زبان، از میان متون عادی و بستهبندیهای Markdown یا HTML استخراج شوند. توسعهدهندگان نباید شواهد را بیصدا دور بریزند، بلکه باید کامنتها و متادیتاها را برای یافتن دستورات مخفی بازرسی کنند. اگرچه ابزارهایی مثل Black یا Prettier کد را مرتب میکنند، اما فرمتبندی هرگز جایگزین بررسی امنیتی نیست.
توجه ویژهای به نرمالسازی یونیکد (Unicode) لازم است. کاراکترهایی مانند U+200B، U+200C، U+200D و U+FEFF باید به دقت بررسی شوند. از آنجایی که حذف کاراکترها میتواند رشتهها یا رفتارهای خاص زبانی را تغییر دهد، سیستم باید به جای ارائه یک نتیجه «پاکشده» بدون مستندات، یک diff (تفاوت) بصری تولید کند.
طبقهبندی قابلیتها و محرکهای بازبینی
پیش از تأیید، خط لوله باید بررسیهای ارزانقیمتی را اجرا کند. این شامل پارس کردن منبع، اجرای linterها و قوانین امنیتی، و اسکن برای یافتن اعتبارنامهها (credentials)، منابع مشکوک وابستگیها، بلوکهای کدگذاری شده و دستورات ساخته شده به صورت پویا است.
بازبینها باید در صورت مشاهده موارد زیر هشدار دریافت کنند:
- دستورات خطرناک: مانند
sudo،rm -rf،shutil.rmtree،subprocess.Popen،os.system،evalوexec. - مسیرهای حساس: مسیرهای مطلق غیرمنتظره مانند
/home/یا:C. - الگوهای مبهم: نامهای API متصل شده به هم، زنجیرههای
chr()، فراخوانیهای بازتابی (Reflective calls) و رشتههای طولانی و نامفهوم.
پس از این بررسیها، سیستم باید جریان داده (Data Flow) را تحلیل کند. باید پرسیده شود: آیا یک مسیر تأییدنشده میتواند به یک حذف بازگشتی (recursive delete) منجر شود؟ آیا متن بازیابیشده میتواند بخشی از یک دستور shell شود؟ آیا یک رشته رمزگشایی شده به یک تابع اجرایی میرسد؟
یک موتور قانونگذار یا یک مدل ثانویه میتواند رفتار را به دستههای «خواندنی»، «نوشتنی»، «حذفی»، «شبکهای» یا «نصب» تقسیم کند. این طبقهبندی باید مسیر بازبینی را هدایت کند — بهویژه برای عملیات نوشتن و حذف — اما هرگز نباید به عنوان تنها مرز مجوز نهایی عمل کند. در واقع، تکیه بر مدلهای زبانی برای این تحلیلها میتواند چالشبرانگیز باشد، چرا که محدودیتهای مدلهای زبانی در ممیزی خودکار کد نشان میدهد که آنها همیشه قادر به شناسایی پیچیدگیهای امنیتی نیستند.
خنثیسازی به جای پاکسازی
پاکسازی صرفاً نمایش یا بستهبندی نامطلوب را حذف میکند، اما خنثیسازی (Neutralization) مانع از رفتار میشود. من ترجیح میدهم در یک عملیات تأییدنشده با یک استثنای (Exception) صریح مواجه شوم تا اینکه خطوط کد را تا زمانی که برنامه بیضرر به نظر برسد، حذف کنم.
با استفاده از بازنویسی مبتنی بر AST (درخت نحو انتزاعی)، یک سیستم میتواند اجرای پویا را با یک شکست کنترلشده جایگزین کند، مثلاً با پیام «رفتار پویای ناایمن مسدود شد». سپس Wrapperهای تأییدشده میتوانند محدودیتهای زمانی (timeout) زیرپردازشها و سیاستهای اجرا را اعمال کنند، در حالی که آداپتورهای Mock میتوانند فراخوانیهای سرویسهای دارای امتیاز را در طول تست جایگزین کنند. هیچیک از این تکنیکها نیاز به بازبینی منبع بازنویسی شده را از بین نمیبرد.
سیاستهای سختگیرانه باید مراحل نصب pip و npm تولیدشده توسط AI را تا زمانی که وابستگیها اعلام و از طریق یک رجیستری خصوصی تأیید شوند، مسدود کنند. به همین ترتیب، کلیدهای API و توکنهای واقعی باید در مرحله ارزیابی حذف شوند تا از نشت دادهها جلوگیری شود. برای تمام ماژولهای مجاز، نقاط انتهایی (endpoints)، مکانهای سیستم فایل و اجراکنندههای خارجی، یک سیاست صریح مورد نیاز است.
اعتبارسنجی فنی و ایزولهسازی
تحلیل استاتیک کافی نیست چون نمیتواند بارهای مخرب تأخیری یا شرطی را شناسایی کند. تستهای زمان اجرا باید در کانتینرهای موقت یا میکرو-ماشینهای مجازی (microVMs) با استفاده از فناوریهایی مانند gVisor یا Firecracker انجام شود. این محیطها نباید دسترسی به شبکه، اعتبارنامههای میزبان یا نقاط اتصال (Mounts) سیستم میزبان داشته باشند.
این محیطها باید محدودیتهای syscall را از طریق seccomp در کنار ایزولهسازی سیستم فایل اعمال کنند. فیلتر کردن syscall به تنهایی یک سیاست نوشتن مبتنی بر مسیر نیست. برای ایمنتر کردن محیط، توسعهدهندگان باید CPU، حافظه و زمان اجرا را محدود کرده و هرگونه I/O ضروری را از طریق یک رابط اعمال سیاست (policy-enforcing interface) مدیریت کنند.
با اجرای کد روی دایرکتوریهای مصنوعی حاوی فایلهای نگهبان (Sentinel files)، توسعهدهندگان میتوانند موارد زیر را رصد کنند:
- اقدامات تخریبی: حذفها، بازنویسیها و عملیات بازگشتی بدون محدودیت.
- کاوش در سیستم: پیمایش دایرکتوریهای والد (Parent-directory traversal) و نوشتنهای مکرر در یک مقصد.
- دسترسیهای غیرمجاز: ایجاد پردازشهای جدید و تلاش برای برقراری اتصالات شبکهای.
تستهای کاناری (Canary testing) دقیقاً به این دلیل مفید هستند که این فایلها یکبار مصرف هستند.
زنجیره ابزارهای پیشنهادی
یک استک امنیتی مؤثر، پارسرهای Python ast یا پارسرهای متناسب با زبان را با Bandit، Semgrep و پلاگینهای امنیتی ESLint ترکیب میکند. این مجموعه باید با اسکن اسرار (secret scanning)، بررسی منشأ وابستگیها، بازرسی یونیکد و اکتشافاتی (heuristics) برای شناسایی محتوای کدگذاری شده gzip, hex یا base64 تقویت شود. دادههای کدگذاری شده باید به مسیر بازرسی هدایت شوند، نه مستقیماً به مسیر اجرا.
سازمانها باید قوانین خاصی برای سازنده Function در جاوااسکریپت، importهای پویا، نامهای API ساخته شده با رشته، مقصدهای شبکهای تأییدنشده و نوشتن در دایرکتوریهای سیستمی مانند /etc داشته باشند. اینها سیاستهای بازبینی هستند، نه لزوماً دلیلی بر قصد مخرب.
هر تصمیمی — از خروجی اولیه و خروجی تغییریافته گرفته تا diffها، مشاهدات محیط ایزوله و تصمیمات نهایی — باید در یک ردپای حسابرسی (Audit trail) تغییرناپذیر ذخیره شود. مرز بنیادی روشن است: خروجی مدل، مجوز اجرای خودش نیست. پارس کردن، بازبینی، ایزولهسازی، کمترین امتیاز (least privilege) و تستهای خصمانه مداوم باید در اطراف این مرز قرار گیرند. حذف کاراکترهای مشکوک یک خانهتکانی مفید است، اما محدود کردن آنچه برنامه در نهایت میتواند لمس کند، تنها کنترل امنیتی واقعی است.
گام بعدی شما
- تمام کدهای تولیدشده توسط AI را در محیطهای ایزوله (Sandbox) تست کنید و هرگز دسترسی Root ندهید.
- یک لیست سیاه از دستورات خطرناک (مانند
rm -rfیاos.system) برای فیلتر کردن خروجیهای مدل تعریف کنید. - از ابزارهای تحلیل استاتیک کد مانند Semgrep برای شناسایی الگوهای ناایمن در کدهای تولیدشده استفاده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو