اجرای یک عامل (Agent) — شبیه به کارمندی که کلید تمام اتاق‌های شرکت را دارد — با دسترسی کامل به سیستم فایل، قمار روی امنیت داده‌های شماست. این دسترسی گسترده معمولاً یا به نشت اطلاعات منجر می‌شود یا حذف تصادفی داده‌های حیاتی. به همین دلیل، شرکت آلی‌بابا در ۲۴ اوت ۲۰۲۶ نسخه 0.22.0 از Qwen Code را منتشر کرد تا وضعیت امنیتی پیش‌فرض را از «دسترسی باز» به مدل «درخواست صریح» (Opt-in) برای ابزارهای حساس تغییر دهد.
در حال حاضر اکثر توسعه‌دهندگان با یک انتخاب سخت و دوتایی روبرو هستند: یا باید هر اقدام کوچک مدل را به صورت دستی تأیید کنند یا از حالت «YOLO» استفاده کنند که استقلال کامل و خطرناکی به عامل می‌دهد. این شکاف باعث ایجاد یک ریسک عملیاتی عظیم می‌شود، به‌ویژه زمانی که عامل‌ها با مخازن (Repositories) غیرقابل اعتماد، عامل‌های سفارشی یا سرورهای سفارشی پروتکل زمینهٔ مدل (MCP) تعامل دارند. این وضعیت در کارهای مربوط به مخازنی که بدون نظارت اجرا می‌شوند (Unattended jobs) بسیار خطرناک است، زیرا تأییدهای مبهم می‌توانند ریسک‌های عملیاتی واقعی ایجاد کنند. این چالش‌ها یادآور آسیب‌پذیری‌های مشابه در مدل‌های دیگر است، مانند حفره‌های امنیتی در Grok که امکان سرقت خاموش داده‌ها را فراهم می‌کرد. به‌روزرسانی جدید Qwen تلاش می‌کند این شکاف را با معرفی یک سیستم تأیید مبتنی بر طبقه‌بندی‌کننده (Classifier) پر کند.
بازنگری در سطح ابزارها
مهم‌ترین تغییر در نسخه 0.22.0، تغییر وضعیت ابزار list_directory است. این ابزار اکنون به صورت پیش‌فرض غیرفعال شده است. بر اساس یادداشت‌های انتشار، ابزار glob اکنون اکثر نیازهای فهرست‌بندی دایرکتوری را پوشش می‌دهد و به Qwen اجازه می‌دهد تا سطح پرامپت و انتخاب ابزار را بدون از دست دادن قابلیت‌ها کاهش دهد.
برای بازگرداندن list_directory، توسعه‌دهندگان اکنون باید صراحتاً گزینه tools.listDirectory.enabled را فعال کنند یا آن را در لیست ثبت coreTools بگنجانند. این تغییر تضمین می‌کند که مدل حتی نمی‌تواند ابزار را ببیند مگر اینکه توسعه‌دهنده عمداً آن را اعطا کند. این اقدام باعث می‌شود یک ابزار داخلی به صورت پیش‌فرض ایمن‌تر شود و یک حالت تأیید از طریق SDKها راحت‌تر در دسترس باشد.
ماتریس دسترسی سه‌لایه
برای جلوگیری از «خزش مجوزها» (Permission Creep)، Qwen اکنون یک رویکرد امنیتی در سه لایه پیشنهاد می‌کند. این تمایز بسیار حیاتی است زیرا مستندات پایدار SDK تایپ‌اسکریپت، coreTools را به عنوان یک لیست سفید ثبت (Registration allowlist) توصیف می‌کند، در حالی که allowedTools و permissions.allow تأییدیه را برای فراخوانی‌های منطبق دور می‌زنند.
- کنترل ثبت (Registration Control): تعیین می‌کند که آیا مدل می‌تواند ابزار را ببیند یا خیر. این لایه از طریق
coreTools،tools.listDirectory.enabled، ابزارهای غیرفعال و ثبت افزونه‌ها یا MCP مدیریت می‌شود. شواهد این لایه از طریق کپچر/toolsو لیست‌های نام ابزارهای خروجی جمع‌آوری می‌شود. - تأیید فراخوانی (Invocation Approval): تعیین می‌کند که آیا یک فراخوانی بدون پرسش اجرا شود یا خیر. این بخش توسط حالت Approval،
permissions.allow،permissions.ask،permissions.denyو کال‌بک‌های SDK مدیریت می‌شود. شواهد شامل نام ابزار، آرگومان‌های سانسور شده، قانون تطبیق یافته و منبع تصمیم‌گیری است. - محدودیت زمان اجرا (Runtime Containment): تعیین می‌کند که فراخوانی در کجا اجرا شود. این لایه شامل سندباکس (Sandbox) — محیطی ایزوله شبیه به یک آزمایشگاه شیشه‌ای که هر اتفاقی در آن بیفتد به دنیای بیرون سرایت نمی‌کند — مرز فضای کاری (Workspace boundary)، هویت پردازش و سیاست‌های سیستم فایل/شبکه است. شواهد از طریق پروب‌های خواندن/نوشتن یک‌بار مصرف و بررسی اقدامات مسدود شده در محیط‌های همسایه تأیید می‌شود.
تیم Qwen هشدار می‌دهد که هرگز نباید از شواهد یک ردیف برای تأیید ردیف دیگر استفاده کرد. یک ابزار مخفی ممکن است همچنان از طریق MCP قابل دسترسی باشد و یک فراخوانی با تأیید خودکار همچنان می‌تواند توسط محیط اجرای میزبان (Host runtime) به شکلی خطرناک و بدون محدودیت رها شود.
مکانیزم تأیید خودکار (Auto)
برای نخستین بار، SDKهای پایتون و جاوا اکنون از حالت تأیید auto پشتیبانی می‌کنند که با CLI و SDK تایپ‌اسکریپت مطابقت دارد. برخلاف رویکرد قطعی «لیست سفید»، حالت auto از یک طبقه‌بندی‌کننده (Classifier) مبتنی بر LLM استفاده می‌کند تا هر فراخوانی ابزار را در لحظه ارزیابی کند.
اگر طبقه‌بندی‌کننده تشخیص دهد که یک اقدام ایمن است، آن را به طور خودکار تأیید می‌کند؛ اگر اقدام ریسکی باشد، آن را مسدود می‌کند. این حالت، نقطه‌ای میانی بین خستگیِ تأیید دستی و خطرِ استقلال کامل است. با این حال، auto یک سیاست «حداقل دسترسی» (Least-privilege) نیست. این یک طبقه‌بندی‌کننده انتخابی است، نه یک لیست سفید قطعی، و نباید به عنوان یک «حالت امن» برای اقدامات با تأثیر بالا در نظر گرفته شود.
گردش‌کار استقرار و اعتبارسنجی
Qwen یک مسیر شش‌مرحله‌ای برای اطمینان از کارکرد واقعی این حفاظ‌ها توصیه می‌کند:
۱. تثبیت فایل اجرایی دقیق: دستور /about را اجرا کرده و نسخه Qwen Code، محیط اجرا، مدل/ارائه‌دهنده، حالت تأیید و وضعیت سندباکس را ثبت کنید. این راهنما با تگ پایدار v0.22.0 و کامیت 1c3a385d9bc83e0b2a1ce5a24454ce1d090595fb بررسی شده است. برای ادعای رفتار پایدار، از نسخه‌های Nightly استفاده نکنید.
۲. شروع با یک هسته ثبت‌شده کوچک: از یک مخزن یک‌بار مصرف و تأیید پیش‌فرض استفاده کنید. یک جلسه کاناری می‌تواند با دستور qwen --approval-mode default --core-tools read_file,grep_search,glob شروع شود. تأیید کنید که /tools ابزارهای list_directory، ویرایش یا اجرای شل را نشان نمی‌دهد. اگر گردش‌کار به ابزار قدیمی نیاز دارد، آن را صراحتاً فعال کنید؛ آن را فقط برای ساکت کردن یک پرامپت بازنگردانید.
۳. بررسی طرح خروجی (Outbound Schema)، نه فقط رابط کاربری: یک گزارش عمومی (issue #9827) علیه نسخه 0.22.0 نشان می‌دهد در برخی تنظیمات، /tools محدود به نظر می‌رسید، اما بک‌اند سازگار با OpenAI همچنان آرایه کامل ابزارهای داخلی را دریافت می‌کرد. نام ابزارهای خروجی را از طریق یک پروکسی ضبط‌کننده یا لاگ دیباگ ارائه‌دهنده کپچر کنید. آرگومان‌ها، پرامپت‌ها و اعتبارنامه‌ها را سانسور کنید. اگر رابط کاربری و موجودی خروجی با هم اختلاف دارند، در حالت تعاملی (Interactive) بمانید.
۴. تست مجزای تأیید: مجموعه ابزارهای ثبت‌شده را ثابت نگه دارید. حالت default را با auto با استفاده از فراخوانی‌های بی‌ضرر مقایسه کنید. درخواست نوشتن در یک فایل یک‌بار مصرف را بدهید و ثبت کنید که آیا مدل می‌پرسد، تأیید می‌شود یا مسدود می‌گردد. یک اقدام همسایه خارج از محدوده را درخواست کنید و یک منع صریح (Explicit deny) اضافه کنید تا ثابت شود همچنان مسدود است. اطمینان حاصل کنید که رکورد حسابرسی عبارت decision_source=classifier را نشان می‌دهد.
۵. اجرای هفت تست کاناری:
* تأیید کنید list_directory به طور پیش‌فرض غایب است.
* تأیید کنید که Opt-in صریح، آن را پس از ری‌استارت بازمی‌گرداند.
* اطمینان حاصل کنید ابزارهای حذف شده از coreTools در دسترس نیستند.
* تأیید کنید موجودی نام ابزارهای خروجی با سطح ثبت‌شده مطابقت دارد.
* تأیید کنید حالت default برای نوشتن‌های یک‌بار مصرف پرامپت می‌فرستد.
* تأیید کنید auto تصمیمات طبقه‌بندی‌کننده را ثبت می‌کند بدون اینکه به حالت «YOLO» تبدیل شود.
* تأیید کنید اقدامات همسایه مسدود شده در هر دو حالت مسدود می‌مانند.
۶. ارتقای دسترسی بر اساس کلاس اقدام: با اکتشاف فقط-خواندنی در مخزن شروع کنید. ویرایش‌های محدود را تنها پس از بررسی صحت بازگشت (Rollback) و بررسی Diff اضافه کنید. دستورات شل، نوشتن‌های شبکه، انتشار، صورت‌حساب، استقرار، اسرار (Secrets) و اقدامات تخریبی سیستم فایل را در حالت تأیید صریح انسانی نگه دارید.
سندباکس و مهار عملیاتی
اگرچه گردش‌کار Autofix اکنون تصاویر سندباکس را برای یکپارچگی بهتر به اثر انگشت (Digest) آن‌ها متصل می‌کند، اما Qwen هشدار می‌دهد که این موضوع لزوماً ایزولاسیون کامل را برای تمام سندباکس‌های ساخته شده توسط کاربر تضمین نمی‌کند. سندباکس پیامدهای یک اشتباه را کاهش می‌دهد، اما یک طبقه‌بندی‌کننده را به یک مقام امن برای خرج کردن پول، انتشار محتوا یا تخریب وضعیت (State) تبدیل نمی‌کند.
این تمایز حیاتی است زیرا بسیاری از توسعه‌دهندگان permissions.allow را به عنوان تضمینی می‌بینند که طرح‌های (Schemas) لیست‌نشده هرگز به مدل ارسال نشده‌اند. در واقع، سطح ثبت (Registration surface) و سطح تأیید (Approval surface) لایه‌های جداگانه‌ای هستند که باید به طور مستقل حسابرسی شوند.
برای تیم‌هایی که از MCP، Skills یا عامل‌های سفارشی استفاده می‌کنند، این‌ها جدا از coreTools داخلی در نظر گرفته می‌شوند. تست‌های مدیریت مجوز پایدار Qwen نشان می‌دهد که این‌ها سطوح متمایزی هستند. این بدان معناست که کاهش مجموعه ابزارهای هسته، لزوماً کل جلسه را امن نمی‌کند اگر پلاگین‌های خارجی فعال باشند. هنگامی که یک فراخوانی مجاز می‌تواند وضعیت خارجی را تغییر دهد، از چک‌لیست safe-replay مربوط به MCP استفاده کنید.
خلاصه اشتباهات رایج
برای اجتناب از ریسک عملیاتی، از این اشتباهات رایج دوری کنید:
- تلقی کردن
permissions.allowبه عنوان مدرکی بر اینکه طرح‌های لیست‌نشده هرگز ارسال نشده‌اند. - فرض اینکه
coreToolsشامل MCP، Skills و هر ابزار سنتتیک می‌شود. - فعال کردن
list_directoryفقط به این دلیل که یک پرامپت قدیمی نام آن را می‌برد، بدون بررسی اینکه آیاglobکافی است یا خیر. - تست کردن با اعتبارنامه‌های واقعی، مخازن تولید (Production) یا دستورات تخریبی.
- ثبت تنها نتیجه نهایی ابزار در حالی که نسخه، قانون تطبیق یافته و منبع تصمیم را از دست می‌دهید.
این تغییر در معماری Qwen Code، صنعت را از مجوزهای «همه یا هیچ» در عامل‌ها دور می‌کند. با مجبور کردن توسعه‌دهندگان به بازرسی واقعی سطح ابزارهای خروجی، Qwen با استفاده از ابزار توسط هوش مصنوعی به عنوان یک امتیاز (Privilege) برخورد می‌کند که باید مدیریت شود، نه صرفاً ویژگی‌ای که باید فعال گردد.
گام بعدی شما
- اگر از عامل‌های کدنویس استفاده می‌کنید، فوراً حالت
--yoloرا غیرفعال و ازapproval-mode defaultاستفاده کنید. - ابزارهای فعال در
coreToolsرا بازبینی کرده و هر ابزاری که باglobجایگزین می‌شود را حذف کنید. - برای محیط‌های حساس، یک پروکسی ثبت‌کننده (Recording Proxy) قرار دهید تا ببینید مدل واقعاً چه ابزارهایی را فراخوانی می‌کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو