Language-Based Agent Control
تقدم هذه الورقة نموذج التحكم القائم على اللغة (LBAC)، وهو نموذج برمجي يضمن التزام التطبيقات الوكيلية بالسياسات الأمنية المحددة من قبل المستخدم عبر اشتراط قيام الوكلاء بتوليد برامج جيدة النوع يتم التحقق منها استاتيكياً قبل التنفيذ، مما يوحد ضمانات السلامة عبر كل من الهياكل البرمجية التي يكتبها المطور والسلوك المولد بواسطة الوكيل مع الحفاظ على القدرة التعبيرية الحسابية.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك وظفت مساعداً موهوباً جداً ولكنه غير متوقع (وكيل ذكاء اصطناعي) للقيام بمهمة ما، مثل تنظيم أوراق بحثك. أنت تريده أن يكون مبدعاً وذكياً، ولكنك تحتاج أيضاً للتأكد من أنه لن يقوم بحذف ملفاتك بالخطأ (أو بسوء نية)، أو سرقة أسرارك، أو اختلاق بيانات وهمية.
حالياً، تجبر معظم الأنظمة على الاختيار بين الأمان والحرية:
- نهج "صندوق الألعاب" (أدوات مقيدة): تمنح المساعد صندوقاً صغيراً من الأدوات المعتمدة مسبقاً. لا يمكنه الخروج من الصندوق. هو آمن جداً، لكنه لا يستطيع القيام بأي شيء ذكي أو معقد. إذا احتاج لترتيب قائمة، فعليه أن يطلب منك القيام بذلك واحداً تلو الآخر.
- نهج "المطبخ المفتوح" (مفسرات الكود): تمنح المساعد وصولاً كاملاً إلى المطبخ. يمكنه طبخ أي شيء يريده! ولكن إذا ارتبك أو تعرض للخداع، فقد يحرق المنزل أو يقدم لك طعاماً مسموماً.
تقدم هذه الورقة طريقة جديدة تسمى التحكم في الوكيل القائم على اللغة (LBAC). فكر في الأمر كأنك تعطي المساعد مطبخاً سحرياً حيث تُكتب قوانين الفيزياء (قوانين الكون) بلغة يجب عليه التحدث بها.
الفكرة الجوهرية: "اللغة السحرية"
بدلاً من مجرد إعطاء المساعد قائمة بـ "الأفعال والممنوعات"، يقوم المبرمجون ببناء النظام بأك its داخل لغة خاصة وصارمة (مثل نسخة شديدة الصرامة من لغة برمجة تسمى Haskell).
في هذه اللغة السحرية، تعمل الأنواع (العلامات الموضوعة على البيانات) كحراس أمن.
- إذا كانت قطعة من البيانات تحمل علامة "موثوق" (Trusted)، فهذا يعني أنها جاءت من مصدر آمن (مثل قاعدة بيانات موثقة).
- إذا كانت تحمل علامة "غير موثوق" (Untrusted)، فهذا يعني أنها جاءت من الإنترنت أو من مستخدم.
- وللغة قاعدة: لا يمكنك خلط المكونات "غير الموثوقة" في طبق "موثوق".
كيف يعمل ذلك في الممارسة العملية
لنعد إلى مثال الأوراق البحثية من النص. تطلب من الوكيل: "ابحث عن أقدم ورقة بحثية حول الخصوصية التفاضلية وأضفها إلى قائمة المراجع الخاصة بي".
- الطريقة القديمة (مفسر الكود): يكتب الوكيل برنامجاً. قد يقرر ببسا p إنشاء عنوان ورقة بحثية وهمية، ويكتبها في ملفك، ويقول: "ها هي!"؛ النظام يتحقق فقط مما إذا كان الكود يعمل، وليس ما إذا كان المحتوى حقيقياً.
- الطريقة القديمة (الأدوات المقيدة): تمنح الوكيل فقط زر "جلب وحفظ". لا يمكنه ترتيب أو تصفية النتال بنفسه. يظل عالقاً في انتظارك لتخبره أي النتائج يختار.
- طريقة (LBAC) عبر (TYPEGUARD):
- يكتب الوكيل برنامجاً في اللغة السحرية.
- للحصول على ورقة بحثية، يجب عليه استخدام دالة خاصة لا تعيد إلا ملصق "موثوق".
- للكتابة في ملفك، تتطلب الدالة وجود ملصق "موثوق".
- الفحص السحري: قبل أن يُسمح حتى بتشغيل برنامج الوكيل، ينظر "مدقق الأنواع" (أمين مكتبة صارم) إلى الكود.
- إذا حاول الوكيل كتابة ورقة بحثية مزيفة (ليس لها ملصق "موثوق") في الملف، سيقول له الأمين: "خطأ! هذا الكود لا يطابق القواعد. حاول مرة أخرى".
- يتلقى الوكيل رسالة الخطأ، ويدرك خطأه، ثم يعيد كتابة الكود لجلب ورقة بحثية حقيقية من قاعدة البيانات أولاً.
- بمجرد اجتياز الكود للفحص، يتم تشغيله.
لماذا يعد هذا أمراً هاماً
تدعي الورقة أن هذا النهج يحل مشكلة "الأمان مقابل الحرية":
- الحرية: لا يزال بإمكان الوكيل كتابة برامج معقدة، وترتيب القوائم، وإجراء العمليات الحسابية. ليس عالقاً مع صندوق صغير من الأدوات.
- الأمان: بما أن الوكيل يجب أن يكتب كوداً يتوافق مع القواعد الصارمة للغة، فإنه لا يستطيع مادياً القيام بأفعال تكسر القواعد (مثل تسريب بيانات سرية أو كتابة ملفات مزيفة). إذا لم يجتز الكود "فحص النوع"، فإنه لا يعمل أبداً.
خدعة "الوكيل المتداخل"
تظهر الورقة أيضاً أن هذا يعمل حتى لو قام الوكيل الرئيسي بتوظيف "وكيل فرعي" للمساعدة.
- تخيل أن الوكيل الرئيسي يطلب من وكيل فرعي فحص بريد إلكتروني مشبوه.
- يقرأ الوكيل الفرعي البريد الإلكتروني (الذي يعتبر "متسخاً" أو غير موثوق).
- بسبب قواعد اللغة السحرية، يتم وضع الوكيل الفرعي تلقائياً في "منطقة حجر صحي". يمكنه قراءة البريد الإلكتروني، لكن لا يمكنه تمرير تلك البيانات "المتسخة" إلى أدوات الوكيل الرئيسي إلا إذا وضعها في حاوية خاصة يسمح الوكيل الرئيسي بفتحها.
- يحدث هذا تلقائياً بسبب قواعد اللغة، وليس بسبب نظام أمني منفصل.
الملخص
تجادل الورقة بأنه بدلاً من بناء جدران حول وكلاء الذكاء الاصطناعي، يجب علينا بناء عالم الذكاء الاصطناعي داخل لغة صارمة قائمة على القواعد. في هذا العالم، لا يعتبر الأمان طبقة منفصلة تضيفها فوق النظام، بل هو جزء أصيل من نسيج كيفية تفكير الوكيل وكتابته للكود. إذا حاول الوكيل كسر القواعد، فإن اللغة نفسها تقول "لا"، ويتم حظر الإجراء قبل وقوعه.
اختبر المؤلفون هذا باستخدام ثلاثة سيناريوهات:
- أصل البيانات (Data Provenance): ضمان إضافة أوراق بحثية حقيقية مستمدة من قاعدة البيانات فقط إلى قائمة المراجع.
- عزل نظام الملفات (File System Sandboxing): ضمان قدرة الوكيل على التعامل فقط مع الملفات في مجلدات محددة (مثل رمز "القدرة" أو Capability Token).
- تدفق المعلومات (Information Flow): ضمان عدم تسريب البيانات السرية إلى الإنترنت العام عن طريق الخطأ.
في جميع الحالات، حافظ النظام على ذكاء ومرونة الوكيل مع ضمان عدم قدرته على كسر القواعد.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.