CAPMAS، حاصل تلاش مشترک EPFL و Swisscom، به توسعهدهندگان اجازه میدهد تا از طریق macaroonها، مجوزهای محدود و مشخصی را به عاملهای فرعی هوش مصنوعی (AI child agents) اختصاص دهند. این روش تأخیر در مدیریت توکن را تا ۳۰ برابر کاهش داده و از دسترسی عاملها به JWTهای کامل کاربر جلوگیری میکند.
چرا این تغییر اهمیت دارد
وقتی یک LLM ابزارهای پاییندست را مدیریت میکند، تیمها اغلب همان JWT را که کاربر با آن وارد شده است، به عامل «فرعی» ایجاد شده واگذار میکنند. یک JWT یک بلوک امضا شده است که تمام مجوزهای کاربر را فهرست میکند—دادههای منابع انسانی، فایلهای پروژه، حقوق مدیریت و غیره. اگر مدل دچار توهم شده و دستوری مخرب صادر کند، عامل فرعی میتواند آن را با تمام اختیارات کاربر اجرا کند. یک اشتباه میتواند دادههای کل یک سازمان را در معرض خطر قرار دهد.
کاستیهای راهکارهای فعلی
صدور یک توکن محدود در لحظه با استفاده از جریان تبادل توکن RFC 8693، چندین مرحله رفت و برگشت به سیستم IAM اضافه میکند، ترافیک شبکه را افزایش میدهد و باعث ایجاد تأخیر محسوس میشود. تیمهایی که عاملهای کوتاه-مدت زیادی ایجاد میکنند، به سرعت متوجه میشوند که این بار اضافی (overhead) بسیار سنگین است.
CAPMAS چگونه کار میکند
CAPMAS اعطای مجوز را به دو مرحله تقسیم میکند:
- کدگذاری در سمت IAM – سرویس IAM یک رمزگذار (encoder) را اجرا میکند که یک درخواست به زبان طبیعی (مثلاً «فایلهای پوشه مالی را لیست کن») را به مجموعهای از امتیازات مطابقتیافته ترجمه میکند.
- ایجاد macaroon – آن امتیازات به caveats (محدودیتها) در داخل یک macaroon تبدیل میشوند؛ یک قالب توکن منعطف که به عاملهای پاییندست اجازه میدهد محدودیتهای بیشتری اضافه کنند، اما هرگز نمیتوانند محدودیتهای موجود را حذف کنند.
وقتی یک عامل macaroon را دریافت میکند، میتواند دامنه را محدودتر کند—مثلاً درخواست لیست کردن فایلها را فقط به یک زیرپوشه محدود کند—اما نمیتواند آن را گسترش دهد. در هر مرحله، سرویس IAM تقاطع (intersection) تمام caveats را تأیید میکند و تضمین میکند که هیچ عاملی از اجازه اولیه فراتر نرود.
اعداد عملکردی که خود گویای همه چیز هستند
- سرعت – CAPMAS یک درخواست مجوز را در کمتر از ۲۰ میلیثانیه پردازش میکند که تقریباً ۳۰ برابر سریعتر از تبادل RFC 8693 است.
- دقت – در یک بنچمارک با کاتالوگ بزرگی از ابزارها، یک LLM استاندارد ۵۳٪ از امتیازات مورد نیاز خود را از دست داد. CAPMAS به دقت ۹۰.۹٪ با تنها ۲.۱٪ نرخ خطا دست یافت.
- پهنای باند – از آنجایی که macaroon فقط مجموعه نهایی caveats را حمل میکند، دادههای تبادل شده تنها بخشی از دادههای مورد نیاز در یک جریان کامل تبادل توکن است.
یک گردش کار عملی برای پذیرش
- پیشفیلتر کردن درخواست – تبدیل قصد کاربر در زبان طبیعی به یک لیست سفید (allowlist) top-k، پیش از آنکه هر هماهنگکننده (orchestrator) با کاتالوگ ابزارها تماس پیدا کند.
- مهر و موم کردن لیست سفید – کدگذاری آن لیست سفید در یک macaroon که عامل فرعی نمیتواند آن را گسترش دهد.
- تأیید در سرویس – اجازه دادن به سرویس هدف برای درخواست از IAM جهت محاسبه تقاطع تمام caveats، پیش از اجرای درخواست.
این مراحل، الگوی «دادن کلید خانه به عامل فرعی» را با مدل «تحویل دادن یک کلید تکبار مصرف با دامنه محدود» جایگزین میکند.
آنچه CAPMAS اصلاح نمیکند
این چارچوب جلوی حملات تزریق دستور (prompt-injection) را نمیگیرد، جایی که مهاجم دستورات مخرب را از طریق دستکاری دستور (prompt) مدل LLM وارد میکند. محافظت آن شامل عاملهای «صادق اما کنجکاو» (honest-but-curious) و LLMهای غیرقابل اعتماد است که در غیر این صورت ممکن بود با یک JWT کامل عمل کنند. تیمها همچنان به دفاعهای مجزا—مانند پاکسازی ورودی (input sanitisation)، محیطهای ایزوله (sandboxing) یا حفاظهای سطح مدل (model-level guardrails)—برای مقابله با تهدیدات مبتنی بر prompt نیاز دارند.
چه کسانی سود میبرند
- توسعهدهندگان سازمانی که دستیارهای مبتنی بر هوش مصنوعی برای فراخوانی APIهای داخلی میسازند.
- تیمهای امنیتی که به دنبال کاهش شعاع تخریب (blast radius) یک مدل هکشده هستند.
- مالکان محصول که برای ایجاد عاملهای پرکاربرد، به بررسی مجوزهای سریع و قابل اعتماد نیاز دارند.
گام بعدی
CAPMAS یک طرح پیشنهادی است.
نکته کلیدی: جایگزینی JWTهای کامل کاربر با macaroonهای محدود، راهی را به توسعهدهندگان میدهد تا عاملهای هوش مصنوعی را بدون پرداخت جریمه تأخیرِ جریانهای سنتی تبادل توکن، قابل اعتماد نگه دارند. با این حال، نیاز به حفاظهای ضد تزریق دستور (prompt-injection) همچنان باقی است.