لایهٔ جدید AegisGate جلوی پرامپت‌های مبهم و دورزنی‌های امنیتی را گرفت

اگر یک عامل هوش مصنوعی ناگهان شروع به تولید متونی نامفهوم کند که در واقع دستوراتی مخفی هستند، بدانید که با یک رخنهٔ امنیتی جدی رو‌به‌رو هستید. برای مقابله با این تهدید، شرکت AegisGate Security نسخه ۱.۵.۰ از چارچوب سرور MCP (پروتکل زمینهٔ مدل) را منتشر کرد که شامل بیست و سومین لایهٔ امنیتی، به‌طور خاص برای شناسایی تکنیک‌های دورزنی است.

بسیاری از فیلترهای امنیتی تنها به دنبال کلمات کلیدی خام می‌گردند، اما مهاجمان از کدگذاری و مبهم‌سازی استفاده می‌کنند تا از این نگهبانان عبور کنند. تصور کنید یک فیلتر کلمه «نادیده بگیر» را مسدود کرده است؛ مهاجم برای دور زدن آن، کلمه را با استفاده از نویسه‌های با عرض صفر (Zero-width characters) به صورت «نا‌دیده بگیر» ارسال می‌کند. لایهٔ جدید شناسایی دورزنی (L2.5 Evasion Detection) دقیقاً همین شکاف را پر می‌کند. این نیاز به لایه‌های دفاعی پیشرفته‌تر زمانی حیاتی‌تر می‌شود که می‌بینیم حتی ابزارهای پیشرفته‌ای مانند مدل Prompt Guard 2 متا در شناسایی حملات تزریق پرامپت نرخ موفقیت بسیار پایینی دارند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های دفاعی باید به صورت پیاپی عمل کنند. این چارچوب که بر پایه معماری نسخه ۱.۳.۰ ساخته شده است، اکنون بین اسکن‌های سادهٔ عبارت منظم (L1) و شناسایی عصبی (L3) قرار می‌گیرد تا تلاش‌های انسانی برای فریب دادن مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — و وادار کردن آن به نادیده گرفتن دستورات سیستمی را متوقف کند.

سازوکار شناسایی دورزنی

طبق مستندات AegisGate، این شناسگر ۱۵ الگوی متمایز را در چهار دستهٔ اصلی بررسی می‌کند:

• کدگذاری (Encoding): شناسایی Base64، URL-encoding، یونیکد و موجودیت‌های HTML برای پنهان کردن محموله‌ها (به عنوان مثال، تبدیل دستور به رشته‌ای مانند aWdub3JlIHByZXZpb3Vz).
• تقسیم‌بندی (Splitting): تشخیص نویسه‌های با عرض صفر، درهم‌تنیدگی و تکه‌تکه کردن کلمات (مانند igno​re previ​ous).
• مبهم‌سازی (Obfuscation): شناسایی «Leet speak» (مثلاً جایگزینی اعداد به جای حروف مانند 1gn0r3 Pr3v10us)، CamelCase، Padding و تزریق نشانه‌گذاری (Markup Injection).
• معنایی (Semantic): علامت‌گذاری چارچوب‌های نقش‌آفرینی (Role-play)، بازنویسی دستورات، دستکاری زمینه (Context Manipulation) و دور زدن محدودیت‌های خروجی، مانند تکنیک معروف «تظاهر کن که DAN هستی».

این سامانه از یک آستانهٔ امتیازدهی برای تصمیم‌گیری استفاده می‌کند. امتیاز ۰.۸ یا بالاتر باعث مسدود شدن مستقل درخواست می‌شود، در حالی که امتیاز ۰.۳ تنها یک هشدار در لاگ ثبت می‌کند. به دلیل توسعه با زبان Go، این سیستم بدون وابستگی به CGO اجرا می‌شود و با بیلد‌های مبتنی بر اکتشاف (Heuristic) سازگار است. اکنون در لاگ‌های زمان شروع (Startup Log)، زنجیره کامل پردازش به‌طور صریح چاپ می‌شود: auth → rbac → regex → evasion → neural → toolPoison → ...

استخراج اطلاعات در میانهٔ ابزار و انتقال داده

یکی از کاربردی‌ترین اضافات این نسخه، قابلیت «استخراج» (Elicitation) است که به سرور اجازه می‌دهد در میانهٔ اجرای یک ابزار، از کلاینت درخواست اطلاعات کند. برای مثال، یک ابزار می‌تواند متوقف شود و بپرسد: «برای ادامه به کلید API شما نیاز دارم؛ لطفاً آن را ارسال کنید».

این قابلیت در سه پروتکل انتقال پیاده‌سازی شده است:

• HTTP/SSE: استفاده از همبستگی نامتقارن (Async Correlation) از طریق یک رجیستری درخواست‌های معلق. سرور رویداد elicitation/create را به عنوان یک رویداد SSE ارسال می‌کند و پاسخ کلاینت به صورت یک درخواست POST مجزا با یک Request ID منطبق می‌رسد.
• TCP: به‌کارگیری الگوی درخواست-پاسخ همزمان روی اتصال دوطرفه. سرور elicitation/create را ارسال کرده و تا زمان رسیدن پاسخ روی همان اتصال، عملیات را متوقف (Block) می‌کند.
• stdio: استفاده از همان الگوی همزمان از طریق لوله‌های stdin/stdout.

برای مدیریت این فرآیند، ElicitationRegistry درخواست‌های معلق را با شناسه‌های یک‌نواخت (Monotonic IDs)، حل‌وفصل ایمن در محیط‌های همزمان (Concurrent-safe) و مهلت زمانی پیش‌فرض ۳۰ ثانیه مدیریت می‌کند. هندلرهای ابزار از متد ElicitInput() برای دریافت پاسخ‌های کاربر یا بازگرداندن خطای Timeout استفاده می‌کنند. همچنین در پاسخِ مقداردهی اولیه (Initialize Response)، قابلیت استخراج اعلام می‌شود؛ کلاینت‌هایی که از آن پشتیبانی نمی‌کنند، خطای «متد یافت نشد» را دریافت خواهند کرد.

ارتقای زیرساخت و عملکرد

AegisGate همچنین پیاده‌سازی SSE (رویدادهای ارسالی سرور) را بازطراحی کرد. اکنون این چارچوب از مالتی‌پلکسینگ (Multiplexing) در هر نشست پشتیبانی می‌کند. این کار با تغییر sseConns از یک Map از تک‌اتصال‌ها به یک Map از اسلایس‌های اتصال (map[string][]*sseConn) انجام شده است. این تغییر اجازه می‌دهد چندین جریان موازی در هر نشست وجود داشته باشد و کلاینت بتواند در حالی که اتصال قدیمی باز است، مجدداً متصل شود.

علاوه بر این، استاندارد HTML برای اتصال مجدد با استفاده از Last-Event-ID پیاده‌سازی شده است. رویدادهای SSE اکنون دارای شناسه‌های یک‌نواخت هستند (مثلاً id: 42 ). هنگام اتصال مجدد، کلاینت مقدار Last-Event-ID: 41 را ارسال می‌کند و سرور رویدادهای از دست رفته را از یک بافر حلقوی (Ring Buffer) محدود به ۱۰۰ رویداد بازپخش می‌کند.

پشتیبانی از دسته‌های JSON-RPC 2.0 در تمام پروتکل‌های انتقال (TCP, stdio, HTTP) فعال شد. این یعنی کلاینت‌ها می‌توانند آرایه‌ای از درخواست‌ها — مانند tools/list ،ping و notifications/initialized — را در یک پیام ارسال کنند. پاسخ‌ها جمع‌آوری شده و به صورت یک آرایه بازگردانده می‌شوند، هرچند طبق استاندارد، دسته‌هایی که فقط شامل اعلان (Notification) هستند، پاسخی تولید نمی‌کنند. هر درخواست در این دسته، به‌طور مستقل از تمام ۲۳ لایهٔ امنیتی عبور می‌کند.

برای جلوگیری از اتمام منابع (Resource Exhaustion)، محدودیت نرخ (Rate Limiting) برای هر ابزار اضافه شد. در حالی که محدودیت‌های کلی وجود دارند، مدیران اکنون می‌توانند سقف‌های خاصی را از طریق ServerConfigV2 تعریف کنند. برای مثال، ابزار گران‌قیمت exec به ۵ فراخوانی در هر نشست و ابزار ارزان read_file به ۱۲۰ فراخوانی محدود شود. این سیستم از یک شمارنده اتمیک (Atomic Counter) برای هر ابزار در هر نشست استفاده می‌کند که پس از انقضای نشست، بازنشانی می‌شود.

تست‌های سخت‌گیرانه و رفع باگ‌ها

به گزارش تیم توسعه، مجموعهٔ تست‌ها از ۴۱۲ مورد به ۶۴۳ مورد افزایش یافته است که تفکیک آن به شرح زیر است:

• واحد/یکپارچگی (Unit/Integration): افزایش از ۴۱۲ به ۶۱۱ مورد.
• بار/استرس (Load/Stress): افزایش از ۰ به ۳۲ مورد.
• بنچمارک‌ها (Benchmarks): افزایش از ۱۰ به ۱۴ مورد.
• اهداف فازینگ (Fuzz Targets): افزایش از ۰ به ۳ مورد.
• پوشش کد (Coverage): بهبود از ۹۱.۳٪ به ۹۲.۰٪.

این شامل ۳۲ تست بار به سبک k6 در ۷ دسته مختلف است (با تگ //go:build load:). این تست‌ها شامل «Stress» (افزایش تدریجی تا ۵۰۰ اتصال همزمان)، «Burst» (پیک ۱۲,۷۱۰ درخواست در ثانیه) و «Crush» (شناسایی نشت‌های goroutine که در آن Δ=0 پس از خاموشی باشد) است. تست‌های دیگر شامل «Chaos» (قطع تصادفی اتصال)، «HTTP» (توان عملیاتی ۲,۲۹۰ rps)، «Cross-transport» (نسبت سربار ۰.۶۲ برای HTTP در مقابل TCP) و «FD leak» (بررسی ۱,۰۰۰ چرخه اتصال) می‌باشد.

یکپارچگی مداوم (CI) اکنون شامل یک Race Detector است که دستور go test -race را روی هر Push و PR اجرا می‌کند. این ابزار اخیراً یک Race Condition را در کمکی mockResponseWriter شناسایی کرد، جایی که یک goroutine تست متد buf.String() را فراخوانی می‌کرد در حالی که دیگری از طریق fmt.Fprintf در حال نوشتن بود. این مشکل با یک sync.Mutex برطرف شد. بررسی‌های CI به ۲۷ مورد گسترش یافته است، از جمله benchstat برای ردیابی پس‌رفت‌ها (Regression) و بررسی‌های go mod tidy.

یک باگ بحرانی در مورد عدم تطابق Session ID در HTTP نیز حل شد. پیش از این، میان‌افزار احراز هویت، شناسه نشست را با شناسه RBAC جایگزین می‌کرد، اما لایه انتقال HTTP همچنان از شناسه اصلی HTTP برای ذخیره نشست استفاده می‌کرد. این امر باعث می‌شد درخواست‌های بعدی با خطای «نشست یافت نشد یا منقضی شده است» مواجه شوند. اکنون چارچوب، شناسه نشست HTTP را به‌طور جداگانه ردیابی می‌کند تا جستجوهای سازگار تضمین شود.

این به‌روزرسانی تمرکز امنیت MCP را از فیلترینگ ساده به شناسایی فعال دورزنی تغییر می‌دهد و AegisGate را به مدل «اعتماد صفر» (Zero-trust) در تعاملات ابزارهای هوش مصنوعی نزدیک‌تر می‌کند.

توسعه‌دهندگان اکنون می‌توانند این سرور را در MCP Registry در آدرس io.github.aegisgatesecurity/aegisgate-mcp بیابند یا آن را از طریق Docker با تگ ۱.۵.۰ مستقر کنند. برای کسانی که از سورس بیلد می‌کنند، چارچوب از یک بیلد heuristic-only (حدود ۸ مگابایت) یا یک بیلد کامل ML که ONNX Runtime را از طریق make build-cgo لینک می‌کند، پشتیبانی می‌کند.

گام بعدی شما

• اگر از سرورهای MCP استفاده می‌کنید، نسخه ۱.۵.۰ را از طریق Docker با تگ مربوطه مستقر کنید.
• در صورت بیلد از سورس، برای کاهش حجم (حدود ۸ مگابایت) از حالت heuristic-only استفاده کنید.
• تنظیمات ServerConfigV2 را برای محدود کردن ابزارهای پرهزینه بررسی کنید.

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