تصور کنید هر بار که Claude Code یک فایل .env را می‌خواند، یک حفره امنیتی ایجاد می‌شود: کلیدهای خصوصی API شما عملاً از محیط امن دستگاهتان خارج می‌شوند. این عامل در گشت‌وگذار میان پروژه‌ها — از جمله باز کردن فایل‌ها، دنبال کردن Importها و خواندن پیکربندی‌ها برای درک نحوه اتصال اجزا به یکدیگر — فوق‌العاده است، اما اغلب فایل‌های استانداردِ «نادیده انگاشتن» (ignore files) را نادیده می‌گیرد.
این ریسک امنیتی در ژانویه ۲۰۲۶ به‌طور جدی مطرح شد؛ طبق گزارشی از The Register، این ابزار حتی با وجود ثبت نام فایل .env در .claudeignore باز هم آن را خوانده است. این موضوع یادآور گزارشات امنیتی پیشین درباره افشای کلیدهای API در تاریخچه چت‌های دستیاران کدنویسی است که خطرات مشابهی را در ابزارهای مختلف برجسته کرده بود. همان‌طور که در تحلیل قبلی ما درباره‌ی موازنهٔ قابلیت‌های Claude Code در برابر Codex اشاره کردیم، این آسیب‌پذیری شکافی حیاتی در نحوهٔ برخورد ابزارهای عامل‌محور (Agentic) با اسرار محیطی (Environment Secrets) را نشان می‌دهد.
زمینه: استراتژی دفاع سه‌لایه
برای رفع این مشکل، توسعه‌دهندگان می‌توانند یک استراتژی دفاعی سه‌لایه را پیاده کنند که از سریع‌ترین روش تنظیمات شروع شده و به قوی‌ترین سطح محافظت ختم می‌شود. این رویکرد تضمین می‌کند که اگر یک لایه دور زده شد، لایه‌های دیگر برای جلوگیری از خروج داده‌ها (Data Exfiltration) در جای خود باقی بمانند.
لایه اول: قوانین منع خواندن (Read Deny Rules)
نخستین لایه، استفاده از «قوانین منع خواندن» در فایل .claude/settings.json است، به جای استفاده از .claudeignore که مستندات رسمی خودِ ابزار اعتراف می‌کند در بسیاری از موارد ناکارآمد است. شما می‌توانید این تنظیمات را در پوشه پروژه یا در مسیر ~/.claude/settings.json اعمال کنید تا تمام پروژه‌های موجود در دستگاه شما را پوشش دهد.
از پیکربندی زیر استفاده کنید:{ "permissions": { "deny": [ "Read(.env)", "Read(.env.*)", "Read(./secrets/**)" ] } }
پس از اعمال، با اجرای دستور /status در محیط Claude Code، بارگذاری صحیح فایل تنظیمات را تأیید کنید. با این حال، دو محدودیت جدی برای این روش وجود دارد:
- پوشش ابزاری: این قوانین فقط روی ابزارهای داخلی فایل و دستورات شناخته‌شده‌ای مثل
catوheadاثر دارند. - ریسک‌های دور زدن: این قوانین دستوراتی را که فایل‌ها را بدون نام بردن مستقیم می‌خوانند (مانند
grep -r pattern .) یا اسکریپت‌های سفارشی پایتون و نود-جی‌اس که مستقیماً فایل را باز می‌کنند، شناسایی نمی‌کنند.
لایه دوم: ماسک کردن اسرار از طریق MCP
برای دفاعی قوی‌تر در لایه دوم، توسعه‌دهندگان می‌توانند از DevProjex استفاده کنند؛ یک سرور پروتکل زمینهٔ مدل (MCP) رایگان و متن‌باز (تحت لایسنس Apache-2.0). DevProjex مانند یک پروکسی «فقط-خواندنی» عمل می‌کند که اسرار را به‌صورت لحظه‌ای ماسک (Redact) می‌کند. در حالت MCP، این قابلیت ماسک کردن هیچ کلید خاموشی ندارد؛ یعنی هیچ پرچم سرور یا پارامتر ابزاری برای غیرفعال کردن آن وجود ندارد.
DevProjex از ۲۲۱ قانون استخراج‌شده از Gitleaks و قوانین تکمیلی برای رشته‌های اتصال (Connection Strings)، URLهای مربوط به اعتبارنامه‌ها و فایل‌های .env استفاده می‌کند. این رویکرد اکتشافی (Heuristic) ریسک را به‌طور قابل‌توجهی کاهش می‌دهد. وقتی Claude Code از طریق DevProjex درخواستی برای فایل .env می‌فرستد، نام متغیرها (مانند STRIPE_SECRET_KEY یا DATABASE_URL) را می‌بیند، اما مقادیر واقعی آن‌ها با نشانگرهایی مثل DEVPROJEX_REDACTED[environment-secret#1] جایگزین می‌شوند.
این قابلیت به عامل اجازه می‌دهد تا کدهای صحیح را با استفاده از نام متغیرها و میزبان‌های دیتابیس درست بنویسد، بدون اینکه هرگز مقدار واقعی اعتبارنامه را ببیند. علاوه‌بر این، محتوای فایل‌ها در تگ‌های <untrusted-data> قرار می‌گیرند تا تضمین شود متنی که در یک مخزن کاشته شده است، به‌عنوان «داده» خوانده شود و نه به‌عنوان «دستور» برای مدل.
لایه سوم: محدودسازی سخت‌گیرانه (Strict Scoping)
لایه سوم بر این اصل استوار است که دقیقاً تصمیم بگیرید عامل مجاز است به چه چیزهایی نگاه کند. DevProjex کار خود را از همان زاویه‌ای شروع می‌کند که Git پروژه شما را می‌بیند: قوانین .gitignore اعمال می‌شوند، خروجی‌های Build فیلتر می‌شوند و دسترسی فقط به پوشه‌ای محدود می‌شود که با پرچم --root معرفی شده است.
- قفل ریشه (Root Locking): عامل می‌تواند دید خود را محدودتر کند، اما هرگز نمی‌تواند دید خود را فراتر از ریشهٔ تعیین‌شده گسترش دهد.
- زمینه زنده (Live Context): در اپلیکیشن دسکتاپ DevProjex، کاربران می‌توانند فایل‌های خاصی را که می‌خواهند عامل روی آن‌ها کار کند، تیک بزنند. این فیلترها به‌عنوان یک محدودیت سخت برای فراخوانی بعدی عامل عمل می‌کنند.
این رویکرد لایه‌بندی شده، مدل امنیتی را از «اعتماد به عامل» به «کنترل خط لولهٔ داده» تغییر می‌دهد. قوانین منع دسترسی نمی‌توانند مقادیر داخل فایل‌های مجاز را ماسک کنند و DevProjex فقط خروجی‌هایی را که خودش برمی‌گرداند محافظت می‌کند و روی سایر ابزارهای Claude اثر ندارد؛ بنابراین ترکیب این سه لایه، نقاط کور یکدیگر را می‌پوشاند.
در نهایت، این ابزارها جایگزین بهداشت امنیتی پایه نمی‌شوند. شما همچنان باید کلیدهای محیط تولید (Production) را از کپی‌های محلی دور نگه دارید و هر کلیدی را که به‌طور تصادفی در یک گفتگوی چت ظاهر شد، سریعاً تغییر (Rotate) دهید.
برای شروع (که نیازمند Node.js ۲۰ یا بالاتر است)، سرور ماسک‌کننده را با یک دستور متصل کنید: claude mcp add devprojex -- npx -y devprojex mcp --root /absolute/path/to/project. سپس دستور /mcp را برای بررسی اتصال اجرا کنید و از عامل بخواهید نمایش دهد که اپلیکیشن چگونه پیکربندی خود را از طریق DevProjex می‌خواند.
منتظر به‌روزرسانی‌های بعدی باشید تا ببینیم چگونه سرورهای MCP ممکن است ماسک کردن اسرار را در سایر عوامل کدنویسی مانند Codex استاندارد کنند تا یک لایه امنیتی جهانی برای توسعه مبتنی بر هوش مصنوعی ایجاد شود.
گفتگو