ما تصفه التقارير فعلاً
عندما يصل وكيل إلى نقطة نهاية حكومية أو واجهة برمجية مؤسسية دون أن يصدر إنسان التعليمات في تلك اللحظة، تكون القصة التي تلي عادةً عن النموذج. مختبر، رقم إصدار، عتبة قدرة. هذا التأطير مقروء وينتشر بسهولة، لكنه يجيب عن سؤال لا يحتاج المستجيبون للحوادث إجابته فعلاً. السؤال الذي يحدد ما يحدث بعد ذلك أضيق: أي بيانات اعتماد قُدِّمت، وما النطاق الذي حملته، وعبر أي سلسلة تفويض وصلت إلى نقطة النهاية تلك.
تصف عدة تقارير حديثة وكلاء يتفاعلون مع أنظمة خارجية بطرق لم يأمر بها المشغّل مباشرة في ذلك الوقت. تختلف التفاصيل، لكن الشكل ثابت: عملية مستقلة أو شبه مستقلة صاغت طلباً، وقُبل الطلب لأن بيانات اعتماد صالحة أذنت به. النموذج أنتج النية. وبيانات الاعتماد أنتجت الوصول. واحد فقط من هذين قابل للإلغاء في الدقائق العشر التالية.
الإسناد هنا ليس تمريناً فلسفياً حول الفاعلية. إنه سؤال نموذج بيانات. من تصرّف، وباسم من، وبأي منحة، وفي أي خطوة من التشغيل. إذا كان نظامك قادراً على الإجابة عن ذلك كاستعلام، فالحادث حدث تشغيلي محدود. وإذا لم يكن قادراً، يصبح الحادث مشروعاً جنائياً يُجرى تحت ضغط الوقت، والجواب الذي تنتجه في النهاية سيكون استنتاجاً لا سجلاً.
لماذا سلسلة التفويض مفقودة
السبب في أن معظم المنظومات لا تستطيع إعادة بناء السلسلة هو أنها لم تُصمم يوماً لتحمل واحدة. ثلاث أنماط تفسر معظم الفجوة.
أولاً، بيانات الاعتماد مُنطَّقة على خدمة لا على مهمة. يُمنح الوكيل رمزاً أو مفتاحاً بالصلاحيات التي يحتاجها التكامل، وتبقى هذه المنحة قائمة عبر كل تشغيل يقوم به الوكيل. التفويض يعيش أطول من النية التي بررته. منحة مُنحت ليقرأ الوكيل تقويماً لمهمة جدولة تظل صالحة بعد ستة أشهر عندما يفعل الوكيل نفسه شيئاً مختلفاً تماماً، لأن لا شيء في بيانات الاعتماد يرمّز المهمة.
ثانياً، القفزات الوسيطة تعيد استخدام بيانات اعتماد الأصل بدلاً من تضعيفها. ينتج المخطِّط وكيلاً فرعياً. يستدعي الوكيل الفرعي وسيط أدوات. يستدعي الوسيط نقطة نهاية طرف ثالث. عند كل قفزة، ينتقل الرمز الحامل نفسه إلى الأمام دون تغيير. يملك الوكيل الفرعي بالضبط سلطة الأصل الجذري، حتى لو كانت مهمته الفعلية تتطلب جزءاً منها. هذا مريح، وهو أكبر مساهم منفرد في نطاق التأثير في أنظمة الوكلاء.
ثالثاً، السجلات تسجل الطلب، لا سلسلة الحيازة التي أنتجته. يُظهر سجل الوصول أن طلباً وصل برمز صالح في طابع زمني معين. لا يُظهر أي خطوة تخطيط أنتجت النية، أو أي وكيل فرعي نفذها، أو أي مهمة انتمى إليها التسلسل كله. لذلك يعتمد إعادة البناء اللاحق على ربط الطوابع الزمنية ومعرّفات الجلسات عبر أنظمة لم تُصمم يوماً لتُوصل ببعضها. ذلك الربط استنتاج. والاستنتاج جيد لتشريح ما بعد الحادث، وغير مجدٍ للإلغاء.
سجل إسناد الحد الأدنى القابل للتطبيق
الحل ليس ترقية تسجيل. إنه تغيير في ما يحمله الإجراء الصادر وأين يُكتب السجل.
يجب أن يحمل كل إجراء صادر أربعة حقول على الأقل:
- الأصل — الهوية التي تُتخذ الإجراء بسلطتها، قابلة للحل إلى حساب حقيقي أو هوية خدمة
- معرّف المهمة — معرّف ثابت لوحدة العمل التي يخدمها الإجراء، لا الجلسة ولا العملية
- معرّف الخطوة الأصل — الخطوة التي أنتجت هذا الإجراء، لتكون السلسلة بنية مترابطة لا قائمة مسطحة
- النطاق المُمارَس فعلاً — الصلاحية المحددة التي استهلكها الإجراء، معبَّراً عنها بنفس المفردات التي تتحقق بها نقطة الإنفاذ
هذه الحقول الأربعة كافية لإعادة بناء رسم بياني موجّه من أي إجراء إلى أصله الجذري، ومن أي أصل إلى كل إجراء اتُّخذ تحت سلطته.
الآلية التي تجعل هذا يعمل هي تضعيف النطاق عند كل قفزة. عند إنتاج وكيل فرعي، يتلقى منحة هي مجموعة فرعية صارمة من سلطة مستدعيه — لا مجموعة شاملة، ولا مجموعة مساوية إلا إذا كانت المهمة تتطلب السلطة الكاملة فعلاً وهذا الشرط صريح. يُنفَّذ التضعيف عند الحدود التي يُنشأ فيها الابن، لا يُدَّعى من الابن. وسيط الأدوات الذي يتلقى طلباً يقدّم منحته المخففة الخاصة، لا رمز المستدعي.
الآلية الثانية هي أين يُكتب السجل. يجب إصدار بيانات الإسناد عند نقطة الإنفاذ — المكان الذي يقرر فعلاً ما إذا كان الطلب يمضي — لا تجميعها لاحقاً من سجلات التطبيق. سجلات التطبيق يكتبها كود قد يكون معطوباً أو متجاوزاً أو غائباً ببساطة في بعض المسارات. نقطة الإنفاذ ترى كل طلب بحكم التعريف، وهي تعرف بالفعل النطاق الذي تحققت منه. كتابة الأصل ومعرّف المهمة ومعرّف الخطوة الأصل والنطاق ال
{ "principal": "svc:reporting-agent",
"task_id": "tsk_8f21",
"parent_step": "stp_04",
"scope": "calendar.read",
"target": "external.example.gov",
"decision": "allow" }
سجل كهذا ليس سطر تسجيل بالمعنى التقليدي. إنه حافة في رسم بياني، ويكتبه المكوّن الذي كان يملك سلطة الرفض.
نتائج التصميم
بمجرد وجود السلسلة، تتغير طبيعة الاستجابة للحوادث. يصبح سؤال "ماذا فعل الوكيل" اجتيازاً: ابدأ من الأصل، امشِ للأمام إلى المهمة، امشِ للأمام إلى كل خطوة، اسرد كل نقطة نهاية لُمست. ويصبح سؤال "كيف وصل إلى هناك" مشياً للخلف من نقطة النهاية إلى المنحة الجذرية. كلاهما استعلامات على بنية تحتفظ بها بالفعل، لا تحقيقات تجريها بعد وقوع الأمر.
يصبح الإلغاء مناطاً بمهمة لا بحساب خدمة. إذا أساءت مهمة واحدة التصرف، تلغي المنح الصادرة لتلك المهمة وكل ما هو تابع لها. يستمر باقي عمل الوكيل. هذا هو الفرق بين احتواء حادث وتعطيل قدرة. وهو أيضاً الفرق بين إلغاء يسري في ثوانٍ وإلغاء يتطلب تدقيق كل تكامل يلمسه حساب الخدمة قبل أن تجرؤ على إيقافه.
تحصل حجج المسؤولية على أساس واقعي. عندما يُنازع على إجراء، تُظهر السلسلة ما أُذن به — النطاق الذي مُنح، والخطوة التي مارسته، والأصل الذي وقف خلفه. هذا نوع مختلف من الادعاء عن ما يؤكده بائع حول سلوك النموذج، وهو قابل للتحقق من الطرفين.
المقايضة الصادقة هي أن التضعيف والسجلات لكل إجراء يكلفان جهداً هندسياً ويُدخلان احتكاكاً. يجب على كل قفزة التفاوض على منحة أضيق، ما يعني أن المكونات التي تنتج وكلاء فرعيين تحتاج إلى معرفة ما سيحتاجه الوكيل الفرعي قبل تشغيله. هذا قيد تصميمي، وهو أصعب فعلاً من تمرير رمز. وهناك أيضاً تكلفة أداء وتخزين حقيقية لكتابة سجل حافة عند كل نقطة إنفاذ بدلاً من أخذ عينات من السجلات. لحركة الوكلاء عالية الحجم، يتناسب حجم السجل مع حجم الإجراءات، وهذا ليس مجانياً.
الحجة المضادة هي أن التكلفة تُدفع مرة واحدة، في التصميم، والبديل يُدفع مراراً، في كل حادث، تحت ظروف أسوأ. النظام الذي لا يستطيع إعادة بناء سلسلة تفويضه لا يواجه مشكلة إسناد أثناء التشغيل العادي. إنه يواجهها في اللحظة التي يسأل فيها أحدهم سؤالاً لا يستطيع الإجابة عنه، وهي بالضبط اللحظة التي تكون فيها الإجابة أهم ما يكون.
الإسناد ليس ميزة أمان مثبتة على منظومة وكلاء. إنه خاصية لكيفية نمذجة السلطة ونشرها. أحسِن نموذج البيانات وستجد محادثة الأمان شيئاً ملموساً تستند إليه. أخطئ فيه وسيصبح كل تقرير حادث جدالاً حول النموذج، لأن السلسلة التي كانت ستحسم السؤال لم تُكتب يوماً.