CAPMAS، وهو جهد مشترك بين EPFL وSwisscom، يتيح للمطورين منح وكلاء الذكاء الاصطناعي الفرعيين (child agents) أذونات محدودة النطاق عبر الـ macaroons. فهو يقلل من زمن انتقال معالجة الرموز (token-handling latency) بمقدار 30 ضعفاً، ويبقي رموز JWT الخاصة بالمستخدم الكامل بعيدة عن متناول الوكلاء.
لماذا يهم هذا التغيير
عندما يقوم نموذج لغوي كبير (LLM) بتنسيق الأدوات اللاحقة، غالباً ما تمنح الفرق الوكيل "الفرعي" المنبثق نفس رمز JWT الذي سجل به المستخدم دخوله. ورمز JWT هو كتلة موقعة تسرد كل إذن يمتلكه المستخدم — مثل بيانات الموارد البشرية، وملفات المشاريع، وصلاحيات المسؤول، وما إلى ذلك. إذا قام النموذج بإنشاء أمر تخريبي نتيجة "هلوسة"، فيمكن للوكيل الفرعي تنفيذه بسلطة المستخدم الكاملة. خطأ واحد قد يؤدي إلى كشف بيانات مؤسسة بأكملها.
أوجه القصور في الحلول المؤقتة الحالية
إن إصدار رمز ضيق النطاق عند الطلب باستخدام تدفق تبادل الرموز RFC 8693 يضيف عدة جولات من الاتصالات بنظام إدارة الهوية والوصول (IAM)، مما يؤدي إلى تضخم حركة مرور الشبكة وإدخال زمن انتقال ملحوظ. وتجد الفرق التي تقوم بتشغيل العديد من الوكلاء قصير العمر أن هذا العبء الإضافي يعيق العمل بسرعة.
كيف يعمل CAPMAS
يقسم CAPMAS منح الأذونات إلى مرحلتين:
- الترميز من جانب IAM – تقوم خدمة IAM بتشغيل برنامج ترميز (encoder) يترجم طلباً بلغة طبيعية (مثل "عرض الملفات في مجلد المالية") إلى مجموعة من الامتيازات المطابقة.
- إنشاء Macaroon – تصبح هذه الامتيازات caveats (قيوداً) داخل macaroon، وهو تنسيق رمز مرن يسمح للوكلاء اللاحقين بإضافة قيود إضافية ولكن لا يسمح لهم أبداً بإزالة القيود الموجودة.
عندما يتلقى الوكيل الـ macaroon، يمكنه تضييق النطاق — على سبيل المثال، قصر طلب قائمة الملفات على دليل فرعي — ولكنه لا يستطيع توسيعه. وفي كل خطوة، تتحقق خدمة IAM من تقاطع جميع الـ caveats، مما يضمن عدم تجاوز أي وكيل للصلاحية الأصلية.
أرقام الأداء التي تتحدث عن نفسها
- السرعة – يعالج CAPMAS طلب الإذن في أقل من 20 مللي ثانية، أي أسرع بنحو 30 مرة من عملية تبادل RFC 8693.
- الدقة – في اختبار مرجعي مع كتالوج كبير من الأدوات، أخطأ نموذج LLM قياسي في 53% من الامتيازات التي كان يحتاجها. بينما حقق CAPMAS دقة بلغت 90.9% مع معدل خطأ قدره 2.1% فقط.
- عرض النطاق الترددي – نظرًا لأن الـ macaroon يحمل فقط المجموعة النهائية من الـ caveats، فإن البيانات المتبادلة هي جزء ضئيل مما يتطلبه تدفق تبادل الرموز الكامل.
سير عمل عملي للتبني
- تصفية الطلب مسبقاً – تحويل نية المستخدم باللغة الطبيعية إلى قائمة سماح (allowlist) من نوع top-k قبل أن يلمس أي منسق كتالوج الأدوات.
- ختم قائمة السماح – ترميز قائمة السماح هذه في macaroon لا يمكن للوكيل الفرعي توسيعه.
- التحقق عند الخدمة – السماح للخدمة المستهدفة بطلب حساب تقاطع جميع الـ caveats من IAM قبل تنفيذ الطلب.
تستبدل هذه الخطوات نمط "إعطاء الطفل مفتاح المنزل بأكمله" بنموذج "تسليم مفتاح وحيد الاستخدام ومحدود النطاق".
ما لا يقوم CAPMAS بإصلاحه
لا يمنع هذا الإطار هجمات حقن الأوامر (prompt-injection attacks)، حيث يتلاعب المهاجم بطلب الـ LLM لحقن أوامر خبيثة. تغطي حمايته الوكلاء "الصادقين ولكن الفضوليين" ونماذج LLM غير الموثوقة التي قد تتصرف بخلاف ذلك بناءً على رمز JWT كامل. لا تزال الفرق بحاجة إلى دفاعات منفصلة — مثل تنقية المدخلات (input sanitisation)، أو العزل (sandboxing)، أو حواجز الحماية على مستوى النموذج (model-level guardrails) — لمعالجة التهديدات القائمة على الأوامر.
من المستفيد؟
- مطوروا المؤسسات الذين يبنون مساعدين مدفوعين بالذكاء الاصطناعي يستدعون واجهات برمجة تطبيقات (APIs) داخلية.
- الفرق الأمنية التي تسعى لتقليل نطاق الضرر (blast radius) في حال تعرض النموذج للاختراق.
- مالكو المنتجات الذين يحتاجون إلى فحوصات أذونات سريعة وموثوقة لعمليات إنشاء الوكلاء عالية التردد.
ما الخطوة التالية؟
CAPMAS هو تصميم مقترح.
الخلاصة: إن استبدال رموز JWT الكاملة للمستخدم بـ macaroons محدودة النطاق يمنح المطورين وسيلة لإبقاء وكلاء الذكاء الاصطناعي صادقين دون تحمل ضريبة زمن الانتقال التي تفرضها عمليات تبادل الرموز التقليدية. ويظل المقابل هو الحاجة المستمرة لضمانات الحماية من حقن الأوامر.