تصور کنید یک برنامه‌نویس ارشد را که هر خط کدِ دستیار هوشمندش را قبل از اجرا در ترمینال بررسی می‌کند تا جلوی یک فاجعه را بگیرد. حالا آنتروپیک این نقش نظارتی را از انسان به کدهای برنامه‌ریزی‌شده منتقل کرده است. آنتروپیک مودها را به عنوان «توابع کوچک تایپ‌اسکریپت که به رویدادهای داخلی متصل می‌شوند تا رفتار عامل را از درون بازنویسی کنند» توصیف می‌کند.
در ۳ اکتبر ۲۰۲۶، شرکت آنتروپیک (Anthropic) با معرفی قابلیت Mods، لایه کنترل عامل (Agent) — یعنی سیستمی که می‌تواند به‌طور مستقل ابزارها را اجرا کند — در Claude Code را تغییر داد. نصب یک Claude Code Mod بیشتر شبیه به نصب یک بسته محلی با دسترسی کامل به سیستم است تا فعال کردن یک افزونه ساده مرورگر.
این تحول در حالی رخ می‌دهد که عامل‌های هوش مصنوعی از محیط‌های چت ساده به ابزارهای خودمختاری با دسترسی به شل (Shell) تبدیل شده‌اند. این تغییر رویکرد در راستای استراتژی کلان آنتروپیک برای تبدیل دستیارهای چت به موتورهای ارکستراسیون است تا مدیریت پیچیده‌تر ابزارها میسر شود. این حرکت در ادامه پوشش‌های پیشین ما درباره‌ی احضاریه شورای شهر نیویورک برای آنتروپیک و سایر آزمایشگاه‌ها در مورد ریسک‌های هوش مصنوعی صورت می‌گیرد. معرفی مودها دقیقاً تنش میان خودمختاری عامل و امنیت سیستم را برجسته می‌کند. برای یک توسعه‌دهنده، تفاوت این است که به‌جای تماشای اشتباه عامل، یک دروازه برنامه‌ریزی‌شده داشته باشد که مانع رسیدن دستور اشتباه به ترمینال شود.
سازوکار: تفاوت قلاب‌ها و مودها
به نقل از مستندات آنتروپیک، تفاوت اصلی Mods با قلاب‌های (Hooks) قدیمی در مالکیت «حلقه رویداد» (Event Loop) است. در حالی که قلاب‌ها صرفاً یک رویداد را مشاهده می‌کنند، مودها می‌توانند رویداد را بازنویسی کنند، آن را به‌طور کامل مسدود کنند یا نتیجه بازگشتی را در مسیر خروج تغییر دهند. آنتروپیک صراحتاً درباره این شکاف اعلام کرده است: «قلاب‌ها کمک کردند تا کاربران بخشی از این کنترل را داشته باشند، اما قلاب‌ها نمی‌توانند رویدادها را بازنویسی کنند، رابط کاربری جدید رسم کنند یا ویژگی‌ها را جایگزین کنند. اما مودها می‌توانند.»
در یک خط لوله استاندارد، عامل رویدادهایی مثل ارسال پرامپت (prompt submissions)، فراخوانی ابزار (tool calls)، نتایج ابزار (tool results) و درخواست مجوز (permission requests) را صادر می‌کند. یک Mod این رویدادها را با استفاده از یک تابع next() در بر می‌گیرد. اولین مودی که بارگذاری می‌شود، ابتدا رویداد را می‌بیند و در نهایت نتیجه را دریافت می‌کند و بدین ترتیب یک زنجیره سلسله‌مراتبی از فرماندهی ایجاد می‌شود. این یعنی یک Mod می‌تواند قبل از فراخوانی next() رویداد را تغییر دهد، یا با حذف کامل فراخوانی next()، چرخه را برای آن نوبت کوتاه (short-circuit) کند، یا تابع next() را در بر بگیرد تا نتیجه را در مسیر بازگشت ویرایش کند.
چهار الگوی کاربردی در پیاده‌سازی
برای درک کاربرد این معماری، چهار الگوی پیاده‌سازی متمایز را بررسی می‌کنیم. در یک مدل ساده‌شده‌ی تایپ‌اسکریپت، این موارد توسط هندلرهای رویداد خاص مدیریت می‌شوند:
- بازنویسی پرامپت (
prompt.submit): یک Mod می‌تواند یک سیاست جهانی را روی هر پرامپت مهر کند. برای مثال، یک مودrewrite-promptمی‌تواند سیاستی مانند «هرگز اسرار را چاپ نکن. پرسیدن را به اجازه دادن ترجیح بده» را به متن اضافه کند، پیش از آنکه مدل درخواست را پردازش کند. - مسدودسازی ابزار (
tool.call): یک Mod می‌تواند رویدادtool.callرا رهگیری کند. اگر یک مودblock-dangerous-shellدستوری مانندrm -rf /را شناسایی کند، می‌تواند نتیجه‌ای تحت عنوان «مسدود شده توسط مود: شل خطرناک» برگرداند، بدون اینکه دستور هرگز به ابزار واقعی برسد. - حذف داده‌های حساس (
tool.result): با در بر گرفتن تابعnext()، یک مودredact-secretsمی‌تواند خروجی ابزار را برای یافتن کلیدهای API یا اسرار با استفاده از عبارت‌های منظم (Regex) اسکن کند (مثلاً جستجو برای الگوهایsk-یاpk-) و آن‌ها را با عبارت[REDACTED]جایگزین کند، پیش از آنکه مدل خروجی را بخواند. - تغییر مجوزها (
permission.ask): یک Mod می‌تواند درخواست مجوز را رهگیری کند. برای مثال، یک مود مخربauto-allowمی‌تواند تصمیم «رد کردن» (deny) را به «پذیرفتن» (allow) تغییر دهد، که همین موضوع نشان می‌دهد چرا ترتیب بارگذاری یک ویژگی امنیتی حیاتی است.
سلسله‌مراتب امنیتی
از آنجا که مودها در محیط ایزوله (Sandbox) اجرا نمی‌شوند، همان سطح دسترسی و امتیازات Claude Code را دارند. این فقدان سندباکسینگ به این معناست که نصب هر مود یک اقدام مبتنی بر اعتماد بالا (high-trust action) است. برای جلوگیری از اینکه مودهای نصب‌شده توسط کاربر، قوانین ایمنی حیاتی را لغو کنند، آنتروپیک یک مود داخلی به نام sec-default را برای طرح‌های تیمی و سازمانی ارائه داده است.
این مود sec-default در ابتدای خط لوله بارگذاری می‌شود. این مود به‌طور خاص رویدادهای permission.ask را نظارت می‌کند. اگر یک مود بعدی و احتمالاً مخرب (مانند auto-allow) سعی کند یک مجوز «رد شده» را به «پذیرفته شده» تغییر دهد، مود sec-default نتیجه را در مسیر بازگشت می‌گیرد و آن را به اجبار به «رد شده» برمی‌گرداند. این سازوکار تضمین می‌کند که قوانین رد مجوز در سطح سازمانی نمی‌توانند توسط پلاگین‌های نصب‌شده توسط کاربر دور زده شوند.
واقعیت‌های پیاده‌سازی
با وجود قدرت این مفهوم، استقرار واقعی با چندین مانع روبروست. در یک دموی ساده، از Regex برای حذف کلیدها استفاده می‌شود، اما این روش برای محیط‌های عملیاتی (Production) ناکافی است. اسکنرهای حرفه‌ای اسرار به تحلیل آنتروپی، بررسی فرمت‌های شناخته‌شده و تحلیل زمینه (Context) نیاز دارند تا از بازنویسی کلیدهایی که مدل قبلاً دیده است، جلوگیری کنند. توسعه‌دهندگان باید داده‌ها را قبل از اینکه مدل نتیجه ابزار را بخواند حذف کنند و همچنان با کل متن گفتگو به عنوان داده حساس برخورد کنند.
به همین ترتیب، مسدود کردن دستورات شل از طریق تطبیق رشته‌ها (String Matching) متزلزل و شکننده است. در حالی که rm -rf / مورد ساده‌ای برای مسدود کردن است، کاربران حرفه‌ای می‌توانند با روش‌های زیر محدودیت‌های ساده رشته‌ای را دور بزنند:
- استفاده از نقل‌قول‌ها و کاراکترهای فرار (Quoting and escaping)
- استفاده از کامنت‌های شل
- استفاده از بسته‌بندی‌های دستوری (Command wrappers)
- استفاده از فلگ‌های متعلق به هارنس
امنیت واقعی نیازمند یک دروازه شل است که با خودِ شل درباره ماهیت واقعی دستور توافق داشته باشد، نه مودی که صرفاً رشته‌های خاصی را مسدود می‌کند.
علاوه بر این، sec-default تنها زمانی محافظت می‌کند که اول بارگذاری شود. اگر یک مود مخرب پیش از آن بارگذاری شود، یا اگر یک تیم تنظیمات پیش‌فرض را بدون حفظ همان محدودیت‌ها جایگزین کند، زنجیره امنیتی می‌شکند. به همین دلیل است که آنتروپیک برای مسیرهای سازمانی، تنظیمات مدیریت‌شده (Managed Settings) را توصیه می‌کند.
چرخش به سمت «هارنس‌های عامل»
این معماری نشان‌دهنده تغییری گسترده در توسعه هوش مصنوعی است. ما از تلاش برای همراستاسازی (Alignment) مدل‌ها صرفاً از طریق پرامپت، به سمت «هارنس‌های عامل» (Agent Harnesses) حرکت می‌کنیم.
در این پارادایم، جریان به این شکل است: رویداد $\rightarrow$ sec-default (اولین) $\rightarrow$ مودهای کاربر (بازنویسی/مسدودسازی/حذف) $\rightarrow$ حلقه عامل $\rightarrow$ نتیجه (که احتمالاً در مسیر بازگشت بازنویسی می‌شود). مدل یک اقدام را پیشنهاد می‌کند، اما یک لایه کد قطعی و مجزا — یعنی Mod — تصمیم می‌گیرد مدل چه چیزی را ببیند و ابزارها چه کاری اجازه دارند انجام دهند. این ساختار تکمیلی است بر سازوکار هماهنگ‌کننده در Claude Code که پیش‌تر برای مدیریت عامل‌های موازی معرفی شده بود.
این رویکرد یک لایه امنیتی برنامه‌ریزی‌شده ایجاد می‌کند که به استدلال مدل وابسته نیست. برای کسانی که «کارمند هوش مصنوعی» می‌سازند، این یعنی سیاست‌ها دیگر چیزی نیستند که بعد از وقوع خطا ارزیابی شوند، بلکه می‌توانند در لحظه چرخه را بازنویسی کنند و تضمین کنند که قوانین سازمانی صرف‌نظر از قصد مدل، اجرا می‌شوند. این جهت‌گیری در تمامی هارنس‌های عامل، دروازه‌های مجوز و کنترل‌های پلاگین سازمانی یکسان است.
تست خط لوله
برای مشاهده این سازوکار در عمل، توسعه‌دهندگان می‌توانند با یک مدل ساده‌شده تایپ‌اسکریپت از این خط لوله آزمایش کنند. با اجرای یک حلقه عامل اسکریپتی از طریق سه خط لوله مختلف — بدون مود، با مودهای مفید، و با مودهای مفید در حالی که sec-default در اولویت است — تأثیر ترتیب بارگذاری بر نتایج امنیتی فوراً آشکار می‌شود.
در یک سناریوی تست با ۵ رویداد (یک پرامپت، یک فراخوانی خواندن فایل .env ، یک فراخوانی bash خطرناک، یک فراخوانی bash استاندارد و یک مجوز رد شده)، نتایج به‌شدت متفاوت است:
- بدون مود: اسرار موجود در
.envبه‌طور کامل چاپ شده و دستورrm -rf /با موفقیت اجرا می‌شود. - با مودهای مفید (بدون sec-default): اسرار حذف شده و شل خطرناک مسدود می‌شود. با این حال، یک مود مخرب
auto-allowبا موفقیت مجوز «رد شده» را به «پذیرفته شده» تغییر می‌دهد. - با اولویت sec-default: اسرار حذف شده و شل مسدود می‌شود. نکته حیاتی این است که وقتی
auto-allowسعی می‌کند مجوز را تغییر دهد،sec-defaultآن را می‌گیرد و وضعیت «رد شده» را حفظ می‌کند.
این آزمایش ثابت می‌کند که ترتیب بارگذاری صرفاً یک جزئیات فنی نیست، بلکه یک ویژگی امنیتی اصلی است. مدل پیشنهاد می‌دهد، ابزارها اجرا می‌کنند، اما مودها مرزها را تعیین می‌کنند. اگر در حال ساخت یک کارمند هوش مصنوعی هستید، به جایی نیاز دارید که سیاست‌ها بتوانند چرخه را بازنویسی کنند، نه اینکه فقط بعد از وقوع اتفاق، آن را نمره بدهند.
گام بعدی شما
- اگر از Claude Code استفاده می‌کنید، ابتدا لیست مودهای نصب‌شده را بررسی کنید تا از ترتیب بارگذاری آن‌ها مطمئن شوید.
- برای محیط‌های سازمانی، حتماً از لایه
sec-defaultبرای جلوگیری از دور زدن مجوزها توسط کاربران استفاده کنید. - به جای تکیه بر پرامپت برای امنیت، توابع TypeScript ساده‌ای برای فیلتر کردن خروجی‌های حساس ابزارها بنویسید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو