النمط في التقارير
تُضبط نوافذ انتهاء الصلاحية بسخاء لتجنب الأعطال أثناء التشغيل. مهمة تستغرق أحياناً أربعين دقيقة تحصل على بيانات اعتماد صالحة لأربع وعشرين ساعة. لا شيء يلغي المنحة عند انتهاء التشغيل بشكل طبيعي، لأن الانتهاء الطبيعي لا يُعامل كحدث أمني. والنتيجة تراكم لسلطة خاملة لا يتتبعها أحد كسطح مخاطر. لا تظهر في مراجعات الوصول لأنها لم تُمنح قط كاستحقاق؛ بل تظهر في السجلات كمصادقة ناجحة من هوية عبء عمل لا تزال، تقنياً، حية.
الفشل ليس أن الوكيل خبيث. الفشل أن دورة الحياة لا تحتوي على حالة نهائية. بيانات اعتماد صادرة لمهمة ولم تُلغَ بعد المهمة ليست بيانات اعتماد مؤقتة. إنها منحة دائمة باسم مضلل.
لماذا لا يكفي انتهاء الصلاحية وحده
التشغيل الطويل بما يكفي سيحتاج دائماً إلى مسار تجديد. أي وكيل ينفذ عملاً متعدد الخطوات — جلب بيانات، استدعاء أدوات، انتظار موافقة بشرية، إعادة محاولة تبعية متذبذبة — سيتجاوز في النهاية مدة صلاحية قصيرة. ومسار التجديد هو حيث تصبح المنح دائمة بهدوء. إذا كان التجديد تلقائياً ومرتبطاً بالهوية، يجدّد الوكيل وصوله بنفسه إلى ما لا نهاية، ويصبح انتهاء الصلاحية شكلياً يولّد ضجيجاً في السجلات بدلاً من أن يكون ضابطاً.
كما أن انتهاء الصلاحية الزمني غير مرتبط بإكمال المهمة. النافذة الخطرة هي الفترة بعد النجاح، لا قبله. بيانات اعتماد تنتهي خلال ساعة آمنة إذا انتهى التشغيل في خمس دقائق وأُلغيت المنحة عند الاكتمال. وهي غير آمنة إذا انتهى التشغيل في خمس دقائق وعاشت المنحة خمساً وخمسين دقيقة أخرى. تقصير مدة الصلاحية يقلّص النافذة لكنه لا يغلقها، ويُدخل نمط فشل جديداً: تشغيلات تفشل في منتصف المهمة لأن بيانات الاعتماد انتهت صلاحيتها، مما يدفع المشغلين إلى تمديد النافذة مجدداً. يتذبذب الضابط بين الإفراط في التساهل والهشاشة المفرطة لأنه يقيس الشيء الخطأ.
آلية ملموسة تجعل الفجوة مرئية. تخيل منحة صادرة كرمز موقّع يحمل ادعاء الفاعل agent:researcher-07 ونطاق read:customer_records. للرمز exp مدته أربع وعشرون ساعة. التشغيل الذي احتاجه اكتمل في ثماني دقائق. خلال الثلاث والعشرين ساعة واثنتين وخمسين دقيقة المتبقية، أي عملية تستطيع تقديم ذلك الرمز — الوكيل نفسه، أداة مخترقة، إعادة تشغيل من سجل — لديها نفس الوصول الذي كان للتشغيل الأصلي. فاعل الرمز هو الوكيل، لا التشغيل، لذا لا يوجد ادعاء يمكن لسلطة بيانات الاعتماد استخدامه لتحديد أن العمل انتهى. الإلغاء سيتطلب تعداد الرموز حسب هوية الوكيل وتخمين أيها قديم. هذا تخمين تشغيلي، لا عقد.
حالة نهائية لكل منحة
الحل هو عقد دورة حياة لا مدة صلاحية أقصر. تُصدر كل بيانات اعتماد مقابل معرّف تشغيل وتحمل انتقالاً نهائياً إلزامياً: مكتمل، فاشل، أو متروك. معرّف التشغيل هو فاعل المنحة، لا هوية الوكيل. قد تظهر هوية الوكيل كسمة، لكنها ليست الشيء الذي ترتبط به المنحة.
المنسّق هو من يصدر الحدث النهائي. فهو يعرف بالفعل متى ينتهي التشغيل، لأنه المكوّن الذي يبدأ التشغيلات ويوقفها. عندما يصل التشغيل إلى حالة نهائية، ينشر المنسّق حدثاً — run.completed، run.failed، run.abandoned — إلى سلطة بيانات الاعتماد. تستهلك سلطة بيانات الاعتماد الحدث وتلغي كل منحة صادرة مقابل معرّف التشغيل ذلك. الإلغاء ليس مسؤولية الوكيل. وكيل ينهار أو يدخل في حلقة أو يُقتل لا يمكن الوثوق به لتنظيف ما بعد نفسه، والتصميم الذي يعتمد على تعاون الوكيل ليس ضابطاً.
التجديد منحة جديدة بمعرّف جديد وتبرير صريح. إذا احتاج تشغيل مزيداً من الوقت، يطلب المنسّق بيانات اعتماد جديدة مقابل معرّف التشغيل نفسه، وتسجّل سلطة بيانات الاعتماد الطلب مع سبب: continuation: awaiting human approval. يُظهر مسار التدقيق حينها استمراراً لا تمديداً. يرى المشغل الذي يراجع السجل سلسلة من المنح، لكل منها بداية ونهاية، بدلاً من منحة واحدة جُدّدت بهدوء. التمييز مهم لأن التمديد يخفي اللحظة التي أصبحت فيها منحة مؤقتة دائمة؛ أما الاستمرار فيجعل تلك اللحظة صريحة وقابلة للمراجعة.
المقايضة حقيقية. عقد الحالة النهائية يتطلب أن يكون المنسّق المصدر الموثوق لدورة حياة التشغيل، ويتطلب أن تكون سلطة بيانات الاعتماد قابلة للوصول عند انتهاء التشغيل. إذا مات المنسّق دون إصدار حدث نهائي، تبقى المنحة حتى تلتقطها عملية تسوية. تلك التسوية مسح يقارن المنح النشطة بالتشغيلات النشطة ويلغي الفرق. إنها أبطأ من إلغاء مدفوع بالأحداث، وتُدخل نافذة تعيش فيها المنحة أطول من تشغيلها. العقد لا يلغي النافذة؛ بل يحدّها ويجعلها قابلة للملاحظة. النظام الذي لا يتحمل حتى نافذة محدودة يحتاج معمارية مختلفة — رموز قصيرة العمر تصدر لكل خطوة، مع المنسّق كحائز وحيد — لكن لتلك المعمارية تكلفتها في زمن الاستجابة والتعقيد. عقد الحالة النهائية هو الوسط العملي:
فحوص تشغيلية
عدّد المنح الدائمة التي تحملها هويات الوكلاء وقارنها بالتشغيلات النشطة. الفرق هو التعرّض. هذا ربط بين مجموعتي بيانات تملكهما معظم الفرق بالفعل: قائمة سلطة بيانات الاعتماد بالمنح الصادرة وقائمة المنسّق بالمهام الجارية. الاستعلام ليس غريباً، لكنه نادراً ما يُنفّذ، لأن بيانات اعتماد الوكلاء غالباً ما تُعامل كبنية تحتية لا كاستحقاقات.
نبّه على المنح التي تعيش أطول من تشغيلها بأكثر من هامش محدد. الهامش قرار سياسي، لا ثابت تقني. هامش من بضع دقائق يستوعب زمن التسوية؛ وهامش من ساعات يشير إلى أن الحدث النهائي لا يُصدر أو لا يُستهلك. يجب أن ينطلق التنبيه على المنحة، لا على الوكيل، لأن الوكيل ليس وحدة الخطر. المنحة هي.
تعامل مع المنح اليتيمة كبند في مراجعة الوصول بنفس وتيرة استحقاقات البشر. إذا روجع وصول موظف بشري ربع سنوياً، فيجب مراجعة المنح الدائمة للوكيل وفق الجدول نفسه، بمتطلبات الأدلة نفسها. يجب أن تطرح المراجعة سؤالاً محدداً: بأي تشغيلات ترتبط هذه المنح، وهل تلك التشغيلات لا تزال نشطة؟ منحة لا يمكن ربطها بتشغيل نشط هي نتيجة تستدعي إجراءً، لا إنذار كاذب.
النقطة الأعمق أن بيانات اعتماد الوكلاء ليست حالة خاصة. إنها استحقاقات لها دورة حياة، ودورة الحياة تحتاج إلى حالة نهائية. انتهاء الصلاحية خاصية لبيانات الاعتماد؛ أما الإنهاء فخاصية للمنحة. الخلط بين الاثنين هو ما يحوّل تشغيلاً مكتملاً إلى منحة دائمة. الحل ليس ساعة أقصر. الحل عقد يقول: عندما ينتهي العمل، ينتهي الوصول.
ما الذي يجب قياسه أولاً
ابدأ بمعرّف التشغيل. إذا لم يكن ربط المنح بتشغيل ممكناً، فلا عقد دورة حياة ممكن. ثم أصدر الحدث النهائي من المنسّق، حتى لو لم تكن سلطة بيانات الاعتماد تستهلكه بعد، ليكون تدفق الأحداث موجوداً وقابلاً لإعادة التشغيل. ثم ابنِ عملية التسوية، لأنها الشبكة الاحتياطية لكل نمط فشل لا يغطيه مسار الأحداث. الترتيب مهم: الهوية أولاً، الأحداث ثانياً، التسوية ثالثاً. تخطي الخطوة الأولى ينتج تنبيهات لا يمكن اتخاذ إجراء بشأنها؛ وتخطي الثالثة ينتج نظاماً يكون صحيحاً فقط عندما يكون كل شيء آخر صحيحاً.