Kong AI Gateway دسترسی عامل‌های Muse Code به ابزارهای حساس را محدود کرد

تصور کنید یک عامل کدنویس در عرض چند دقیقه علت قطعی سرور را پیدا کند، اما دسترسی او برای رفع مشکل، یک حفره امنیتی عظیم ایجاد کند. اگر به یک عامل هوش مصنوعی اجازه دهید بدون تایید انسانی دستور «بازگشت به نسخه قبلی» (Rollback) را اجرا کند، ریسک تخریب محیط عملیاتی (Production) به شدت بالا می‌رود.

Muse Code — عامل کدنویسی ترمینالی شرکت Meta — اجازه می‌دهد ابزارها به عنوان فرآیندهای فرزند بدون محدودیت اجرا شوند. این یعنی عاملی که به ابزار Rollback دسترسی دارد، می‌تواند بدون هیچ هشدار یا تاییدیه در سمت کاربر، تغییرات گسترده‌ای در سرور ایجاد کند. این یک آسیب‌پذیری بحرانی است: در حالی که کاربران می‌توانند در تنظیمات Muse، گزینه‌های shell_execute و file_write را طوری تنظیم کنند که پیش از اجرا اجازه بخواهند، این تنظیمات هیچ‌گونه تاییدیه یا پرامپتی را در برابر فراخوانی‌های ابزارهای پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) قرار نمی‌دهند. این موضوع یادآور چالش‌های بنیادین در تعریف مرزهای امنیتی جدید در پروتکل MCP است که می‌تواند منجر به ریسک‌های تزریق پرامپت در ابزارهای خارجی شود.

این شکاف در مکانیزم سندباکس (Sandbox) به این معناست که مرز ایمنی هوش مصنوعی باید از سمت کلاینت به سمت درگاه (Gateway) منتقل شود. همان‌طور که در تحلیل قبلی ما درباره‌ی یکپارچه‌سازی ترافیک هوش مصنوعی در Kong AI Gateway 2.0 اشاره کردیم، اکنون یک پیاده‌سازی عملی نشان می‌دهد که چگونه می‌توان کنترل دسترسی مبتنی بر هویت (Identity-based Access Control) را برای عامل‌های MCP اجرا کرد.

معماری مرزهای عامل (Agent Boundaries)

مشکل اصلی این است که ابزارهای استاندارد MCP اغلب بر اساس منطق «همه یا هیچ» عمل می‌کنند. اگر یک عامل دارای یک کلید API باشد، معمولاً به تمام ابزارهای موجود دسترسی دارد. برای حل این مشکل، در این پیاده‌سازی، Kong AI Gateway بین عامل و APIهای عملیاتی REST قرار می‌گیرد.

درگاه (Gateway) چهار وظیفه حیاتی را بر عهده می‌گیرد:

• احراز هویت هویت فراخوان (Caller's Identity).
• تصمیم‌گیری در سطح هر ابزار (Per-tool) درباره اینکه آیا آن هویت مجاز به دسترسی است یا خیر.
• تبدیل فراخوانی‌های مجاز به درخواست‌های HTTP استاندارد برای APIهای REST.
• ثبت یک ورودی حسابرسی (Audit Entry) دقیق برای هر تصمیم اتخاذ شده.

ارزیابی استراتژی‌های ایجاد مرز

پیش از نهایی کردن رویکرد درگاه، سه الگوی معماری مختلف مورد ارزیابی قرار گرفت:

۱. سرور MCP اختصاصی (Bespoke MCP Server): نوشتن سروری که در هر هندلر (Handler)، نقش کاربر را بررسی کند. این روش کار می‌کند، اما به این معناست که هر تصمیم مربوط به مجوزها باید در کد نوشته و تست شود، و لیست ابزارها برای همه فراخوان‌ها، صرف‌نظر از هویتشان، یکسان باقی می‌ماند.
۲. گیتینگ با کلید API (API Key Gating): قرار دادن ابزارها پشت یک کلید API ساده. این یک رویکرد «همه یا هیچ» است که در آن هر کسی کلید را داشته باشد، به تمام ابزارها دسترسی می‌یابد.
۳. Kong AI Gateway 2.0: این گزینه انتخاب شد زیرا APIهای REST موجود را به ابزارهای MCP تبدیل می‌کند و لیست‌های کنترل دسترسی (ACL) را به صورت مجزا برای هر ابزار و هر هویت اعمال می‌کند. نکته حیاتی این است که حتی فراخوانی tools/list (لیست ابزارها) نیز فیلتر می‌شود.

پیاده‌سازی قابلیت مشاهده ابزارها (Per-Tool Visibility)

برخلاف کلیدهای API ساده که فقط درخواست‌های غیرمجاز را رد می‌کنند، این تنظیمات پاسخ tools/list را فیلتر می‌کند. اگر هویتی مجوز دسترسی به یک ابزار خاص را نداشته باشد، عامل اصلاً متوجه نمی‌شود که چنین ابزاری وجود دارد. این امر مانع از آن می‌شود که مدل حتی یک اقدام تخریبی را پیشنهاد دهد. این یک ویژگی متمایز از «رد کردن درخواست» است؛ زیرا قصد انجام عمل را از چرخه تفکر مدل حذف می‌کند. در واقع، مدیریت صحیح پاسخ‌های منفی در سطح سرور، مانع از بداهه‌پردازی (Hallucination) عامل‌ها شده و آن‌ها را مجبور می‌کند در چارچوب ابزارهای موجود عمل کنند.

برای تست این مرز، دو هویت مجزا تعریف شد:

• oncall-investigator: می‌تواند بررسی‌های سلامت، خلاصه‌های خطا و دستورالعمل‌ها (Runbooks) را ببیند. او می‌تواند یک حادثه (Incident) ایجاد کند اما نمی‌تواند محیط عملیاتی را تغییر دهد.
• oncall-operator: تمام ابزارهای محقق را دارد، به اضافه‌ی ابزار rollback-deployment.

ماتریس دسترسی به ابزارها:

توجه داشته باشید که این یک تفکیک ساده بین «خواندن» و «نوشتن» نیست. محقق همچنان می‌تواند با باز کردن یک حادثه، عملیات نوشتن را انجام دهد. تمایز حیاتی در توانایی تغییر وضعیت محیط عملیاتی (Production State) است.

اجرای فنی: تبدیل REST به MCP

API عملیاتی یک سرویس REST استاندارد است که استقرارها، خلاصه‌های خطا، دستورالعمل‌ها و حوادث را پوشش می‌دهد. با استفاده از conversion-listener در Kong، این نقاط انتهایی (Endpoints) بدون نیاز به نوشتن یک سرور MCP سفارشی، به ابزارهای MCP نگاشت می‌شوند.

به عنوان مثال، ابزار get-error-summary با توصیفی خاص پیکربندی شده است: «تعداد خطاها برای یک سرویس در بازه‌های پنج دقیقه‌ای، تفکیک شده بر اساس نوع خطا. از این ابزار برای یافتن زمان دقیق شروع خطا و تشخیص اینکه کدام نوع خطا در حال رشد است (و نه فقط کدام یک بلندتر/بیشتر است) استفاده کنید.»

جزئیات پیکربندی

دو نکته حیاتی در پیکربندی به چشم خورد:

• تفکیک مسیر (Path Resolution): مسیر ابزار باید شامل پیشوند مسیر (Route Prefix) باشد. یک مسیر /ops-mcp در ترکیب با مسیر ابزار /ops-mcp/errors/summary به آدرس http://host:9110/v1/errors/summary ختم می‌شود. حذف پیشوند منجر به خطای 404 می‌گردد.
• کیفیت توصیفات (Description Quality): توصیف ابزار تنها اطلاعاتی است که عامل برای تصمیم‌گیری درباره فراخوانی ابزار استفاده می‌کند. نوشتن این توصیفات به صورت دستورالعمل‌هایی برای یک همکار، کیفیت بررسی‌های عامل را به طور قابل توجهی بهبود بخشید.

تنظیمات هویت و مجوزها

برای اعمال مرزها، سیستم از ai_gateway_auth_strategies برای احراز هویت کلید و ai_gateway_consumers برای تعریف هویت‌ها استفاده می‌کند. هویت oncall-investigator در گروه incident-response و اپراتور در گروه sre-oncall قرار می‌گیرد.

مجوزها از طریق default_tool_acls و جایگزینی‌های (Overrides) هر ابزار مدیریت می‌شوند:

• پایه (Baseline): تنظیمات default_tool_acls به هر دو گروه incident-response و sre-oncall اجازه دسترسی می‌دهد.
• جایگزینی (Override): ابزار rollback-deployment از یک ACL خاص استفاده می‌کند که فقط sre-oncall را لیست کرده است. چون ACL هر ابزار به طور کامل جایگزین ACL پیش‌فرض می‌شود (و با آن ادغام نمی‌شود)، گروه incident-response دسترسی به این ابزار را از دست می‌دهد.
• استقرار: پیکربندی با استفاده از kongctl apply اعمال می‌شود. دستور apply بر sync ترجیح داده شد زیرا sync تمام انواع منابع را تطبیق می‌دهد و ممکن است موجودیت‌هایی را که صراحتاً در فایل نام بر نشده‌اند، حذف کند.

نتایج: بررسی در عمل

در ۲۴ سپتامبر ۲۰۲۶، سیستم در برابر یک API عملیاتی شبیه‌سازی شده تست شد. به عامل محقق این دستور داده شد: «خطاهای پرداخت پس از آخرین استقرار افزایش یافته است. با استفاده از ابزارهای on-call موجود، علت را بررسی کن. شواهد نتیجه‌گیری خود را نشان بده و سپس بگو چه اقدامی باید انجام شود.»

عامل با استفاده از ابزارهای موجود، با موفقیت تشخیص داد که استقرار dep-482 باعث خطای PaymentProviderTimeout به دلیل اتمام ظرفیت استخر اتصالات (Pool Exhaustion) شده است. شواهد عامل شامل موارد زیر بود:

• زمان تخریب: سرویس checkout در ساعت 16:58:46Z دچار افت شد (نرخ خطا ۸.۴٪ در مقابل SLO ۰.۵٪، p99 برابر ۴۱۸۰ میلی‌ثانیه در مقابل خط پایه ۳۱۰ میلی‌ثانیه، نسخه فعال 2026.9.24-3).
• همبستگی با استقرار: استقرار dep-482 در ساعت 16:55:46Z انجام شد، یعنی تقریباً ۳ دقیقه پیش از جهش خطاها. تغییر اعمال شده «استفاده مجدد از اتصالات استخر شده برای کلاینت پرداخت» بود.
• تحلیل خطا: خطای PaymentProviderTimeout از ۰ در هر ۵ دقیقه به ۲۳۵ در هر ۵ دقیقه (در مجموع ۱۵۰۰ مورد) رسید. سایر خطاها مانند CardDeclined (حدود ۵۵-۶۰) و SessionExpired (۱۰ مورد) ثابت ماندند.
• شواهد لاگ: نمونه‌ها نشان دادند که pool_max_size: 8, pool_active: 8, pool_idle: 0 است و یک Stack Trace در PaymentsClient.acquire (payments/pool.js:114) وجود دارد.
• بررسی وابستگی‌ها: عامل تایید کرد که payments-provider-api سالم است (خطا ۰.۱٪ در مقابل SLO ۱.۰٪، p99 برابر ۲۸۸ میلی‌ثانیه در مقابل خط پایه ۲۷۵ میلی‌ثانیه) و بدین ترتیب احتمال مشکل از سمت ارائه‌دهنده را رد کرد.

منطق عامل از دستورالعمل rb-204 پیروی کرد که تصریح می‌کند اگر استقراری در ۱۰ دقیقه قبل از شروع خطاها انجام شده باشد، تایم‌اوت‌ها معمولاً به معنای اشباع استخر اتصالات هستند. عامل در متن پاسخ خود پیشنهاد Rollback داد، اما هرگز سعی نکرد این فراخوانی را انجام دهد زیرا ابزار rollback-deployment برای هویت او نامرئی بود.

اثبات مرز امنیتی

وقتی همان دستور به هویت «اپراتور» داده شد، عامل با موفقیت عملیات بازگشت از dep-482 به dep-481 (نسخه 2026.9.24-2) را انجام داد و سلامت سرویس را بازیابی کرد.

برای اثبات اینکه این رفتار صرفاً یک «همکاری» از سوی مدل نیست، یک اسکریپت تاییدیه برای دور زدن مدل و فراخوانی مستقیم دست‌دادن (Handshake) MCP استفاده شد. نتایج نشان داد:

• کلید محقق: در tools/list تنها ۷ ابزار دیده شد و rollback-deployment غایب بود. فراخوانی مستقیم این ابزار منجر به خطای 403 Forbidden شد.
• کلید اپراتور: در tools/list تعداد ۸ ابزار دیده شد و فراخوانی rollback-deployment با موفقیت انجام شد.
• لاگ حسابرسی: Kong دقیقاً یک مورد «رد درخواست» (Deny) برای oncall-investigator ثبت کرد. مقدار upstream_status خالی بود و proxy_latency برابر -1 بود، که ثابت می‌کند درخواست هرگز به API عملیاتی نرسیده است.

چالش‌های پیاده‌سازی

در طول راه‌اندازی، چندین مانع فنی شناسایی شد:

• تفسیر هدرها (Header Interpolation): نسخه ۱.۳.۰ Muse Code متغیرهای محیطی (مانند ${VAR}) را در هدرهای MCP تفسیر نمی‌کند. این باعث می‌شود Muse در صورت دریافت خطای 401، یک خطای گمراه‌کننده مربوط به ورود OAuth برگرداند. باید از کلیدهای لیتِرال (Literal) در پیکربندی استفاده کرد.
• مدیریت پیکربندی: Muse فقط از مسیر ~/.config/muse/settings.json می‌خواند. برای تست چندین هویت بدون بازنویسی تنظیمات، باید از XDG_CONFIG_HOME استفاده کرد (مثلاً XDG_CONFIG_HOME=/tmp/muse-investigator). کاربران همچنین باید فایل‌های auth.json و trust.json را به آن دایرکتوری کپی کنند.
• نشت لاگ (Log Leakage): تنظیم hide_credentials: true در Kong کلیدها را از درخواست‌های ارسالی به Upstream حذف می‌کند اما آن‌ها را از محموله http-log حذف نمی‌کند. این می‌تواند منجر به ذخیره کلیدهای API به صورت متن ساده در فایل‌های لاگ شود. پاک‌سازی (Redaction) در مقصد برای هدرهایی مانند apikey ،authorization ،x-api-key و cookie ضروری است.
• نگاشت آرگومان‌ها: پارامترهای مسیر و کوئری پیشوند می‌گیرند (مثلاً deployment_id تبدیل به path_deployment_id می‌شود). بدنه درخواست‌ها (Request Bodies) به آرگومان‌های نام‌گذاری شده تبدیل نمی‌شوند بلکه به صورت یک شیء واحد می‌رسند. برای عملکرد صحیح این مورد، شیء requestBody در OpenAPI 3 الزامی است.
• ظرافت‌های لاگ حسابرسی: یک لاگ «اجازه» (Allow)، گروه مصرف‌کننده را ثبت می‌کند، در حالی که یک لاگ «رد» (Deny)، مصرف‌کننده فراخوان (نام کاربر) را ثبت می‌کند. علاوه بر این، هر ابزار مجاز دو ورودی لاگ تولید می‌کند (یک فراخوانی MCP و یک درخواست HTTP لوپ‌بک) که هیچ ID مشترکی برای همبستگی ندارند.

تحلیل: تغییر مدل اعتماد

این رویکرد فرض بنیادی در جریان‌های کاری عامل‌محور را تغییر می‌دهد. به جای اینکه سعی کنیم با «پرامپت» مدل را ایمن کنیم یا به انسانی تکیه کنیم تا هر فراخوانی ابزار را تایید کند، ایمنی را در لایه زیرساخت می‌گنجانیم.

برای تیم‌های SRE و DevOps، این بدان معناست که «شعاع تخریب» (Blast Radius) یک عامل هوش مصنوعی دیگر توسط توانایی‌های استدلالی مدل، بلکه توسط RBAC (کنترل دسترسی مبتنی بر نقش) موجود در APIهای آن‌ها تعیین می‌شود. غافلگیرکننده‌ترین یافته این بود که حذف ابزارهای تخریبی، کیفیت تشخیص عامل را کاهش نداد؛ او همچنان قادر بود توصیه‌هایی مبتنی بر شواهد ارائه دهد، بدون اینکه قدرت اجرای آن‌ها را داشته باشد.

گام‌های بعدی برای سخت‌سازی (Hardening)

برای تکامل بیشتر این معماری، بهبودهای زیر توصیه می‌شود:

• Idempotency: افزودن کلیدهای Idempotency به ابزار create-incident برای جلوگیری از ایجاد حوادث تکراری در هنگام تلاش مجدد (Retry) عامل.
• مجوزهای زمینه‌ای (Contextual Permissions): محدود کردن کلید اپراتور به گونه‌ای که فقط در صورتی بتواند Rollback انجام دهد که یک حادثه متناظر از قبل باز شده باشد.
• محدودیت زمانی (Time-Boxing): پیاده‌سازی مجوزهای موقت، به طوری که ابزار Rollback فقط در طول یک رویداد فعال Paging در دسترس باشد.
• درگاه یکپارچه: هدایت ترافیک خودِ مدل از طریق Kong با استفاده از فلگ --base-url در Muse، تا هزینه توکن‌ها و محتوای پرامپت‌ها تحت همان نقطه کنترلی ابزارها قرار گیرند.
• محدودیت نرخ (Rate Limiting): افزودن محدودیت نرخ برای هر هویت تا از فشار بیش از حد عامل‌ها در حلقه‌های Retry بر APIهای عملیاتی جلوگیری شود.

شما می‌توانید پیاده‌سازی کامل، شامل اسکریپت‌های stack.sh و demo.sh را در مخزن گیت‌هاب پروژه مشاهده کنید: github.com/tejakummarikuntla/kong-muse-oncall-toolkit.