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

​
1. السجلّات الأربعة وراء مسار تدقيق وكيل الذكاء الاصطناعي

يأتي الإسناد من أربعة تيارات مستقلة، كلٌّ منها مرتبط بنفس التشغيل والجلسة كي تستطيع التنقّل بينها:

مطابقات حواجز الحماية

كل قاعدة محتوى أُطلقت على طلب أو استجابة — نوع القاعدة، والإجراء، والمرحلة، وسلسلة تفصيل. قابلة للقراءة من Member.

أحداث جدار الحماية والتشغيلات

كل حكم استدعاء أداة — allow، audit، deny، sanitize، pending_approval (تعليق للموافقة)، والحكم المحلول لقاعدة cap_cost — مجمّع حسب تشغيل الوكيل والجلسة. Developer+.

قرارات الموافقة

من وافق على أو رفض كل استدعاء أداة معلَّق، مسجَّلاً كإجراء تدقيق.

تاريخ تغيير السياسة

كل تعديل لحاجز حماية وجدار حماية — ذو إصدار، وقابل للمقارنة، وقابل للرجوع — إضافةً إلى صفّ تدقيق لمساحة العمل لكل تغيير.
النسيج الرابط هو معرّف تشغيل الوكيل والجلسة. مطابقة حاجز حماية وحدث جدار حماية من نفس المحادثة يحملان نفس نسب التشغيل، فتُقرأ “هذا التشغيل أخفى بريداً، ثم حاول جلباً رفضناه، ثم وُوفِق عليه لكتابة” كقصة واحدة بدلاً من ثلاثة سجلات منفصلة.

​
2. مطابقات حواجز الحماية — ما الذي فُحص (Member)

كل مرة تُطلق قاعدة حاجز حماية، تكتب البوابة مطابقة. تعيش التغذية على صفحة Guardrails (تبويب Matches) وقابلة للقراءة من أي عضو في مساحة العمل. كل مطابقة تسجّل نوع القاعدة، والإجراء المتّخَذ (block / mask / flag / annotate / spotlight)، والمرحلة (input / output)، وسلسلة تفصيل، ونسب التشغيل للطلب الذي حفّزها. اعرضها، جمّعها حسب حاجز الحماية أو نوع القاعدة، صفِّها حسب الإجراء، تعمّق في مطابقة واحدة، أو صدّر التغذية إلى CSV.
تُسجَّل السلسلة الفرعية المطابقة (البريد الفعلي، رقم الضمان الاجتماعي) فقط عندما يكون مفتاح Log raw content لحاجز الحماية مفعّلاً — وهو مطفأ افتراضياً، الموقف المحافظ على الخصوصية. مع إطفائه، تحصل على أن قاعدة أُطلقت وسلسلة وصفها الفوقية، لكن ليس القيمة الخام. فعّله لكل حاجز حماية حين تحتاج السلسلة الفرعية للفرز؛ الإعداد غير رجعي.
القاعدة الصاخبة جزء من المسار أيضاً. وسم مطابقة كإيجابية كاذبة بـ POST /api/guardrail/match/:id/mark-fp (Admin) كي تبقى إشارتك نظيفة ولا تفرط تقاريرك في العدّ.

​
3. أحداث جدار الحماية والتشغيلات — ماذا فعل الوكيل (Developer+)

حيث تغطّي Matches النص، تغطّي Events جدار الحماية الإجراءات. يُسجَّل كل تقييم استدعاء أداة بحكمه، وسطحه، واسم أداته، و — بشكل حاسم — تشغيل الوكيل والجلسة الذي ينتمي إليه. تتطلب القراءات على Events، وتجميع التشغيلات/الجلسات، وتتبّع كل تشغيل Developer+؛ وتغذيتا الأدوات المكتشفة والشذوذ الأخفّ مفتوحتان لكل Member. عرض Runs & sessions هو حصان العمل الجنائي: يجمّع الأحداث حسب تشغيل الوكيل في تفصيل أحكام، والأدوات والنماذج المتمايزة التي بلغها التشغيل، وطوابع أول/آخر ظهور — إجابة “ماذا فعل هذا الوكيل فعلاً” في شاشة واحدة. أبعد من الأحكام الساكنة، تعلّم تغذية الشذوذ الانحرافات عن خط أساس لساعة الأسبوع المُتعلَّم لكل مساحة عمل (متوسط متحرك على 14 يوماً) — ارتفاعات المعدل والتكلفة، وretry_loop، وانتقالات novel_path — فيظهر نمط مسموح-لكن-غير-طبيعي في السجلّ رغم ذلك.

​
4. قرارات الموافقة — من قال نعم (إجراء تدقيق)

حين تحلّ قاعدة إلى pending_approval، يصبح الاستدعاء المعلَّق مراجعةً خارج النطاق (انظر تدفّق HITL لجدار الحماية). القرار جزء من المسار: الموافقة أو الرفض يكتب صفّ تدقيق لمساحة العمل — firewall_approval_approve أو firewall_approval_reject — مسمّياً الفاعل. القرارات بمبدأ أول كاتب يفوز وعديمة الأثر التكراري، وإن تغيّرت القاعدة الأساسية بعد التعليق، يلاحظ الإثراء أن السياق تغيّر. فاستدعاء أداة عُلِّق-ثم-وُوفِق-عليه قابل للإسناد بالكامل من طرف لطرف: حدث جدار الحماية يُظهر التعليق، وصفّ التدقيق يُظهر من أطلقه، وكلاهما يرتبط بنفس التشغيل.

​
5. تدقيق تغيير السياسة — من غيّر القواعد

مسار سلوك الوكيل موثوق فقط إن استطعت أيضاً إثبات ما كانت السياسة في حينه — ومن غيّرها. تحتفظ حواجز الحماية بتاريخ إصدارات كامل. كل إنشاء وتحديث وحذف يكتب صفّ تاريخ ذي إصدار في نفس معاملة التغيير. افتح History على حاجز حماية لترى كل إصدار بمؤلّفه وطابعه الزمني، وقارن أي اثنين، وتراجع إلى أقدم (يُسجَّل التراجع كإصدار جديد — لا يُحوَّر التاريخ أبداً). تغييرات سياسة جدار الحماية وقاعدته وإعداداته يكتب كلٌّ منها صفّ تدقيق لمساحة العمل بعد أن يُثبَّت التغيير — firewall_policy_update، وfirewall_rule_create، وfirewall_settings_update، وهكذا — وتغييرات مستوى الاستقلالية (firewall_autonomy_applied / firewall_autonomy_undone) تلتقط لقطة الحالة-السابقة التي تشغّل التراجع بنقرة واحدة. لا تُسجَّل الأسرار وكتل القواعد أبداً.
يسجّل المستويان التغيير ويبقيان السياسة قابلة للرجوع. إن سبّب تعديل قاعدة انحداراً، يخبرك مسار تغيير السياسة أي تعديل ومن أجراه — وتتراجع عنه دون إعادة نشر أي شيء.

​
6. مثال معالَج: تتبّع تشغيل واحد مشتبه به

افترض أن تشغيلاً عُلِّم لاستدعاء صادر غير متوقّع. من وحدة التحكم، بجلسة Developer+:
1

افتح التشغيل في Firewall → Runs

اعثر على التشغيل بمعرّفه. يُظهر التجميع كل أداة استدعاها والحكم على كل منها — بما في ذلك deny على الأداة ذات الشكل-الجالب التي علّمته.
2

انتقل إلى الأحداث

تعمّق في الحدث المرفوض. يحمل اسم الأداة، والقاعدة والسبب المطابقين، والسطح، ونسب التشغيل/الجلسة — نفس النسب الذي ستستخدمه لمحاذاة جانب حاجز الحماية.
3

افحص ما فُحص على نفس التشغيل

افتح Guardrails → Matches وصفِّ إلى ذلك التشغيل. إن أُطلقت قاعدة Secrets Blocker أو PII على المطالبة، تعرف الآن أن الوكيل سُلِّم مادةً حساسة قبل أن يحاول تسريبها.
4

تأكّد من أن السياسة كانت نافذة

افتح History على حاجز الحماية وصفوف تدقيق سياسة جدار الحماية. تأكّد أن لا أحد أضعف القاعدة المعنية قبل التشغيل — وإن فعل، يكون لديك المؤلّف والطابع الزمني.
تشغيل واحد، أربعة سجلات مرتبطة، بلا تنقيب grep في السجلات. أما لدفاعات التسريب نفسها فانظر تسريب البيانات واستدعاءات الأدوات الخطرة.

​
7. تقارير امتثال موقَّعة — مسار يستطيع مدقّق التحقق منه

للإثبات الخارجي، يحوّل سطح الامتثال هذا المسار إلى أثر واحد. تصفّح كتالوج الأطر، والحزم، والجاهزية مفتوح لكل Member ومجاني؛ أما تثبيت حزمة، وتوليد تقرير، والانتقال للحيّ، وضبط إقامة البيانات فهي إجراءات Admin لمساحة العمل على خطة مدفوعة (مقيَّدة بالخادم). تقرير الامتثال موقَّع بـ Ed25519 مع تجزئة محتوى SHA256 وهو قابل للتحقق علناً — يفحصه المستلِم دون حساب OrcaRouter:
نقطة النهايةالغرض
GET /api/public/compliance/pubkeyالمفتاح العام للتحقق مقابله.
POST /api/public/compliance/verifyتحقّق من توقيع تقرير + تجزئته.
GET /api/public/compliance/share/:tokenرابط مشاركة-مدقّق إلى تقرير.
تُصدَّر التقارير كـ CSV / JSON / PDF. تتضمّن الأطر soc2 وhipaa وgdpr وiso_27001 وiso_42001 وnist_ai_rmf وpci_dss، وقانون الذكاء الاصطناعي الأوروبي (eu_ai_act)، وOWASP Top 10 لتطبيقات LLM (owasp_llm)، من بين أخرى — تثبيت حزمة يجسّد حواجز الحماية وسياسات جدار الحماية المطابقة كي تكون الضوابط التي تُبلّغ عنها هي الضوابط المفروضة فعلاً.
إقامة البيانات هنا هي منطقة أثر التقرير (us / eu / uk / ap / cn / global)، قابلة للضبط عبر PUT /api/compliance/residency (Admin)؛ تُحجب القراءات عبر المناطق. تحكم أين يعيش أثر الدليل — وهي ليست تثبيتاً جغرافياً لحركة استدلالك.

​
8. الاحتفاظ والحق في المحو

السجلّ الجنائي محدود، لا أبدي. تتخلّف سجلات الطلبات إلى 30 يوماً من الاحتفاظ وتُقصَّر بالخادم إلى حدّ أقصى صلب قدره 180 يوماً. حين يحذف مستخدم نفسه، تنطبق نافذة مهلة 30 يوماً، تُفرَك بعدها PII الخاصة به ويطهّر التتالي مطابقات حاجز حمايته، وسجلات طلباته، وأحداث جدار حمايته — ملبّياً التزامات الحق في المحو / DSAR مع إبقاء تاريخ التدقيق الإجمالي سليماً.

​
9. إلى أين تذهب بعد ذلك

مرجع حواجز الحماية

Matches، وتسجيل المحتوى الخام، وتاريخ الإصدارات، ومجموعة القواعد الكاملة.

مرجع جدار الحماية

Events، وRuns، والشذوذات، والموافقات، وسجلّ التدقيق.

الاستقلالية المفرطة

قيّد ما يُسمح لوكيل بفعله قبل أن يتصرّف.

أوضاع الفرض

التدقيق، والظل، وobserve — كيف تبني مساراً قبل أن تفرض.