سد agentgateway در برابر نشت فایل‌های حساس در پروتکل MCP

تصور کنید یک برنامه‌نویس برای افزایش بهره‌وری، دسترسی یک عامل هوش مصنوعی به پوشه پروژه خود را باز می‌کند، اما ناگهان متوجه می‌شود مدل تمام رمزهای عبور دیتابیس را خوانده است. این دقیقاً همان نقطه‌ضعفی است که در پیاده‌سازی‌های فعلی پروتکل زمینه مدل (MCP) وجود دارد. یک سرور MCP سیستم فایل که محدود به یک دایرکتوری خاص است، همچنان به عامل هوش مصنوعی اجازه می‌دهد تا اگر صراحتاً مسیر یک فایل .env را درخواست کند، آن را بخواند.

بسیاری از توسعه‌دهندگان تصور می‌کنند محدود کردن عامل به یک دایرکتوری خاص (Scoping) امنیت را تأمین می‌کند، اما این روش جلوی خروج عامل از محیط ایزوله (Sandbox) را می‌گیرد، نه دسترسی به اسرار زندگی در داخل آن محیط. فایل‌هایی مثل .env ،.ssh/id_rsa و .git/config همگی در همان دایرکتوری قرار دارند که قرار است عامل در آن فعالیت کند و به راحتی قابل خواندن‌اند.

به گزارش منابع فنی در ۱۶ اکتبر ۲۰۲۶، یک بررسی عمیق فنی فاش کرد که سیاست‌های احراز هویت استاندارد اغلب در اینجا شکست می‌خورند؛ زیرا این سیاست‌ها نام ابزار را ارزیابی می‌کنند، نه آرگومان‌های ورودی آن را. این شکاف امنیتی ابتدا در ۵ اکتبر ۲۰۲۶ توسط یکی از کاربران در r/mcp در پستی با عنوان «Claude تقریباً فایل .env محیط عملیاتی من را بلعید» افشا شد. نویسنده آن پست در نهایت مجبور شد یک حفاظ (Guardrail) شخصی با زبان Rust بنویسد، زیرا نتوانست راهکاری در سطح بالادستی (Upstream) پیدا کند.

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد مطلق به محدوده‌های دسترسی (Sandbox) بدون نظارت بر محتوا، ریسک نشت داده را به‌شدت بالا می‌برد. این چالش‌ها در حالی رخ می‌دهد که پروتکل MCP به دلیل استانداردسازی اتصال مدل‌ها به داده‌ها به سرعت در حال گسترش است و اکنون به درگاه استاندارد اتصال مدل‌های AI تبدیل شده است.

شکست احراز هویت استاندارد

برای حل این مشکل، شرکت Solo.io ابزاری به نام agentgateway و یک حفاظ همراه به نام filesystem-mcp-env-guard را توسعه داد. در ابتدا، هدف این بود که از سیاست داخلی mcpAuthorization در agentgateway استفاده شود. این سیاست از قوانین CEL (Common Expression Language) استفاده می‌کند که بر اساس mcp.tool.name ،mcp.tool.target و ادعاهای JWT مانند jwt.sub ارزیابی می‌شوند.

در حالی که لیست‌های مجاز (Allowlists) برای نام ابزارها کار می‌کنند — برای مثال، قوانینی که فقط اجازه اجرای echo یا get-sum را می‌دهند — اما برای امنیت مبتنی بر مسیر (Path-based security) ناکافی هستند. فیلد mcp.tool.arguments در جدول متغیرهای CEL وجود دارد، اما به عنوان «پس از درخواست» (post-request) علامت‌گذاری شده است. این بدان معناست که این فیلد برای لاگ‌های دسترسی، پس از آنکه فراخوانی اجرا شد، پر می‌شود. از آنجایی که قوانین mcpAuthorization قبل از فراخوانی ارزیابی می‌شوند، آرگومان مسیر هنوز برای مسدود کردن در دسترس نیست. تست روی نسخه v1.5.0 باینری agentgateway تأیید کرد که فراخوانی‌های read_text_file صرف‌نظر از مسیر ارائه شده، به طور یکسان ارزیابی می‌شوند.

حفاظ در سطح درخواست (Request-Level Guardrail)

راهکار نهایی، انتقال نقطه کنترل به ExtMCP بود؛ یک سرویس gRPC خارجی. Agentgateway این سرویس را از طریق رابط ext_mcp.proto فراخوانی می‌کند که شامل دو RPC است: CheckRequest و CheckResponse. این سرویس می‌تواند درخواست را عبور دهد، نسخه‌ای تغییر یافته از آن را برگرداند یا آن را با یک خطا رد کند.

پیاده‌سازی این مورد نیازمند یک بلوک سیاست mcpGuardrails در تنظیمات است. برای مثال، تنظیم methods: tools/call: full تضمین می‌کند که هر دو قلاب برای سرور سیستم فایل اجرا شوند. اولین خط دفاعی، قلاب CheckRequest است. این مکانیزم پارامترهای JSON-RPC را تحلیل می‌کند تا ابزارهای حامل مسیر را شناسایی کند، از جمله:

• read_text_file و read_file
• read_media_file و get_file_info
• read_multiple_files (که به جای یک رشته واحد، آرایه‌ای از مسیرها را مدیریت می‌کند)

اگر هر رشته مسیر با یک لیست سیاه (Denylist) مطابقت داشته باشد — شامل .env ،.ssh ،.git/ ،credentials ،id_rsa ،id_ed25519 ،.aws/ ،.npmrc یا .netrc — گیت‌وی یک خطای AuthorizationError برمی‌گرداند. در تستی با استفاده از MCP inspector، درخواستی برای مسیر /sandbox/.env پیامی برگرداند که بیان می‌کرد مسیر با یک الگوی ممنوعه مطابقت دارد و توسط filesystem-mcp-env-guard مسدود شده است. بدون این سیاست، همان فراخوانی باعث نشت مستقیم DATABASE_URL و API_KEY به عامل می‌شد. این نوع آسیب‌پذیری‌ها یادآور نقص امنیتی در SDK پایتون MCP است که پیش‌تر امکان دسترسی غیرمجاز به اعتبارنامه‌های OAuth را فراهم می‌کرد.

پشتیبان در سطح پاسخ (Response-Level Backstop)

لیست‌های سیاه مسیر نمی‌توانند هر نشت داده‌ای را شناس کنند. ممکن است یک راز به‌طور تصادفی در یک فایل بی‌خطر مانند app.log چسبانده شده باشد، که در لیست سیاه مسیرها نیست. برای مقابله با این مورد، agentgateway از قلاب CheckResponse استفاده می‌کند که متن بازگشتی را برای یافتن زیررشته‌های «شبیه به راز» اسکن می‌کند.

این لایه دوم به دنبال الگوهایی مانند موارد زیر می‌گردد:

• کلیدهای API و رشته‌های password=
• رشته‌های اتصال به Postgres
• بلوک‌های کلید خصوصی PEM
• شناسه‌های کلید دسترسی AWS

اگر تطابقی پیدا شود، گیت‌وی محتوای حساس را قبل از خروج از گیت‌وی سانسور کرده و آن را با [REDACTED] جایگزین می‌کند. برای مثال، خواندن فایل app.log که حاوی عبارت «connecting with API_KEY=sk-demo...» است، پیش از آنکه عامل آن را ببیند به «connecting with API_KEY=[REDACTED]» تبدیل می‌شود. این امر تضمین می‌کند که حتی اگر قلاب درخواست توسط یک نام فایل بی‌خطر دور زده شود، خود داده‌ها محافظت شوند.

هزینه امنیت: منطق شکست بسته (Fail-Closed)

پیاده‌سازی این حفاظ‌ها یک وابستگی حیاتی در دسترس بودن ایجاد می‌کند. سیستم از سیاست failureMode: failClosed استفاده می‌کند؛ به این معنی که اگر سرور سیاست‌ها در دسترس نباشد، agentgateway به جای اجازه دادن به فراخوانی‌های بررسی نشده، تمام فراخوانی‌های تحت حفاظت را به‌طور پیش‌فرض رد می‌کند.

در حالی که این امر تضمین می‌کند که سقوط سرور منجر به یک رخنه امنیتی خاموش نشود، اما به این معناست که زمان فعال بودن (Uptime) سرور MCP سیستم فایل اکنون دقیقاً محدود به زمان فعال بودن سرور سیاست‌ها است. در تست‌ها، متوقف کردن سرور سیاست‌ها در میانه دمو منجر به رد حتی فایل‌های بی‌خطری مانند notes.txt شد و خطای «Connection refused (os error 61)» را برگرداند.

انتخاب failOpen این وابستگی را حذف می‌کرد اما در لحظه‌ای که سرور سیاست‌ها دچار مشکل شود، آسیب‌پذیری اولیه را دوباره بازمی‌گرداند. برای مسیرهای حاوی اعتبارنامه‌ها، «شکست بسته» تنها پاسخی است که در شرایط فشار کاری، دوباره به حالت پیش‌فرض ناامن برنمی‌گردد.

پیاده‌سازی و محدودیت‌ها

توسعه‌دهندگان می‌توانند این سیستم را با کلون کردن مخزن themsquared/filesystem-mcp-env-guard و اجرای اسکریپت scripts/demo.sh تست کنند. این دمو هفت بررسی را اجرا می‌کند: یک خواندن ایمن، خواندن ممنوع .env ،خواندن ممنوع .ssh/id_rsa ،یک فراخوانی read_multiple_files با یک مسیر ممنوع، یک بررسی پشتیبان ماسک پاسخ و یک تست رفتار شکست بسته.

باید به محدودیت‌های این رویکرد توجه داشت:

• تطبیق مسیر: لیست سیاه از تطبیق زیررشته (Substring matching) روی رشته مسیر استفاده می‌کند. این یک زبان کامل سیاست‌گذاری مسیر نیست و ممکن است لینک‌های نمادین (Symlinks) ایجاد شده قبل از حفاظ یا دایرکتوری‌هایی با نام‌های هوشمندانه را شناس نکند.
• دامنه DLP: الگوهای ماسک پاسخ، مجموعه‌ای ثابت برای اشکال اعتبارنامه‌های این دمو هستند و یک موتور کلی جلوگیری از نشت داده (DLP) نیستند.

این معماری مدل امنیتی را از «اعتماد به محدوده عامل» به «تأیید قصد عامل و خروجی سرور» تغییر می‌دهد. این مدل می‌پذیرد که در یک محیط عملیاتی، ریسک نشت اعتبارنامه‌ها بسیار بیشتر از ریسک قطعی موقت سرویس است. برای توسعه‌دهندگان، این بدان معناست که صرفاً ایزوله کردن یک دایرکتوری کافی نیست. امنیت واقعی برای استفاده از ابزارهای عاملی نیازمند یک Interceptor است که بتواند هم آرگومان‌های ورودی و هم داده‌های خروجی را ببیند. این رویکرد تکمیلی بر راهکارهای جامع‌تری است که پیش‌تر دیدیم، مانند زمانی که AegisGate با گیت‌وی ۷ لایه خود سعی کرد خلأهای امنیتی گسترده‌تر پروتکل MCP را پر کند.

گام بعدی شما

• اگر از MCP برای اتصال عامل‌ها به سیستم فایل استفاده می‌کنید، حتماً یک لایه Interceptor برای بررسی آرگومان‌ها اضافه کنید.
• فایل‌های حساس را از پوشه‌هایی که عامل به آن‌ها دسترسی دارد خارج کنید و از متغیرهای محیطی سیستمی استفاده کنید.
• برای محیط‌های Production، حتماً سیاست failClosed را فعال کنید تا در صورت خرابی سیستم امنیتی، داده‌ها لو نروند.

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