الوكيل الخامل يظل فاعلًا أصليًا: استرداد بيانات الاعتماد كبوابة دورة حياة

الرقم المهم ليس نسبة النشاط

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

التقارير الكامنة وراء هذا التأطير تستحق القراءة مباشرة (حساب واحد، وآخر). لا يغيّر أي منهما الآلية الأساسية: الوكيل الذي لم يستدعِ أداة منذ شهور لا يزال يقدّم رمزًا صالحًا لكل خدمة لاحقة مُنح لها الوصول إليها.

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

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

لماذا تتعفن الوكلاء بشكل مختلف عن حسابات الخدمة

حساب الخدمة عادةً ما يكون بيانات اعتماد واحدة بنطاق واحد، تصدرها فريق المنصة، وتُدوَّر وفق جدول. سلطة الوكيل مركّبة، وكل عنصر منها يعمل وفق ساعته الخاصة:

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

لأن هذه تنتهي صلاحيتها بشكل مستقل، نادرًا ما تنقضي السلطة المركّبة كوحدة واحدة. مفتاح النموذج يُدوَّر، ومنحة OAuth تتجدد بصمت، وكلمة مرور قاعدة البيانات تبقى. يبدو الوكيل مُصانًا. وهو ليس كذلك: إنه مجموعة من بيانات الاعتماد في حالات تحلل مختلفة، ولا يوجد عرض واحد يُظهر الاتحاد.

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

الاسترداد كضابط مجدول

معاملة الاسترداد كمشروع تنظيف تضمن تكراره. التنظيف حدث له بداية ونهاية؛ قائمة المهام المتراكمة تمتلئ من جديد في الأسبوع التالي لإغلاقه. يجب أن يكون الضابط عملية مجدولة بنتيجة افتراضية.

الانتهاء هو الافتراضي. حدّد عتبة خمول لكل فئة وكيل — مساعدون تفاعليون، وظائف مجدولة، مستجيبون مدفوعون بالأحداث — واجعل العتبة محفزًا للتعليق التلقائي لبيانات الاعتماد، لا تذكرة ليراجعها أحد. إعادة التصريح هي الفعل الصريح؛ استمرار السلطة هو ما يتطلب تبريرًا. قيم العتبة قرار سياسة لكل مؤسسة؛ الآلية هي ما يهم.

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

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

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

سجل استرداد أدنى يبدو هكذا:

{
  "principal_id": "agent:invoice-recon-v3",
  "event": "credentials_revoked",
  "reason": "inactivity_threshold_exceeded",
  "last_successful_tool_call": "2025-01-14T09:22:07Z",
  "grants_revoked": ["oauth:ledger.read", "db:recon_rw"],
  "owner": "finance-ops",
  "policy_version": "reclamation-v4",
  "reauthorisation_path": "ticket:OPS-2214"
}

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

ما يجب قياسه

القياس المهم ليس صحة الحاوية.

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

المنح اللاحقة كعناصر جرد من الدرجة الأولى، لكل منها مالكها وانتهاء صلاحيتها، مرتبطة بالوكيل الذي يحملها. هذه هي الطريقة الوحيدة للإجابة عما يمكن للوكيل الوصول إليه دون قراءة أربعة أنظمة والتخمين.

تنبيهات الانحراف على مجموعات المنح. الفاعل الأصلي الذي تغيّرت أذوناته دون سجل تغيير مقابل إما سوء تكوين أو اختراق، والاثنان لا يمكن تمييزهما دون السجل. نبّه على الفارق، لا على النطاق المطلق.

قاعدة التصميم

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

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