۱۶٪ از پیکربندی‌های عامل‌های کدنویس دارای نقص امنیتی هستند

امنیت عامل کدنویس شما دقیقاً به اندازه‌ی لایه‌ی پیکربندی آن است. طبق مطالعه‌ای که در سپتامبر ۲۰۲۶ در arXiv منتشر شد، ۱۶٪ از استقرار‌های عامل (Agent) حداقل یک نقص امنیتی دارند که توسعه‌دهندگان را در برابر حملات زنجیره‌ی تأمین قرار می‌دهد.

در حالی که مدل‌هایی مثل Claude Code، Cursor، GitHub Copilot و OpenAI Codex تحت نظارت شدید هستند، لایه‌ی «هارنس» (Harness) — شامل فایل‌های دستورالعمل، مهارت‌ها و اعلان‌های سرور پروتکل زمینهٔ مدل (MCP) — تا حد زیادی رها شده است. این لایه با تمام امتیازات توسعه‌دهنده اجرا می‌شود و در جلسات مختلف باقی می‌ماند، اما برخلاف وابستگی‌های نرم‌افزاری سنتی، از حفاظ‌های استاندارد بهره نمی‌برد. در این راستا، تعریف دقیق مهارت‌ها برای جلوگیری از رفتارهای پیش‌بینی‌نشده حیاتی است، مشابه آنچه در راهنمای تبدیل پرامپت‌های تکراری به گردش‌کارهای بازرسی‌پذیر بررسی کردیم.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جابه‌جایی مرزهای اعتماد در سیستم‌های خودکار، نقاط کور جدیدی ایجاد می‌کند. پژوهشگران در این مطالعه ۳,۱۷۱ مخزن عمومی گیت‌هاب (GitHub) را تحلیل کردند که شامل ۲,۶۶۰ استقرار چندجزئی و ۵۱۱ مجموعه‌ی مهارت بود.

بر اساس گزارش arXiv، سه کلاس ریسک تأییدشده شناسایی شده است:

• وابستگی‌های تثبیت‌نشده: ۹.۸٪ از استقرارها یک سرور MCP را بدون نسخه‌ی ثابت نصب می‌کنند.
• پنهان‌سازی مجوزها: ۳.۱٪ اجرای دستورات دلخواه را از طریق مجوزهایی که محدود به نظر می‌رسند (مانند Bash(python:*)) پیش‌تأیید می‌کنند.
• امتیاز بیش از حد شل: ۳.۸٪ مهارت‌هایی را بارگذاری می‌کنند که دسترسی فوری به شل را برای هر کاربری که آن‌ها را نصب کند، فراهم می‌کند.

در مجموع، ۱۶.۷٪ از استقرار‌های تحلیل‌شده دارای حداقل یک نقص امنیتی تأییدشده بودند. پژوهشگران بر یک شکاف بحرانی تأکید دارند: برخلاف کتابخانه‌های استاندارد، هارنسِ عامل هیچ فایل قفل (lockfile)، تأییدیه در زمان نصب و واژگان استانداردی برای تعریف مجوزهای هر جزء ندارد. این فقدان ساختار، در مقایسه با گذار به سامانه‌های پیش‌بین در اتوماسیون SaaS، ریسک‌های عملیاتی را در محیط‌های توسعه افزایش می‌دهد.

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

توسعه‌دهندگان باید اکنون با پیکربندی‌های عامل همان‌قدر سخت‌گیرانه برخورد کنند که با کدهای محیط عملیاتی (Production) برخورد می‌کنند. این یعنی تثبیت تمام نسخه‌ها، بازرسی دقیق دامنهٔ مجوزهای سرورهای MCP و پرهیز از پیش‌تأییدهای گسترده‌ای که در پوشش مجوزهای محدود ارائه می‌شوند.

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

گام بعدی شما

• تمام نسخه‌های سرورهای MCP مورد استفاده در محیط توسعه خود را Pin کنید.
• مجوزهای اعطا شده به عامل‌ها را بازبینی کرده و دسترسی‌های Bash گسترده را حذف کنید.
• از ابزارهای تحلیل ایستا برای بررسی فایل‌های پیکربندی عامل‌ها پیش از استقرار استفاده کنید.

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