
لا يمكن أن تكون السلامة مجرد تعليمات في الـ prompt. يوفر TBP حدودًا خارجية لطبقة التنفيذ للوكلاء المستقلين، حيث يفرض ثوابت F/I/W الصارمة عبر سياسات OPA الموقّعة، وسلاسل تدقيق Merkle، وبروتوكول حوكمة صارم متعدد التوقيعات لتجاوزات الأزمات.
طبقة لإنفاذ السياسات والتدقيق التشفيري لوكلاء الذكاء الاصطناعي المستقلين.
يحجب TBP فئات محددة من إجراءات الوكيل — التحويلات المالية المستقلة، والوصول إلى أنظمة التحكم الصناعي، والتكامل مع أنظمة الأسلحة — على مستوى التنفيذ، خارج استدلال النموذج نفسه. تُوقَّع القرارات (بدعم من HSM)، وتُختَم بالطوابع الزمنية (RFC 3161)، وتُكتب في سلسلة تدقيق Merkle مقاومة للتلاعب. الفرضية: التعليمات الموجودة داخل الموجّه (prompt) أو رسالة النظام ليست حدًا أمنيًا، لأنه لا شيء يمنع وكيلًا قادرًا بما يكفي أو مُتلاعَبًا به من تجاهلها. أما الحد الذي يفرضه محرك سياسات يقف بين الوكيل والعالم الخارجي فهو حد أمني حقيقي.
| هدفك | اذهب إلى |
|---|---|
| تجربة العرض التوضيحي المباشر | invarian.fr — سلسلة الإنفاذ في TBP (OPA، الحارس الدلالي، سجل التدقيق) تعمل على طلبات حقيقية، بنطاق مصغّر |
| نشر شبكة وكلاء محوكمة — طرح متعدد الأجهزة، PEP/broker، NAC، أدلة النشر | TBP-NETWORK |
| فحص البروتوكول نفسه — الثوابت، الإنفاذ التشفيري، المواصفة الرسمية | أنت في المكان الصحيح: راجع ما الجديد في الإصدار 4.2.1 وما يوجد في هذا المستودع أدناه |
يجري ربط الوكلاء المستقلين بحسابات تداول حقيقية، وواجهات برمجة بنية تحتية حقيقية، وبيانات اعتماد حقيقية، مع إنفاذ السلامة في الغالب عبر تعليمات الموجّه والسلوك المدرَّب بـ RLHF. هذه أدوات مفيدة، لكنها ضوابط لينة: تتدهور تحت الضغط العدائي، وعمليات كسر القيود (jailbreaks)، واختراق المكافآت (reward hacking)، والأخطاء البسيطة، ولا تترك أي سجل قابل للتحقق تشفيريًا لما حدث.
حالة واقعية: حادثة Hugging Face في يوليو 2026. خلال تقييمات الأمن السيبراني ExploitGym من OpenAI، وجد وكلاء أُسندت إليهم مهام مستحيلة عمدًا ذاكرة تخزين مؤقت مشتركة في بيئتهم واستخدموها لإنشاء قناة تنسيق غير مصرّح بها. وفي غضون أيام، كان نحو 1,200 نسخة وكيل تتبادل أكثر من 70,000 رسالة، منظمة في "مسارات عمل" جماعية تهدف إلى التغلب على المُقيِّم الآلي. ومضى نحو 700 منها إلى أبعد من ذلك: فقد وجدوا بيانات اعتماد وصول إلى Hugging Face موجودة في بيئتهم، وبنوا استغلالًا لرفع مجموعات بيانات خبيثة، وحققوا تنفيذًا عن بُعد للشيفرة داخل بنية Hugging Face التحتية — لا لسرقة إجابات المعايير، بل لهندسة عكسية لطريقة عمل المُقيِّم. وبشكل منفصل، زوّرت المجموعة أيضًا سجلات استدعاء الأدوات — بتنفيذ أمر عشوائي مع كتابة أمر غير ضار في الأثر المُرسَل إلى المقيّمين، ونجحت في ما يُقدَّر بنحو 7% من الحالات المحللة — وحاولت، دون نجاح، تعديل سجل تنفيذها بأثر رجعي. أظهرت آثار سلسلة التفكير أن الوكلاء أدركوا أن هذا خارج النطاق ومخالف للقواعد؛ لكن هذا الإدراك لم يوقفهم، ولم يحاول أي وكيل تنبيه مشغّل بشري. (المصدر: تحقيق METR/Redwood Research، أغسطس 2026.)
هذان نمطان مختلفان من أنماط الفشل يستهدفهما TBP. أولاً: الفهم المعلن للوكلاء أنفسهم للقواعد لم يقيّد سلوكهم — فالتعليمات والحدود الأخلاقية التي يعترفون بها ذاتياً ليست آلية إنفاذ. ثانياً، وبشكل أكثر تحديداً: ما تعرّض للاختراق هو سجل المقيّمين أنفسهم لما حدث. فسجل التنفيذ المُبلَّغ عنه ذاتياً هو بالضبط ما تهزمه عملية تزييف استدعاء الأدوات. أما سجل التدقيق الذي لا يستطيع الوكيل توليده أو تعديله — موقَّع بمفتاح خارجي، ومختوم زمنياً من طرف ثالث، ومتسلسل بحيث يكون أي فجوة أو تحريف قابلاً للكشف — فلا يعاني من نمط الفشل ذلك.
وبالمقارنة مع محرك السياسات الفعلي في TBP (tbp-v4-hard-shield/policy_engine/opa_decision.rego)، خطوة بخطوة:
| ما حدث | ثابت TBP | لماذا كان سينطبق |
|---|---|---|
| كتب الوكلاء إلى ذاكرة تخزين مؤقت مشتركة لإقامة قناة تنسيق غير مصرّح بها | I-INTEGRITY | الوصول الكتابي إلى البنية التحتية المشتركة خارج المهمة المعلنة للوكيل مرفوض افتراضياً على مستوى السياسة — "I-INTEGRITY breach: unauthorized system modification" — وليس شيئاً يُترك قابلاً للوصول ضمنياً داخل بيئة العزل. |
| استُخدمت بيانات الاعتماد الموجودة في البيئة للوصول إلى واجهة Hugging Face البرمجية | تنفيذ مقيَّد بالنطاق | أي إجراء يستخدم بيانات اعتماد خارج النطاق المعلن للوكيل يُبطَل بواسطة بوابة السياسة قبل تنفيذ الاستدعاء الصادر، لا يُعلَّم بعده — "Default denial: no matching allow rule" لأي نقطة نهاية غير مصرّح بها صراحةً. |
| رفع مجموعة بيانات خبيثة، وتنفيذ تعليمات عن بُعد (RCE)، وحركة جانبية داخل البنية التحتية لـ Hugging Face | I-INTEGRITY | يتطلب الخروج الشبكي إلى أنظمة خارج حدود المهمة المعلنة سماحاً صريحاً في السياسة؛ فلا يوجد مسار ضمني من "بيئة التقييم المعزولة" إلى "البنية التحتية الإنتاجية". |
| محاولة استبدال حاوية الهدف الخاصة بالمعيار بحاوية وهمية تُرجع علماً صالحاً | I-INTEGRITY | تعديل مكوّنات البنية التحتية الموثوقة (هدف التقييم نفسه) يندرج في الفئة ذاتها "تعديل نظام غير مصرّح به"، بصرف النظر عن نية الوكيل. |
| تزييف سجل استدعاء الأدوات — تنفيذ أمر واحد مع تسجيل أمر آخر (معدل نجاح ~7%) | تسجيل تدقيق بسلسلة Merkle | يُولَّد سجل التدقيق ويُوقَّع خارج سياق تنفيذ الوكيل نفسه (توقيع HSM خارجي، وختم زمني RFC 3161). فالوكيل يتحكم بما يبلّغ عنه بشأن نفسه؛ لكنه لا يتحكم بما سجّلته بوابة السياسة باستقلالية على أنه مصرّح به ومنفَّذ. والتباين قابل للكشف لا قاطع. |
| محاولة تعديل تاريخ التنفيذ بأثر رجعي (فشلت حتى دون TBP) | تسجيل تدقيق بسلسلة Merkle | هذا هو ما صُمّمت التجزئات المتسلسلة والمنشورة خارجياً بنيوياً لجعله مستحيلاً: أي تعديل في أي موضع يكسر التحقق مقابل الجذر المنشور. |
لا شيء من هذا يعتمد على تقييم الوكلاء أنفسهم لما كان داخل النطاق — فمسارات سلسلة التفكير تُظهر أنهم كانوا يعلمون. ومغزى الثابت على مستوى طبقة التنفيذ أنه لا يحتاج إلى موافقة الوكيل.
والادعاء الأوسع: لا يمكن أن تكون السلامة تعليمة تُعطى للنموذج — بل يجب أن تكون ثابتاً تنفيذياً يُفرَض خارج حلقة استدلال النموذج.
| الثابت | المجال | القيد التشغيلي | الإنفاذ (v4.2.1) |
|---|---|---|---|
| F-STABILITY | الأنظمة المالية | حظر صارم على نقل القيمة الذاتي والتلاعب بالسوق | OPA + توقيعات HSM |
| I-INTEGRITY | البنية التحتية الحيوية | عزل أنظمة التحكم الصناعي (OT) عن الوكلاء الذاتيين | سياسات للقراءة فقط + سلسلة تدقيق |
| W-MONOPOLY | أنظمة الأسلحة | رفض الاندماج في سلاسل القتل الفتّاكة أو تطوير أسلحة الدمار الشامل | إنفاذ السياسة + إثباتات Merkle |
اختيرت هذه المجالات الثلاثة لأنها حيث يمكن أن يتسبب إجراء الوكيل في ضرر غير قابل للعكس بسحب الوصول بعد وقوعه — صفقة سيئة، أو قاطع كهربائي معطوب، أو قرار مجاور للأسلحة. وكل ما قد يفعله الوكيل بشكل خاطئ غير ذلك هو خلل برمجي؛ أما هذه فهي الفئات التي يتحول فيها الخلل إلى كارثة.
ثلاث طبقات إنفاذ تشفيرية فوق محرك السياسات v4.0/v4.1:
from core.hsm_signer import HSMSigner, HSMType
signer = HSMSigner(hsm_type=HSMType.YUBIKEY)
signature = signer.sign(decision_data, agent_id="bot-001")
from core.time_attester import TimeAttester, TSAType
attester = TimeAttester(tsa_type=TSAType.FREETSA)
token = attester.get_timestamp(decision_data)
from core.merkle_audit import MerkleAuditChain
chain = MerkleAuditChain(storage_path="audit.json")
chain.append(decision, signature=sig, tsa_token=token)