تصور کنید یک عامل هوش مصنوعی را برای بهروزرسانی مستندات پروژه به کار میگیرید، اما او تصمیم میگیرد برای «بهینهسازی»، فایلهای حساس تنظیمات CI/CD شما را تغییر دهد. هنگامی که در زمان واقعی با یک عامل هوش مصنوعی تعامل دارید، اصلیترین safeguard یا حفاظ در برابر تغییرات ناخواسته در فایلها، نظارت انسانی است. اگر به عامل بگویید «به هیچ چیزی خارج از دایرکتوری src دست نزن»، شما خودتان مکانیزم اجرایی هستید؛ یعنی انحراف را متوجه میشوید و مداخله میکنید. اما وقتی یک عامل بهصورت بدون نظارت (Unattended) اجرا میشود — مانند یک خط لوله CI/CD زمانبندی شده یا یک وظیفه اتوماسیون در پسزمینه — نظارت انسانی وجود ندارد. در این سناریوها، اجرا باید برنامهریزیشده و مطلق باشد.
Claude Code — ابزاری که برای تعامل مستقیم با کدها طراحی شده — دو مکانیزم برای کنترل دسترسی به فایلها ارائه میدهد. این ابزار در واقع قابلیتهای ویرایش مستقیم فایلها را به محیط ترمینال آورد تا سرعت توسعه را افزایش دهد. اما طبق بررسی مستندات فنی، این دو ابزار با هم متفاوتاند و بسیاری از توسعهدهندگان متوجه شدهاند که این سیستمها نمیتوانند مدل امنیتی «لیست سفید» (Allow-list) را که برای محیطهای عملیاتی ضروری است، پیاده کنند.
اولین مکانیزم، سیستم مجوزهای اعلامی (Declarative Permission System) است که در فایل settings.json یافت میشود. این سیستم از یک لیست «رد» (Deny) برای مسدود کردن مسیرهای خاص استفاده میکند. برای مثال، یک توسعهدهنده ممکن است مشخص کند که عامل نمیتواند فایلهای .env را بخواند یا در دایرکتوری .github بنویسد. این قوانین از تطبیق مسیر به سبک gitignore استفاده میکنند؛ به طوری که دو اسلش در ابتدا نشاندهنده یک مسیر مطلق و علامت تیلدا (~) نشاندهنده دایرکتوری خانگی (Home Directory) است.
منطق حاکم بر این قوانین بر اساس یک سلسلهمراتب سختگیرانه است: دستور «رد» (Deny) بر «پرسش» (Ask) اولویت دارد و «پرسش» بر «اجازه» (Allow) برتری دارد. علاوه بر این، این قوانین در دامنههای مختلف با هم ادغام میشوند. اگر یک تنظیم در سطح پروژه دسترسی به پوشهای را رد کند، یک تنظیم جهانی (Global) شخصی نمیتواند آن محدودیت را برای اعطای دسترسی بازنویسی کند. در حالی که این اولویتبندی باعث میشود قوانین «رد» مستحکم باشند و بهطور تصادفی لغو نشوند، اما یک مشکل معماری بنیادی برای کسانی ایجاد میکند که به دنبال یک محیط محدودکننده هستند.
مشکل اصلی اینجاست که اکثر توسعهدهندگانی که میخواهند یک عامل بدون نظارت را ایمن کنند، به دنبال یک لیست سفید هستند؛ یعنی پیکربندیای که بگوید «عامل فقط اجازه دارد در این پوشههای خاص بنویسد و هیچ جای دیگر نه». اما سیستم مجوزهای Claude Code اساساً به عنوان یک لیست سیاه (Block-list) ساخته شده است. شما نمیتوانید منطقاً یک لیست سفید را با استفاده از یک لیست سیاه بسازید، در حالی که قانون «رد» همیشه اولویت دارد. تلاش شهودی برای حل این مشکل — یعنی مسدود کردن تمام نوشتنها از طریق Write(**) و سپس افزودن قوانین اجازه برای پوشههای خاص — شکست میخورد؛ زیرا قانون رد جهانی، بر هر قانون اجازه بعدی برتری دارد. نتیجه این است که عامل کاملاً فلج میشود و قادر نیست هیچ فایلی را بنویسد.
تنها مرز لیست سفید در این ابزار، ریشه پروژه (Project Root) و هر مسیری است که در additionalDirectories ذکر شده باشد. این قابلیت برای جلوگیری از سرگردانی عامل در دایرکتوریهای سیستمی مانند /etc یا /var موثر است، اما برای اکثر نیازهای سطح پروژه بسیار کلی و خام است. خطر واقعی به ندرت این است که یک عامل زمانبندی شده بخواهد فایل hosts سیستم را ویرایش کند؛ خطر واقعی این است که عاملی که وظیفه نوشتن مستندات یا بهروزرسانی کد منبع را دارد، تصمیم بگیرد پروژه را با تغییر اسکریپتهای ساخت (Build Scripts)، تغییر پیکربندی CI یا تغییر فایل package.json «بهینه» کند. از آنجایی که ریشه پروژه، خط پایه لیست سفید است، عامل بر روی هر فایلی در آن ریشه تسلط کامل دارد، مگر اینکه بهطور خاص توسط یک قانون رد مسدود شده باشد.
برای حل این مشکل، توسعهدهندگان باید از تنظیمات داخلی settings.json فراتر رفته و یک Wrapper یا پوشش ساختاری پیاده کنند. از آنجا که عامل از طریق فراخوانی ابزار (Tool Use) — شبیه به یک دستیار که برای هر کار باید از جعبهابزار خاصی استفاده کند — با سیستم فایل تعامل دارد، موثرترین راه برای اعمال یک مرز دایرکتوری سختگیرانه، رهگیری (Intercept) این فراخوانیهاست. با قرار دادن محیط اجرای عامل در یک شل محدود شده یا استفاده از یک پروکسی سیستم فایل، میتوانید اطمینان حاصل کنید که هرگونه تلاش برای نوشتن در مسیری خارج از «منطقه امن» تعیین شده، پیش از آنکه هرگز به دیسک برسد، رد شود. این کار، اجرا را از یک تنظیم اعلامی (که ممکن است عامل سعی در دور زدن آن داشته باشد یا بیش از حد سهلگیرانه باشد) به یک محدودیت عملیاتی (Operational Constraint) تغییر میدهد. این رویکرد برای مقابله با آسیبپذیریهایی است که پیشتر در قالب چهار حفره امنیتی خطرناک توسط آنتروپیک شناسایی و مسدود شدند تا از نفوذ به فایلهای سیستمی جلوگیری شود.
در پیادهسازی این روش، منطق باید از یک رویکرد «رد پیشفرض» (Default-deny) پیروی کند. به جای فهرست کردن آنچه ممنوع است، Wrapper باید لیستی از دایرکتوریهای تایید شده را نگه دارد. هنگامی که عامل یک دستور نوشتن صادر میکند، Wrapper مسیر هدف را تجزیه (Parse) کرده، تمام لینکهای نمادین (Symbolic Links) را Resolve میکند تا از حملات پیمایش دایرکتوری (Directory Traversal) — مانند استفاده از ../../ برای فرار از ریشه — جلوگیری شود و بررسی میکند که آیا مسیر Resolve شده با یکی از پیشوندهای دایرکتوری تایید شده شروع میشود یا خیر. اگر اینطور نباشد، فراخوانی ابزار رهگیری شده و یک پیام خطا به عامل بازگردانده میشود که بیان میکند دایرکتوری Read-only است. این کار یک حلقه بازخورد ایجاد میکند که در آن عامل مرزهای محیط خود را از طریق آزمون و خطا یاد میگیرد، به جای اینکه به یک دستور مبتنی بر پرامپت تکیه کند که ممکن است در طول یک زنجیره استدلال پیچیده نادیده گرفته شود.
تفاوت میان مجوزهای اعلامی و محدودیتهای عملیاتی برای استقرار عاملهای خودمختار حیاتی است. مجوزهای اعلامی برای راحتی توسعهدهنده (Developer Ergonomics) عالی هستند — مثلاً برای جلوگیری از اینکه یک انسان بهطور تصادفی اجازه دهد عامل یک فایل پیکربندی را حذف کند. اما محدودیتهای عملیاتی برای امنیت و پایداری هستند. با treating کردن عامل به عنوان یک فرآیند غیرقابل اعتماد و محصور کردن دسترسی آن به سیستم فایل در یک پروکسی لیست سفید سختگیرانه، توسعهدهندگان میتوانند در نهایت به الزام «به هیچ چیز خارج از src/ دست نزن» برای عاملهای بدون نظارت دست یابند. برای کسانی که میخواهند امنیت محیط خود را به حداکثر برسانند، بررسی ۱۰ تنظیم حیاتی برای جلوگیری از دور زدن حفاظهای امنیتی میتواند مکمل این راهکار عملیاتی باشد. این رویکرد تضمین میکند که حتی اگر منطق داخلی عامل شکست بخورد یا سعی کند از اهداف خود فراتر رود، مرزهای فیزیکی سیستم فایل دستنخورده باقی میمانند و یکپارچگی پیکربندی و زیرساخت پروژه محافظت میشود.
در پیادهسازی این روش، منطق باید از یک رویکرد «رد پیشفرض» (Default-deny) پیروی کند. به جای فهرست کردن آنچه ممنوع است، Wrapper باید لیستی از دایرکتوریهای تایید شده را نگه دارد. هنگامی که عامل یک دستور نوشتن صادر میکند، Wrapper مسیر هدف را تجزیه (Parse) کرده، تمام لینکهای نمادین (Symbolic Links) را Resolve میکند تا از حملات پیمایش دایرکتوری (Directory Traversal) — مانند استفاده از ../../ برای فرار از ریشه — جلوگیری شود و بررسی میکند که آیا مسیر Resolve شده با یکی از پیشوندهای دایرکتوری تایید شده شروع میشود یا خیر. اگر اینطور نباشد، فراخوانی ابزار رهگیری شده و یک پیام خطا به عامل بازگردانده میشود که بیان میکند دایرکتوری Read-only است. این کار یک حلقه بازخورد ایجاد میکند که در آن عامل مرزهای محیط خود را از طریق آزمون و خطا یاد میگیرد، به جای اینکه به یک دستور مبتنی بر پرامپت تکیه کند که ممکن است در طول یک زنجیره استدلال پیچیده نادیده گرفته شود.
تفاوت میان مجوزهای اعلامی و محدودیتهای عملیاتی برای استقرار عاملهای خودمختار حیاتی است. مجوزهای اعلامی برای راحتی توسعهدهنده (Developer Ergonomics) عالی هستند — مثلاً برای جلوگیری از اینکه یک انسان بهطور تصادفی اجازه دهد عامل یک فایل پیکربندی را حذف کند. اما محدودیتهای عملیاتی برای امنیت و پایداری هستند. با treating کردن عامل به عنوان یک فرآیند غیرقابل اعتماد و محصور کردن دسترسی آن به سیستم فایل در یک پروکسی لیست سفید سختگیرانه، توسعهدهندگان میتوانند در نهایت به الزام «به هیچ چیز خارج از src/ دست نزن» برای عاملهای بدون نظارت دست یابند. این رویکرد تضمین میکند که حتی اگر منطق داخلی عامل شکست بخورد یا سعی کند از اهداف خود فراتر رود، مرزهای فیزیکی سیستم فایل دستنخورده باقی میمانند و یکپارچگی پیکربندی و زیرساخت پروژه محافظت میشود.
گام بعدی شما
- اگر از Claude Code در محیطهای اتوماتیک استفاده میکنید، به جای تکیه بر settings.json، یک محیط ایزوله (Sandbox) یا کانتینر با دسترسی محدود ایجاد کنید.
- برای پیادهسازی Wrapper، از کتابخانههایی استفاده کنید که مسیرهای مطلق را Resolve میکنند تا جلوی دور زدن محدودیتها با لینکهای نمادین گرفته شود.
- دسترسیهای Write را در سطح سیستمعامل برای کاربرِ اجراکنندهٔ عامل، به حداقل ممکن برسانید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو