یک متغیر اشتباه در مسیر فایل، تمام آن چیزی بود که برای یک فاجعه لازم بود. این نتیجه‌ی تلخ گزارش وب‌سایت dev.to است که توضیح می‌دهد چگونه یک عامل کدنویس متعلق به مَت شومر- در ۱۲ ژوئیه ۲۰۲۶، به‌طور تصادفی دستور rm -rf /Users/mattsdevbox را اجرا کرد. با وجود اینکه این عامل صدها بار پیش از آن با موفقیت و ایمن اجرا شده بود، یک خطای واحد در یک متغیر، یک عامل تولیدی را به یک فاجعه‌ی سیستمی تبدیل کرد و باعث پاک شدن روزها کد، فایل‌ها و عکس‌ها شد.
برای یک عامل (Agent) — چیزی شبیه به کارمندی دیجیتال که می‌تواند به‌جای شما ابزارها را اجرا کند — این اتفاق صرفاً یک تیتر خبری نیست، بلکه بازتابی از اضطراب عملیاتی روزمره است. هر بار که یک عامل دستور rm -rf یا git push --force تایپ می‌کند، یک پرسش خاموش وجود دارد: اگر مسیر اشتباه باشد چه می‌شود؟ اگر یک متغیر مقداردهی نشده (uninitialized) باشد چه اتفاقی می‌افتد؟ اگر دستور chmod -R 777 کل سیستم را برای همه قابل نوشتن (world-writable) کند، چه رخ می‌دهد؟ این‌ها ترس‌های خیالی نیستند؛ بلکه عملیات‌های به‌حق‌اند که در بستر درست مفید و در بستر غلط، مرگبارند.
بسیاری از برنامه‌نویسان برای حفظ بهره‌وری، دسترسی گسترده‌ای به شل (Shell) می‌دهند، اما این کار یک وضعیت ریسک دائمی ایجاد می‌کند. شکاف موجود، فاصله بین سیستم‌های دسترسی سخت‌گیرانه است که اغلب مانع کارهای اکتشافی مشروع می‌شوند و گزارش‌های بازرسی (Audit Logs) که فقط بعد از وقوع آسیب به شما می‌گویند چه چیزی خراب شده است. تصور کنید خلبانی باشد که به‌جای یک سیستم هشدار فعال، صرفاً به گزارش‌های پس از سقوط (مانند گزارشات NTSB) تکیه کند؛ این دقیقاً وضعیت فعلی ایمنی عامل‌ها است. حادثه‌ی مَت شومر ثابت کرد که «صدها بار تست شدن»، با «ایمن بودن» یکی نیست.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، نیاز به لایه‌های حفاظتی در زمان اجرا (Runtime) حیاتی است. در همین راستا، بررسی حافظه‌های حفاظتی برای جلوگیری از تخریب مخازن کد نشان می‌دهد که مدیریت دسترسی‌های خودکار نیازمند استراتژی‌های چندلایه است. برای پر کردن این شکاف، ابزار destructive_command_guard به‌عنوان یک لایه ایمنی در زمان اجرا معرفی شده است. این ابزار یک فایل اجرایی نوشته شده با زبان Rust است که دقیقاً بین عامل هوش مصنوعی و شل قرار می‌گیرد. به‌جای استفاده از لیست‌های ساده‌ی مجاز (Allowlist)، این ابزار جریان دستورات را برای یافتن الگوهای خاص تخریبی رصد می‌کند تا به‌عنوان یک مدارشکن (Circuit Breaker) برای دستورات خطرناک عمل کند.
سازوکار حفاظتی
طبق مستندات این پروژه، ابزار مذکور مانند یک مدارشکن برنامه‌ریزی‌شده عمل می‌کند. وقتی عاملی سعی می‌کند دستوری را اجرا کند، این guard آن را با کتابخانه‌ای از الگوهای خطرناک تطبیق می‌دهد. اگر تطابقی پیدا شود، ابزار اجرا را مسدود کرده و یک خطای ساختاریافته (Structured Error) به عامل برمی‌گرداند تا دستور هرگز به شل نرسد و اجرا نشود.
نکته کلیدی این است که چون عامل به‌جای مواجهه با یک ترمینال کراش کرده، یک پاسخ خطای ساختاریافته دریافت می‌کند، می‌تواند بفهمد چه اتفاقی افتاده است، رویداد را ثبت کند، رفتار خود را اصلاح کند یا موضوع را برای تأیید نهایی به یک انسان ارجاع دهد.
دسته‌بندی‌های اصلی دستورات مسدود شده عبارت‌اند از:
- تخریب شل: هدف قرار دادن عملیاتی مانند
rm -rf /،rm -rf ~،rm -rf .وrm -rf ... - فجایع گیت: عملیات‌های پرریسک مثل
git push --force،git push origin +mainیاgit reset --hard HEAD~1. - نابودی پایگاه‌داده: دستوراتی نظیر
DROP TABLE،DROP DATABASEیاDELETE FROM users. - خراب‌کاری سیستمی: تغییرات خطرناک در مجوزها مانند
chmod -R 777 /، نوشتن‌های سطح پایین روی دیسک مانندdd if=/dev/zero of=/dev/sdaیا اجرای بمب‌های فورک (Fork Bombs) مانند:(){ :|:& };:. - کابوس‌های زیرساختی: دستوراتی مثل
kubectl delete ns defaultیاterraform destroy.
مهندسی برای قابلیت اطمینان
انتخاب زبان Rust برای ساخت این ابزار یک سیگنال طراحی آگاهانه است. از آن‌جا که این ابزار مسئول ایمنی است، نباید خودش منبع آسیب‌پذیری باشد. ابزار ایمنی‌ای که کراش کند، باگ‌های حافظه داشته باشد یا وابستگی‌های پیچیده ایجاد کند، در واقع یک تناقض است. تضمین‌های ایمنی حافظه در Rust باعث می‌شود احتمال اینکه خودِ guard منبع یک آسیب‌پذیری باشد، به حداقل برسد.
معماری بدون وابستگی (Zero-dependency) این ابزار نیز به همان اندازه حیاتی است. در اکوسیستم عامل‌ها، هر npm install یا pip install صدها وابستگی غیرمستقیم (Transitive Dependencies) اضافه می‌کند که هر کدام یک مسیر احتمالی برای حمله هستند. destructive_command_guard با اجتناب از این‌ها، سطح حمله زنجیره تأمین (Supply-chain attack surface) را از بین می‌برد. این ابزار به یک باینری استاتیک واحد تبدیل می‌شود: دانلود کنید، اجازه اجرا بدهید و پیکربندی کنید.
عملکرد نیز عامل تعیین‌کننده‌ای است. برای اینکه تجربه برنامه‌نویس کند نشود، این ابزار از سرعت کامپایل‌شده‌ی Rust برای تطبیق الگوهای regex با تأخیر (Latency) ناچیز استفاده می‌کند. این یعنی بررسی ایمنی سریع‌تر از آن چیزی است که شل بتواند دستور را اجرا کند، و در نتیجه توان عملیاتی (Throughput) عامل کاهش نمی‌یابد.
نحوه «تفکر» گارد
بر اساس بررسی ساختار مخزن (Repository) این پروژه، ابزار از یک منطق تطبیق لایه‌ای برای کاهش مثبت‌های کاذب و شناسایی ریسک‌های پیچیده استفاده می‌کند:
- تطابق دقیق: ابتدا دستورات خطرناک شناخته‌شده را با نام دقیق شناسایی می‌کند.
- الگوهای Regex: از قابلیت‌های regex در Rust برای شناسایی گونه‌های مختلف، مانند مسیرهایی که شامل کاراکترهای جایگزین (Wildcards) یا فلگ‌های خاص Force هستند، استفاده می‌کند. برای مثال، دستور
rm -rf /var/logبه همان اندازهrm -rf ~شناسایی و مسدود می‌شود. - هیورستیک‌های حساس به متن: ابزار راه‌اندازی شده دایرکتوری کاری (Working Directory)، مسیر هدف و آرگومان‌ها را به‌طور هم‌زمان تحلیل می‌کند.
این رویکرد لایه‌ای اجازه می‌دهد تهدیدات ظریف شناسایی شوند. مثلاً دستور git push --force origin main نه فقط به دلیل یک کلمه کلیدی، بلکه به دلیل ترکیب فلگ --force، یک شاخه ریموت و نام شاخه‌ای که شبیه به محیط تولید (Production) است، آستانه ایمنی را رد کرده و مسدود می‌شود.
این متد روی مدل تهدید «دستور تخریبی تصادفی» تمرکز دارد؛ مانند یک غلط تایپی، یا متغیری محیطی که مقداردهی نشده و به‌جای /tmp/build123 به / گسترش می‌یابد، یا اشتباه در دایرکتوری کاری فعلی. هدف این نیست که جلوی کاربر مصمیمی را که می‌تواند دستورات را کدگذاری (Encode) کند یا از اجرای غیرمستقیم استفاده کند بگیرند، بلکه هدف جلوگیری از خطاهای رایجی است که منجر به از دست رفتن داده‌ها می‌شود.
چرخش در زیرساخت‌های عامل‌محور
این ابزار بخشی از یک روند بزرگتر در اکوسیستم است. destructive_command_guard به‌تازگی با رسیدن به ۲۸۰۵ ستاره در گیت‌هاب (با میانگین ۴۴۴ ستاره در روز)، نشان داد که جامعه توسعه‌دهندگان شکاف بحرانی در زیرساخت عامل‌ها را به‌طور جمعی پذیرفته‌اند.
این رشد شبیه به ابزارهای ایمنی دیگری مثل DesktopCommanderMCP (با ۷۹۶۸ ستاره) است که بر دسترسی کنترل‌شده به ترمینال تمرکز دارد و همچنین ابزارهای نوظهور سندباکسینگ (Sandboxing) برای ایزوله‌سازی اجرا.
ما در حال ظهور رشته «امنیت عامل‌ها» (Agent Security) هستیم که مشابه مدل OSI عمل می‌کند: انتقال از امنیت شبکه به امنیت اپلیکیشن و اکنون به امنیت عامل. سه ماه پیش، ایمنی یعنی این بود که رمز عبور دیتابیس تولید را به عامل ندهید. امروز، ایمنی شامل گارد‌های ساختاریافته برای دستورات، تشخیص نشت داده‌ها (Data Exfiltration)، سرورهای MCP با کنترل دسترسی و اجرای سیاست‌های زمان اجرا (Runtime Policy Enforcement) است. این تکامل امنیتی به‌ویژه زمانی اهمیت می‌یابد که بدانیم اسکریپت‌های غیرفعال در مخازن کد می‌توانند به سطوح حمله جدیدی برای عامل‌ها تبدیل شوند و ریسک‌های پیش‌بینی نشده‌ای ایجاد کنند.
پیاده‌سازی عملی و محدودیت‌ها
برای کسانی که از Claude Code، Codex، Cursor یا تنظیمات سفارشی (مانند Hermes) استفاده می‌کنند، دفاع لایه‌ای به‌جای تکیه به یک راهکار واحد توصیه می‌شود:
- نصب گارد: قرار دادن
destructive_command_guardدر مسیر PATH عامل به عنوان اولین خط دفاع. - حسابرسی بک‌اندها: بررسی تنظیمات آپلود داده‌ها. همان‌طور که در داستان Grok CLI دیدیم، عامل‌های کدنویس ممکن است داده‌های بسیار بیشتری را ارسال کنند تا آنچه در رابط کاربری گفتگو (UI) دیده می‌شود.
- تمرینات آتش‌نشانی: به عامل دستوری بدهید که قاعدتاً باید مسدود شود تا از دریافت پیام «COMMAND BLOCKED: destructive pattern detected» مطمئن شوید.
- حفظ لایه‌ها: لیست‌های مجاز (Allowlists)، گزارش‌های بازرسی و نظارت انسانی (Human-in-the-loop) را حفظ کنید. گارد موارد استثنایی — مثل یک غلط تایپی یا متغیر گسترش‌یافته — را می‌گیرد که از فیلترهای دسترسی استاتیک رد می‌شوند.
با این حال، این ابزار همه چیز را حل نمی‌کند. این ابزار جلوی نوشتن‌های تخریبی را می‌گیرد اما نمی‌تواند مانع خواندن فایل‌های حساس .env یا کلیدهای SSH توسط عامل و نشت آن‌ها در یک پرامپت شود. کاربران همچنان باید دسترسی‌های سطح فایل را مدیریت کنند تا از افشای داده‌ها در چارچوب مدل تهدید گسترده‌تر خود جلوگیری کنند.
در نهایت، حالت‌های شکست عامل‌های هوش مصنوعی دقیقاً مشابه برنامه‌نویسان انسانی است: یک نگاهِ از دست‌رفته به مسیر فایل یا یک خطای کپی-پیست. تنها تفاوت در مقیاس و سرعت اجراست. انسان شاید یک بار مسیر را چک کند، اما یک هوش مصنوعی در هر جلسه صدها دستور اجرا می‌کند. حفاظ‌های خودکار تنها راه حفظ ایمنی در سرعت‌های عملیاتی مورد نیاز عامل‌ها هستند. پرسش دیگر این نیست که آیا عامل شما اشتباه خواهد کرد یا خیر، بلکه این است که آیا لایه‌های حفاظتی شما وقتی این اتفاق افتاد، آن را شکار می‌کنند یا خیر. اگرچه گاردها از اجرای دستورات خطرناک جلوگیری می‌کنند، اما برای تحلیل دقیق‌تر ریشه‌ی این خطاها، ابزارهایی مانند Causari با ثبت زنجیره علیّت به توسعه‌دهندگان کمک می‌کنند تا بفهمند چرا یک عامل به مسیر تخریبی هدایت شده است.
گام بعدی شما
- اگر از عامل‌های کدنویس با دسترسی شل استفاده می‌کنید، این ابزار را در مسیر PATH سیستم خود جای‌گذاری کنید.
- دستورات پرریسکِ خاصِ محیط توسعه خود را به لیست الگوهای regex ابزار اضافه کنید.
- یک محیط ایزوله (Sandbox) ایجاد کرده و با دستورات تخریبی، عملکرد گارد را تست کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و تاثیر آن‌ها بر سرعت استنتاج مراجعه کنید.
گفتگو