بروتوكول التحديد الغائي (TBP) الإصدار 4.2.1

طبقة لفرض السياسات والتدقيق التشفيري لوكلاء الذكاء الاصطناعي المستقلين.

يحجب TBP فئات محددة من إجراءات الوكيل — التحويلات المالية المستقلة، والوصول إلى أنظمة التحكم الصناعي، والتكامل مع أنظمة الأسلحة — على مستوى التنفيذ، خارج منطق النموذج نفسه. تُوقَّع القرارات (بدعم من HSM)، وتُختَم زمنيًا (RFC 3161)، وتُكتب في سلسلة تدقيق Merkle مقاومة للتلاعب. الفرضية: التعليمات داخل الأمر النصي أو رسالة النظام ليست حدودًا أمنية، لأن لا شيء يمنع وكيلًا قادرًا بما يكفي أو مُتلاعَبًا به من تجاهلها. أما الحد الذي يفرضه محرك سياسات يقع بين الوكيل والعالم الخارجي، فهو كذلك.

نشأ هذا المشروع أيضًا من جدل أوسع حول التعايش بين الذكاء الاصطناعي والبشر، طُوِّر بالتعاون مع عدة مساعدين من الذكاء الاصطناعي كشركاء في الصياغة. تعيش تلك الرؤية وقصة النشأة في philosophy/، منفصلة عن المادة التقنية أدناه حتى يمكن تقييم الهندسة بشروطها الخاصة.

المشكلة

يُوصَل الوكلاء المستقلون بحسابات تداول حقيقية، وواجهات برمجة تطبيقات بنية تحتية حقيقية، وبيانات اعتماد حقيقية، مع فرض السلامة في الغالب عبر تعليمات الأمر النصي والسلوك المدرَّب بـ RLHF. هذه مفيدة، لكنها ضوابط لينة: تتدهور تحت الضغط العدائي، والاختراقات، وقرصنة المكافآت، والأخطاء البسيطة، ولا تترك سجلًا قابلًا للتحقق تشفيريًا لما حدث.

حالة من الواقع: حادثة 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)، خطوة بخطوة:

لا شيء من هذا يعتمد على تقييم الوكلاء أنفسهم لما كان داخل النطاق — تُظهر آثار سلسلة التفكير أنهم علموا. بيت القصيد في ثابت طبقة التنفيذ أنه لا يحتاج موافقة الوكيل.

الادعاء الأوسع: لا يمكن أن تكون السلامة تعليمة تُعطى للنموذج — بل يجب أن تكون ثابتًا تنفيذيًا مفروضًا خارج حلقة استدلال النموذج.

الحل: ثوابت F/I/W

اختيرت هذه المجالات الثلاثة لأنها حيث يمكن أن يسبب إجراء الوكيل ضررًا غير قابل للعكس بإلغاء الوصول بعد وقوعه — صفقة سيئة، أو قاطع كهربائي مُقلَب، أو قرار قريب من الأسلحة. كل ما قد يفعله الوكيل بشكل خاطئ غير ذلك هو خطأ برمجي؛ أما هذه فهي الفئات التي يتحول فيها الخطأ إلى كارثة.

الجديد في v4.2.1 "Shield-Hardening"

ثلاث طبقات فرض تشفيرية فوق محرك السياسات v4.0/v4.1:

1. توقيع وحدة أمان الأجهزة (HSM) — توقيعات مدعومة بـ PKCS#11 (YubiKey، AWS CloudHSM، Azure Key Vault، SoftHSM للتطوير)، مع تحديد المعدل وحماية من إعادة التشغيل مرتبطة بمعرّف الوكيل.
   root@kitploit:~

   from core.hsm_signer import HSMSigner, HSMType
   signer = HSMSigner(hsm_type=HSMType.YUBIKEY)
   signature = signer.sign(decision_data, agent_id="bot-001")
   

2. طوابع زمنية موثوقة RFC 3161 — طوابع زمنية معتمدة خارجيًا مع تجاوز فشل متعدد TSA، بحيث لا يستطيع وكيل مخترَق تأريخ أو التلاعب بسجل وقت اتخاذ القرار.
   root@kitploit:~

   from core.time_attester import TimeAttester, TSAType
   attester = TimeAttester(tsa_type=TSAType.FREETSA)
   token = attester.get_timestamp(decision_data)
   

3. سلسلة تدقيق Merkle — تخزين سجلات مقاوم للتلاعب على نمط البلوكتشين مع إثباتات سلامة فعّالة.
   root@kitploit:~

   from core.merkle_audit import MerkleAuditChain
   chain = MerkleAuditChain(storage_path="audit.json")
   chain.append(decision, signature=sig, tsa_token=token)
   

أيضًا في هذا الإصدار: ثغرة v4.1 السابقة (نقطة اختراق واحدة في خادم OPA، CVSS 9.8) مُعالَجة — التراجع إلى توقيع البرمجيات معطَّل افتراضيًا، وحماية إعادة التشغيل مفروضة، وطُبِّقت 10 تصحيحات أمنية حُدِّدت خلال المراجعة الخارجية. راجع دليل الترحيل من v4.1 إلى v4.2.1.

الجودة: 56 اختبار وحدة (جميعها ناجحة)، تغطية 87%، محاكاة هجمات عدائية، ومعايير أداء (>1000 عملية/ثانية Merkle، >50 عملية/ثانية HSM).

البدء السريع

جرِّبه محليًا (5 دقائق)

git clone https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol.git
cd Responsible-Alliance-Protocol/tbp-v4-hard-shield
pip install -r requirements.txt
python validate_v42.py
# Expected: 20+ checks passed, READY_FOR_PRODUCTION

Docker

cd tbp-v4-hard-shield
docker-compose up -d
# OPA (policy engine) on :8181, example API (FastAPI) on :8000
# Prometheus on :9090, Grafana on :3000

مثال تكامل كامل

from core.hsm_signer import HSMSigner, HSMType
from core.time_attester import TimeAttester, TSAType
from core.merkle_audit import MerkleAuditChain
import json

signer = HSMSigner(hsm_type=HSMType.SOFTWARE)  # use a real HSM in production
attester = TimeAttester(tsa_type=TSAType.FREETSA)
chain = MerkleAuditChain(storage_path="audit.json")

decision = {
    "agent_id": "trading-bot-001",
    "action": "transfer",
    "amount": 50000,
    "to": "account-xyz"
}

data_bytes = json.dumps(decision).encode()
ts_token = attester.get_timestamp(data_bytes)
signature = signer.sign(data_bytes, agent_id=decision["agent_id"], timestamp=ts_token.timestamp.timestamp())
chain.append(decision, signature=signature.signature, timestamp=ts_token.timestamp, tsa_token=ts_token)

root = chain.get_root()
is_valid, errors = chain.verify_integrity()
assert is_valid, f"Tampering detected: {errors}"

signer.close()
attester.close()

البنية المعمارية

┌─────────────────────────────────────────────────────────┐
│                    AI Agent Decision                     │
└────────────────────┬────────────────────────────────────┘
                      │
                      ▼
         ┌───────────────────────┐
         │   Policy Evaluation   │
         │   (OPA Rego Rules)    │
         └───────────┬───────────┘
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
     ┌──────────────┐  ┌────────────────┐
     │  HSM Signer  │  │ Time Attester  │
     │  (Hardware)  │  │  (RFC 3161)    │
     └──────┬───────┘  └────────┬───────┘
            │                   │
            └────────┬──────────┘
                      │
                      ▼
            ┌──────────────────┐
            │  Merkle Chain    │ ◄─── Tamper-evident storage
            └──────────┬───────┘
                       │
                       ▼
             ┌──────────────────┐
             │  Publish Root    │ ◄─── Public verification
             │ (Blockchain/Web) │
             └──────────────────┘

خمس طبقات، كل منها قابلة للهزيمة بشكل مستقل لكن قابلة للكشف: السياسة (حجب الإجراءات غير المصرح بها) → التشفير (توقيعات غير قابلة للتزوير) → الوقت (اعتماد الطابع الزمني) → التدقيق (كشف التلاعب) → النشر (التحقق العام من الجذر).

شاهد TBP في العرض التوضيحي → invarian.fr — عرض تقني عام لسلسلة الفرض هذه (OPA، الحارس الدلالي، سجل التدقيق) يعمل على طلبات حقيقية، بنطاق مصغَّر. ليس المنتج المؤسسي النهائي؛ راجع إخلاء المسؤولية الخاص بالعرض التوضيحي لمعرفة ما يعنيه هذا التمييز عمليًا.

ما يوجد في هذا المستودع

المواصفات (V3.1)

• Architecture.md — تصميم CORE مقابل GOVERNANCE ومبرراته
• COMPLIANCE_STRESS_TEST.md — منهجية اختبار سلوكي لتدقيق ما إذا كان النظام يحترم فعلًا حدود F/I/W
• Red_team_analysis.md — أقوى الحجج ضد TBP، مفحوصة بصدق
• INVARIANT_THRESHOLDS.md — مبررات العتبات الرقمية المستخدمة في F-STABILITY

التنفيذ (V4.2.1 "Shield-Hardening")

tbp-v4-hard-shield/
├── core/
│   ├── hsm_signer.py         # Hardware-backed signatures
│   ├── time_attester.py      # RFC 3161 timestamps
│   └── merkle_audit.py       # Tamper-evident chain
├── policies/
│   └── tbp_core.rego         # OPA policy enforcement
├── integrations/
│   ├── langchain_integration.py
│   ├── fastapi_middleware.py
│   └── autogen_integration.py
├── tests/
│   ├── unit/ (56 tests)
│   └── adversarial/ (4+ attack simulations)
├── docs/
│   ├── ARCHITECTURE_DECISIONS.md  (8 ADRs)
│   ├── MIGRATION_GUIDE.md
│   └── TESTING_V4.2.md
└── deployment/
    ├── docker-compose.yml
    └── kubernetes/

التوثيق الكامل: tbp-v4-hard-shield/README.md.

امتداد الحوكمة (اختياري)

يُعرِّف tbp-governance/ آلية تجاوز طارئ مؤلمة عمدًا وقابلة للتدقيق (لجنة متعددة التوقيع من 5 أشخاص، تحليلات ما بعد الحادث الإلزامية، إغلاق تلقائي عند إساءة الاستخدام) لمجموعة صغيرة من عمليات النشر — مشغّلو البنية التحتية الحيوية بشكل أساسي — حيث يكون default deny الصارم أسوأ تشغيليًا من عملية استثناء بطيئة ومُدقَّقة. لا ينبغي لمعظم عمليات النشر استخدامه؛ راجع tbp-governance/readme.md للقائمة (الطويلة) من المتطلبات المسبقة.

الرؤية والأصول

philosophy/ — ميثاق "التحالف المسؤول" والعملية التعاونية مع الذكاء الاصطناعي التي أنتجته. اقرأ هذا للسياق حول كيفية وجود المشروع؛ واقرأ بقية هذا المستودع لتقييم ما إذا كانت آلية الفرض تعمل فعلًا.

التفاصيل التقنية

تكامل HSM (PKCS#11): YubiKey (تطوير)، AWS CloudHSM / Azure Key Vault (إنتاج)، SoftHSM (اختبار). RSA-PSS مع SHA-256، تحديد المعدل (100 عملية/دقيقة)، إبقاء الجلسة نشطة، حماية من إعادة التشغيل مرتبطة بمعرّف الوكيل.

سلطة الطابع الزمني (RFC 3161): FreeTSA، DigiCert، Sectigo، Apple، مع تجاوز الفشل، وتخزين مؤقت للاستجابات (TTL ساعة واحدة)، وكشف انحراف الوقت (<5 ثوانٍ).

سلسلة تدقيق Merkle: ربط متسلسل على نمط البلوكتشين، شجرة Merkle ثنائية لإثباتات فعّالة، تتبع نشر الجذر، تخزين JSON دائم.

قِيست على i7-الجيل العاشر، ذاكرة 16GB. توصية الإنتاج: HSM عتادي، طوابع زمنية مخزَّنة مؤقتًا، إلحاقات Merkle مُجمَّعة.

الاختبار

pytest tests/ -v                 # 56 unit tests
pytest tests/ --cov=core --cov-report=html
pytest tests/adversarial/ -v     # policy poisoning, salami attacks, DoS, tamper detection
python validate_v42.py           # automated end-to-end validation

نموذج الأمان

نموذج التهديد، والجداول الزمنية للاستجابة، وعملية الإفصاح المسؤول: راجع Security.md. أبلغ عن الثغرات عبر GitHub Security Advisories — لا تفتح مشكلة عامة لأي شيء قد يتجاوز فرض F/I/W.

النشر

Docker Compose: cd tbp-v4-hard-shield && docker-compose up -d Kubernetes: kubectl apply -f tbp-v4-hard-shield/deployment/kubernetes/ السحابة: أدلة AWS/Azure/GCP قيد الإعداد — راجع tbp-v4-hard-shield/DEPLOYMENT.md. الطرح على مستوى الشبكة: ترحيل TBP إلى شبكات المؤسسات/الويب على نطاق واسع (NAC، PEP، سجل الخلايا، المصافحة بين الكيانات) — قيد التقدم، راجع TBP-NETWORK.

المساهمة

راجع CONTRIBUTING.md. الأولويات الحالية: تكاملات الأطر (CrewAI، Semantic Kernel)، اختبارات عدائية لمتجهات هجوم جديدة، التحقق الشكلي (TLA+/Z3)، والترجمات. المشكلات المفتوحة: #7 (أدلة النشر السحابي)، #5 (ترجمات FR/ES/CN).

خارطة الطريق

v4.2.1 (الحالي): HSM، RFC 3161، تدقيق Merkle، تحليل أنماط مضاد للسلامي، تحديد المعدل. v5.0 (مخطط): التحقق الشكلي، إطار الحوكمة، أتمتة الامتثال. التفاصيل الكاملة: Roadmap.md.

الترخيص

Apache License 2.0 — راجع LICENSE.

شكر وتقدير

البشر:

• Philippe Abraxas — البنية المعمارية، توجيه المنتج
• Caetano Collet — الاختبار، التحقق، الصيانة
• Sharayu — نشر Kubernetes

التطوير بمساعدة الذكاء الاصطناعي: كُتبت وحدات موقِّع HSM، ومُعتمِد الوقت، وتدقيق Merkle بشكل جوهري بواسطة Claude (Anthropic) وDeepSeek بالتعاون مع المهندس البشري. أجرى Gemini (Google) مراجعة أمنية حدَّدت وأدَّت إلى إصلاح 10 ثغرات في تدفق التوقيع قبل v4.2.1. استُخدم Mistral وChatGPT كمنصات لتبادل الأفكار خلال التصميم. هذه هندسة بمساعدة الذكاء الاصطناعي مُنسوبة بصدق — وليست تأييدًا من Anthropic أو Google أو Mistral أو OpenAI، ولم يراجع أي منهم أو يوافق على هذا المشروع كمؤسسات.

أعمال سابقة: Open Policy Agent، RFC 3161، PKCS#11.

التواصل

• العرض التوضيحي المباشر: invarian.fr — TBP في العرض التوضيحي، نسخة تقنية عامة، نطاق مصغَّر
• المشكلات: GitHub Issues
• المناقشات: GitHub Discussions
• Discord: رابط الدعوة

@misc{tbp2026,
  title={Teleological Bounding Protocol v4.2.1: Universal Safety Invariants with Cryptographic Enforcement},
  author={Abraxas, Philippe and Collet, Caetano and Contributors},
  year={2026},
  url={https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol}
}