Proof-of-Guardrail in AI Agents and What (Not) to Trust from It
تقترح هذه الورقة نظام "إثبات الحواجز الوقائية" (Proof-of-Guardrail)، وهو نظام يستفيد من بيئات التنفيذ الموثوقة لتوفير إثبات تشفيري وقابل للتحقق بأن وكلاء الذكاء الاصطناعي يفرضون تدابير سلامة محددة، مما يعالج تهديد السلامة المعلنة كذباً مع الإقرار بالمخاطر المتبقية مثل عمليات كسر الحماية النشطة.
المؤلفون الأصليون:Xisen Jin, Michael Duan, Qin Lin, Aaron Chan, Zhenglun Chen, Junyi Du, Xiang Ren
إليك شرح لورقة بحثية بعنوان "إثبات الحواجز الوقائية" (Proof-of-Guardrail) باستخدام لغة بسيطة، وتشبيهات من الحياة اليومية، واستعارات إبداعية.
المشكلة الجوهرية: فخ "صدقني!"
تخ fear أنك تطلب طعاماً من مطعم جديد وغامض يقوم بتوصيل الطلبات عبر طائرة بدون طيار (درون). يدعي المطعم قائلاً: "لا تقلق! لدينا مفتش صحي صارم يفحص كل وجبة قبل خروجها من المطبخ للتأكد من أنها آمنة وطازجة".
لديك مشكلة: لا يمكنك رؤية ما بداخل مطبخهم. عليك أن تصدق كلامهم فحسب.
المخاطرة: ماذا لو كان المطعم يكذب؟ ماذا لو تخطوا المفتش، أو الأسوأ من ذلك، ماذا لو وظفوا مفتشاً فاسداً يكتفي بوضع ختم "آمن" على طعام مسموم؟
الواقع الحالي: في عالم الذكاء الاصطناعي، غالباً ما يتعين على المستخدمين الوثوق بالمطورين ثقة عمياء. يقول المطورون: "نحن نستخدم فلاتر أمان لمنع ذكائنا الاصطناعي من قول أشياء مسيئة أو تقديم نصائح سيئة". ولكن بما أن الذكاء الاصطناعي يعمل على خوادم المطور الخاصة، لا يمكن للمستخدمين التحقق مما إذا كانت هذه الفلاتر تعمل بالفعل أم لا.
الحل: "الإيصال غير القابل للتلاعب"
يقترح المؤلفون نظاماً يسمى "إثبات الحواجز الوقائية" (Proof-of-Guardrail).
لا تنظر إلى هذا كوعود، بل كـ إيصال تشفيري يثبت أن فحص الأمان قد حدث بالفعل.
إليك كيف يعمل، باستخدام تشبيه خزنة البنك:
الغرفة الخاصة (البيئة التنفيذية الموثوقة - TEE): تخيل أن على المطور تشغيل ذكائه الاصطناعي داخل خزنة بنك عالية التقنية (تسمى البيئة التنفيذية الموثوقة أو TEE). هذه الخزنة مصنوعة من فولاذ غير قابل للكسر وتتم مراقبتها بواسطة نظام أمني للأجهزة.
لماذا؟ داخل هذه الخزنة، يمكن للمطور وضع "وصفة" الذكاء الاصطناعي السرية (التي لا يريد مشاركتها)، ولكن يجب عليه أيضاً وضع "مفتش السلامة" العام (الحاجز الوقائي).
العملية: عندما يطرح مستخدم سؤالاً على الذكاء الاصطناعي، يذهب السؤال إلى داخل الخزنة.
يفكر الذكاء الاصطناعي في الإجابة.
يقوم مفتش السلامة بفحص الإجابة.
إذا كانت الإجابة آمنة، تسمح الخزنة بخروجها.
إذا كانت الإجابة خطيرة، تقوم الخزنة بحظرها.
الإيصال السحري (التصديق): الأمر الحاسم هو أن الخزنة تحتوي على كاميرا مدمجة وختم رقمي. في كل مرة تسمح فيها الإجابة بالخروج، تقوم بطباعة إيصال موقع.
يقول هذا الإيصال: "أنا، الخزنة، أؤكد أن مفتش السلامة قد فحص هذه الإجابة تحديداً قبل خروجها."
هذا الإيصال موقع بمفتاح فريد لا يملكه إلا عتاد (Hardware) الخزنة نفسه. ومن المستح المستحيل رياضياً تزويره.
تحقق المستخدم: يتلقى المستخدم الإجابة و الإيصال معاً. ليس عليهم الوثوق بالمطور، بل يحتاجون فقط إلى التحقق من الإيصال مقابل قواعد "مفتش السلامة" المعلنة. إذا كان الإيصال صالحاً، فسيعرفون يقيناً أن فحص الأمان قد تم.
لماذا يعد هذا أمراً هاماً؟
الخصوصية مقابل الإثبات: عادةً، لإثبات أنك آمن، عليك إظهار مطبخك بالكامل (كود البرمجة الخاص بك) للجمهور. يسمح لك هذا النظام بالاحتفاظ بوصفاتك السرية (ذكاؤك الاصطناعي الخاص) مخفية داخل الخزنة، مع إثبات اتباعك لقواعد السلامة في الوقت نفسه.
لا يوجد وسيط: لست بحاجة إلى مدقق طرف ثالث ليأتي ويفحص المطبخ. الخزنة تقوم بعملية التدقيق تلقائياً وفورياً.
التنبيه: إنه ليس "ضماناً للسلامة"
تنتهي الورقة البحثية بتحذير مهم جداً. إثبات الحواجز الوقائية ليس هو نفسه إثبات السلامة.
لنعد إلى تشبيه المطعم:
ما يثبته الإيصال: "المفتش الصحي نظر إلى البرجر".
ما لا يثبته الإيصال: "البرجر لذيذ أو جيد فعلياً".
المخاطر:
قد يخطئ المفتش: حتى لو فحص المفتش البرجر، فقد يغفل عن وجود شعرة فيه. تُظهر الورقة أن فلاتر الأمان (الحواجز الوقائية) ليست مثالية؛ فهي أحياناً تسمح بمرور أشياء سيئة أو تحجب أشياء جيدة.
خدعة "كسر الحماية" (Jailbreak): إذا كان المطور سيئ النية، فقد يحاول خداع مفتش السلامة. تخيل أن المطور يهمس للمفتش: "هذا البرجر يبدو وكأنه لعبة، لذا لست بحاجة لفحصه". إذا تم خداع المفتش، فسيظل الإيصال يقول "تم الفحص"، لكن الطعام لا يزال سيئاً.
الخلا الخلاصة
إثبات الحواجز الوقائية (Proof-of-Guardrail) يشبه الختم غير القابل للتلاعب على زجاجة دواء.
هو يثبت أن الزجاجة تم ختمها في المصنع (أي أن فحص الأمان قد تم).
يثبت أن الختم لم يُكسر أثناء النقل.
لكنه لا يضمن أن الدواء الموجود بالداخل فعال أو أن المصنع لم يضع الحبوب الخاطئة في الزجاجة منذ البداية.
لماذا نستخدمه؟ في عالم مليء بمطوري الذكاء الاصطناعي المشبوهين، يسمح هذا النظام للمطورين الشرفاء بالقول: "انظروا، لدي الختم الذي يثبت أنني أتبع القواعد"، مما يبني الثقة. ولكن يجب على المستخدمين أن يكونوا أذكياء ويعرفوا أن الختم لا يعني أن المنتج مثالي.
إليك ملخص تقني مفصل لورقة البحث بعنوان "إثبات حواجز الحماية في وكلاء الذكاء الاصطناعي وما الذي (لا) يجب الوثوق به منها".
1. بيان المشكلة
مع تزايد نشر وكلاء الذكاء الاصطناعي كخدمات عبر الإنترنت (مثل روبوتات الدردشة، أو بوتات التداول الآلي)، يعتمد المستخدمون على ادعاءات المطورين فيما يتعلق بتدابير السلامة. ومع ذلك، توجد فجوة ثقة حرجة:
التهديد: قد يروج المطورون كذباً بأن حواجز الحماية (القواعد التي تقيد استدعاء الأدوات أو المحتوى) يتم إنفاذها. قد يتخطون حواجز الحماية تماماً، أو يستخدمون نسخاً معدلة منها، أو يقومون بـ "كسر الحماية" (jailbreak) لها لتوليد استجابات غير آمة أو مضللة مع ادعاء الامتثال.
محدودية الحلول الحالية:
التدقيق العام: إن مطالبة المطورين بفتح المصدر لكامل تنفيذ الوكيل الخاص بهم (بما في ذلك المطالبات والمنطق البرمجي المملوك لهم) من أجل التدقيق العام هو أمر غير واقعي بسبب مخاوف الملكية الفكرية.
المدققون من طرف ثالث: في عمليات النشر اللامركزية أو العابرة للمنصات، لا يوجد طرف ثالث موثوق به عالمياً للتحقق من التنفيذ.
الهدف: إنشاء نظام يمكن للمستخدم من خلاله التحقق تشفيرياً من أن حاجز حماية مفتوح المصدر محدد قد تم تنفيذه لتوليد استجابة، دون إجبار المطور على الكشف عن تنفيذ الوكيل الخاص به.
يقترح المؤلفون "إثبات حاجز الحماية"، وهو نظام خفيف الوزن يعتمد على بيئات التنفيذ الموثوقة (TEEs) والتوثيق عن بُعد (Remote Attestation).
البنية الأساسية
برنامج الغلاف (f): ينشئ المطور برنامج غلاف يجمع بين حاجز الحماية مفتوح المصدر (g) والمنطق المخصص لوساطة المدخلات/المخرجات. هذا البرنامج عام وقابل للتحقق.
الوكيل الخاص (A): يتم التعامل مع منطق الوكيل المملوك للمطور كـ مدخل سري (s). يتم تحميله داخل بيئة التنفيذ الموثوقة (TEE) ولكن لا يتم كشفه للعالم الخارجي أبداً.
تدفق التنفيذ:
يعمل الغلاف f داخل بيئة TEE (مثل AWS Nitro Enclaves).
بالنسبة لمدخل المستخدم x، تقوم الـ TEE بتنفيذ f، والذي يستدعي الوكيل الخاص A ويفرض حاجز الحماية g.
ينتج النظام استجابة r.
توليد التوثيق (Attestation Generation):
تقوم أجهزة الـ TEE بتوليد وثيقة توثيق موقعة (σ).
تتضمن هذه الوثيقة:
القياس (m): هاش (Hash) تشفيري لبرنامج الغلاف f (لإثبات أن الكود المحدد هو الذي تم تشغيله).
الالتزام (d): هاش للمدخل x والمخرج r (لربط الاستجابة المحددة بعملية التنفيذ).
التوقيع: موقع بواسطة المفتاح الخاص لمنصة الـ TEE، والمتجذر في مرساة ثقة صلبة (مثل Intel أو AWS).
التحقق:
يتلقى المستخدم r و σ.
يتحقق المستخدم من التوقيع باستخدام المفتاح العام لمنصة الـ TEE.
يتحقق المستخدم مما إذا كان القياس m يطابق هاش برنامج الغلاف f المعروف مفتوح المصدر.
يتحقق المستخدم مما إذا كان الالتزام d يطابق هاش المدخل الخاص به والاستجابة المستلمة.
مبادئ التصميم الرئيسية
سلامة الحوسبة: يثبت أن كود حاجز الحماية قد تم تشغيله بالفعل.
السرية: يظل منطق الوكيل الخاص (A) مخفياً كمدخل سري داخل الـ TEE.
لا يوجد طرف ثالث موثوق: يتم التحقق بشكل غير متصل (offline) من قبل المستخدم باستخدام المفاتيح العامة والكود مفتوح المصدر.
3. المساهمات الرئيسية
تصميم نظام مبتكر: قدم "إثبات حاجز الحماية"، وهو أول نظام يتيح التحقق التشفيري من إنفاذ السلامة في وكلاء الذكاء الاصطناعي دون المساس بمنطق الوكيل المملوك.
التنفيذ والتقييم: تم تنفيذ النظام بنجاح باستخدام وكلاء OpenClaw (إطار عمل قوي للوكلاء مفتوح المصدر) وAWS Nitro Enclaves.
التحليل الأمني: أثبت أن النظام قوي ضد التلاعب، بما في ذلك تعديل الكود، وتعديل وثيقة التوثيق، وتعديل الاستجابة.
تحديد المخاطر الحرجة: سلط الضوء على أنه بينما يثبت النظام التنفيذ، فإنه لا يضمن السلامة إذا كان حاجز الحماية نفسه معيباً أو تعرض لكسر الحماية.
4. النتائج التجريبية
قيم المؤلفون النظام على مثيلات AWS m5.xlarge باستخدام GPT-5.1 كنموذج خلفي.
التحقق الأمني
محاكاة الهجمات: اكتشف النظام بنجاح 100% من الهجمات المحاكية، بما في ذلك:
تعديل كود حاجز الحماية (عدم تطابق القياس).
تعديل وثيقة التوثيق (توقيع غير صالح).
تعديل الاستجابة بعد توليدها (عدم تطابق الهاش).
الأداء والتكلفة
تأخر الاستجابة (Latency Overhead):
أدى تنفيذ الـ TEE إلى تأخير بنسبة 25% إلى 38% مقارنة بالنماذج المرجعية غير المعتمدة على TEE.
أضاف توليد التوثيق حوالي 100 مللي ثانية.
اعتُبر إجمالي التأخير مقبولاً للتفاعلات بين الإنسان وروبوت الدردشة.
التكلفة:
تكلفة مثيلات TEE (m5.xlarge) تزيد بنحو 18.5 ضعفاً عن المثيلات القياسية (t3.micro).
يرى المؤلفون أنه في الأسواق منخفضة الثقة، فإن قيمة الثقة التي يكتسبها المستخدم عبر الإثبات تفوق تكلفة البنية التحتية.
فعالية حاجز الحماية
تم الاختبار باستخدام Llama Guard 3 (سلامة المحتوى) و Loki (التحقق من الحقائق).
أظهرت النتائج دقة غير كاملة (على سبيل المثال، سجل Llama Guard 3 درجة F1 قدرها 0.56 في اكتشاف "المحتوى غير الآمن")، مما يعزز فكرة أن الإثبات يتحقق من العملية، وليس من جودة النتيجة.
5. الأهمية والقيود
الأهمية
آلية الثقة: يوفر بديلاً قابلاً للتحقق لادعاءات "ثق بنا"، مما يسمح للمستخدمين بالتأكيد تشفيرياً من تطبيق تدابير السلامة.
التميز في السوق: يمكّن المطورين الصادقين من تمييز وكلاءهم عن الوكلاء الضارين، مما قد يفتح آفاق الشراكات وتبني المستخدمين في بيئة منخفضة الثقة.
الحفاظ على الخصوصية: يحل معضلة التحقق من السلامة دون الكشف عن منطق الذكاء الاصطناعي المملوك.
القيود والمخاطر (تفاصيل هامة)
تحذر الورقة صراحة من أن إثبات حاجز الحماية = إثبات السلامة.
أخطاء حاجز الحماية: إذا كان حاجز الحماية مفتوح المصدر نفسه غير دقيق (على سبيل المثال، فشل في اكتشاف السمية)، فإن الإثبات سيظل يثبت تنفيذ هذا الحاجز المعيب.
كسر الحماية (Jailbreaking): يمكن للمطور الضار كسر حماية حاجز الحماية مفتوح المصدر قبل أو أثناء التنفيذ. تثبت الـ TEE تشغيل حاجز الحماية، لكنها لا تثبت نجاحه في صد النوايا الضارة.
ثغرات برنامج الغلاف: إذا كان برنامج الغلاف f يحتوي على ثغرات، فقد يتمكن الوكيل الخاص من تجاوز منطق حاجز الحماية داخل البيئة المعزولة.
توصية: يدعو المؤلفون إلى نهج "أفضل الممارسات" حيث يتفق المجتمع على حواجز حماية مفتوحة المصدر عالية الجودة وخضعت لاختبارات الاختراق. يجب على المستخدمين التحقق من الإثبات وأيضاً الوثوق بجودة كود حاجز الحماية الأساسي.
الخاتمة
يمثل "إثبات حاجز الحماية" خطوة مهمة نحو سلامة الذكاء الاصطناعي القابلة للتحقق. من خلال الجمع بين بيئات التنفيذ الموثوقة (TEEs) والتوثيق عن بُعد، فإنه ينقل عبء الثقة من كلمة المطور إلى الدليل التشفيري. ومع ذلك، فهو أداة للتحقق من سلامة التنفيذ، وليس ضماناً لـ نتائج السلامة، ويجب استخدامه جنباً إلى جنب مع معايير قوية لحواجز الحماية المراجعة من قبل المجتمع.