الوكلاء يتحولون إلى عبء عمل في IAM، وحسابات الخدمة لديك غير جاهزة

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

لكن هذا هو موضع توقف ذلك النهج عن العمل. حساب الخدمة يجيب عن سؤال: "أي نظام هو الذي يجري الاتصال؟" أما الوكيل فيفرض سؤالًا أصعب: "أي وكيل هو الذي يجري الاتصال، نيابة عن من، ولتحقيق أي هدف، ومن يستطيع إلغاء صلاحيته خلال الثلاثين ثانية المقبلة؟" تشير أرقام قطاع IAM نفسه إلى أن الهويات غير البشرية باتت تفوق الهويات البشرية بنحو مرتبة عشرية، كما حذر تقرير Verizon DBIR لعام 2026 من أن حسابات الخدمة والآلات هي التي ينبغي مراقبتها مع وصول الذكاء الاصطناعي الوكيلي، وفق قراءة Token Security للتقرير. هذه إحاطة تشرح لماذا يفشل هذا الإسقاط، وما الذي يُبنى لاستبداله، وكيف تبدو حالات الفشل بالفعل.

الخلاصات الرئيسية - تفترض حسابات الخدمة ومفاتيح API وجود جهة اتصال مستقرة وحتمية. الوكلاء مؤقتون وغير حتميين ويفوض بعضهم بعضًا، ما يكسر افتراضات التدقيق والإلغاء وأقل قدر من الصلاحيات المضمنة في بيانات الاعتماد المشتركة. - يتجه مسار المعايير نحو هوية عبء عمل منفصلة لكل وكيل: هناك ضغط على مجموعة عمل IETF WIMSE لفرض إمكانية التمييز بين الوكلاء بالهوية، لا بمجال الرمز فقط، باستخدام معرّفات لكل وكيل على نمط SPIFFE للسياسة والتدقيق والإلغاء. - الحوادث أصبحت ملموسة بالفعل: استُخدمت رموز OAuth مخترقة في منظومة Salesloft Drift للانتقال إلى بيئات Salesforce مؤسسية، كما نُفذ اختراق Hugging Face في يوليو بواسطة وكيل مستقل من البداية إلى النهاية. - تتقارب إرشادات التنفيذ: هوية مخصصة لكل وكيل، وبيانات اعتماد قصيرة العمر ومحددة بنطاق المهمة تصدر خارج سياق النموذج، ومسارات تدقيق ترتبط بالوكيل نفسه لا بالدور المشترك. - إذا كان وكلاؤك يصادقون جميعًا باستخدام حساب خدمة مشترك واحد، فلن تتمكن سجلاتك من إخبارك أي وكيل فعل ماذا. هذا هو الاختبار الذي ينبغي تطبيقه هذا الأسبوع.

ما الذي حدث

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

ثانيًا، استمر إيقاع الحوادث. كان اختراق Hugging Face في منتصف يوليو أول اختراق معلن لشركة معروفة ينفذه وكيل مستقل من البداية إلى النهاية: تنفيذ شيفرة في خط بيانات مجموعات البيانات، وجمع بيانات الاعتماد، والحركة الجانبية عبر العناقيد الداخلية، وآلاف الإجراءات خلال عطلة نهاية أسبوع واحدة. وفي وقت سابق من العام، سرب Moltbook، وهو شبكة اجتماعية لوكلاء الذكاء الاصطناعي، 1.5 مليون رمز API من قاعدة بيانات سيئة الإعداد بعد أيام من وصوله إلى 1.5 مليون حساب وكيل، وفق ملخص Studio Global. كما أن المثال المتكرر في DBIR لهجمات الهوية غير البشرية، وهو اختراق رموز OAuth الخاصة بـ Salesloft Drift واستخدامها للوصول إلى بيئات Salesforce في مؤسسات كبرى من بينها Google وCisco وZscaler، يماثل تمامًا نوع بيانات الاعتماد التي يعتمد عليها الوكلاء.

في أغسطس 2026، اقترحت مشكلة في IETF WIMSE أن تكون أفعال الوكلاء قابلة للتمييز عبر هويات أعباء عمل منفصلة، لا عبر نطاقات الرموز، وأن تُستخدم معرّفات لكل وكيل كمفتاح ثابت للسياسة والتدقيق والإلغاء. جاء ذلك بعد اختراق Hugging Face الذي نفذه وكيل في يوليو، وحادثة يناير التي سربت فيها منصة Moltbook للوكلاء 1.5 مليون رمز API.

لماذا لا تتوافق حسابات الخدمة ومفاتيح API مع الوكلاء

لعدم التوافق هذا أربعة جوانب، ومن المفيد تسميتها كل على حدة لأن حلولها تختلف.

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

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

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

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

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

ما الذي يبنيه الموردون وهيئات المعايير

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

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

اتحاد الهوية بدل الأسرار المخزنة. يوضح شرح Descope لاتحاد هوية عبء العمل للوكلاء النمط: تُستبدل هوية منصة الوكيل، مثل دور AWS IAM أو حساب خدمة Kubernetes عبر IRSA، برمز قصير العمر ومحدد النطاق من منصة الهوية، التي تنشئ أيضًا سجل دليل للوكيل كي تبقى مسارات التدقيق بعد انتهاء عمر الرمز. لا يوجد مفتاح طويل العمر يمكن تسريبه، وسجل الهوية يعيش أطول من أي بيانات اعتماد منفردة.

الاكتشاف والحوكمة كسوق. تجاريًا، تعيد شركات الهوية غير البشرية مثل Reco وToken Security وOasis وAembit وغيرها تموضعها حول الوكلاء: اكتشاف كل بيانات اعتماد الوكلاء، وربطها بمالك، والتنبيه إلى الإفراط في الصلاحيات، وإلغاء الوصول بشكل نظيف. صياغة Reco عملية: طابق نوع الهوية مع دور الوكيل، بحيث يُستخدم OAuth المفوض لأفعال المستخدم وهوية عبء عمل مخصصة للأفعال المستقلة، وراجع الصلاحيات مع توسع المسؤوليات لأن الوكلاء يراكمون الامتيازات كما يراكم الموظفون مفاتيح المبنى. وقد وضع OWASP في قائمة Top 10 for Agentic Applications المنشورة في ديسمبر 2025 خطر إساءة استخدام الهوية والامتيازات كفئة من الدرجة الأولى، ما يمنح فرق الأمن مفردات مشتركة لنتائج التدقيق. أما موضع هذه الطبقة في بقية بنيتك فهو سؤال حوكمة بقدر ما هو سؤال أدوات، وأتناول الجانب التنظيمي في حوكمة وكلاء الذكاء الاصطناعي.

المعمارية الناشئة: هويات أعباء عمل لكل وكيل، بمعرّفات على نمط SPIFFE تُستخدم للسياسة والتدقيق والإلغاء وفق نقاش WIMSE، واتحاد هوية المنصة إلى رموز قصيرة العمر ومحددة النطاق مع سجلات دليل دائمة للوكلاء وفق Descope، وسوق موردين لاكتشاف الهويات غير البشرية وحوكمتها وفق مبدأ أقل قدر من الصلاحيات.

عندما تفشل هوية الوكيل

ثلاث حوادث، وثلاثة أنماط فشل مختلفة، وكلها تستحق الدراسة.

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

Salesloft Drift، قصة DBIR التحذيرية: الرموز كمفاتيح شاملة. استُخدمت رموز OAuth مخترقة من منظومة أحد الموردين للانتقال إلى بيئات Salesforce لدى مؤسسات كبرى. لا كلمات مرور ولا تصيد لبشر: بيانات اعتماد غير بشرية، موثوقة على نطاق واسع، وأعيد استخدامها في صمت. كل وكيل تربطه بأداة SaaS عبر منحة OAuth طويلة العمر يحمل هذا الشكل من المخاطر، والحل يحمل الشكل نفسه أيضًا: قصير العمر، ضيق النطاق، خاص بكل وكيل، وقابل للإلغاء.

Moltbook، يناير 2026: منصات الوكلاء تجمع مخاطر الهوية في مكان واحد. سربت منصة لحسابات الوكلاء 1.5 مليون رمز API إلى جانب عناوين بريد إلكتروني ورسائل بين الوكلاء من قاعدة بيانات سيئة الإعداد، وفق رواية Studio Global. عندما تركز هوية الوكلاء، فإنك تركز أيضًا نطاق الضرر المحتمل. ومن المهم القول إنني سأتعامل مع بعض تفاصيل الحادث المتداولة باعتبارها تقارير لا حقائق مدققة: إفصاح Hugging Face نفسه مصدر أولي، أما أرقام Moltbook فتأتي من تغطية ثانوية.

تشمل حالات الفشل الموثقة في هوية الوكلاء اختراق Hugging Face في يوليو 2026، حيث حصد وكيل مستقل بيانات اعتماد السحابة والعناقيد وتحرك جانبيًا وفق تحليل Waxell، وانتقال رموز OAuth الخاصة بـ Salesloft Drift إلى مستأجري Salesforce مؤسسيين وفق Token Security عن DBIR 2026، وتسريب Moltbook لـ 1.5 مليون رمز API للوكلاء.

ما الذي ينبغي فعله الآن

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

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

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

الأسئلة الشائعة

ما المقصود بهوية الوكيل من منظور IAM؟

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

لماذا لا يمكن للوكلاء مشاركة حساب خدمة ببساطة؟

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

ماذا تفعل هيئات المعايير بشأن هوية الوكيل؟

تعمل مجموعة IETF WIMSE على توسيع معمارية هوية عبء العمل لتشمل الوسطاء المعتمدين على الذكاء الاصطناعي، مع اقتراح نشط لفرض معرّفات لكل وكيل، وتُقترح SPIFFE URIs كآلية، بدل الاعتماد على نطاقات الرموز. ونشر OWASP قائمة Top 10 for Agentic Applications في ديسمبر 2025 وجعل إساءة استخدام الهوية والامتيازات فئة مسماة، كما لدى Cloud Security Alliance إطار لحوكمة هوية الوكلاء يوصي بهوية فريدة لكل وكيل.

هل ينبغي أن تظهر بيانات اعتماد الوكيل في سياق النموذج؟

لا. أي شيء داخل نافذة السياق مرئي للنموذج ويمكن تسريبه بواسطة حقن التعليمات. النمط المقبول هو إصدار بيانات الاعتماد وقت المهمة من خدمة رموز، والاحتفاظ بها في طبقة تنفيذ الأدوات بين النموذج وواجهة API، مع تضييق نطاقها للمهمة وجعلها قصيرة العمر. النموذج يطلب الفعل، والـ harness يحتفظ بالسر.

الخلاصة

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

إذا كنت تربط هوية الوكلاء ببنية IAM قائمة وتريد ممارسًا في الغرفة، فهذا من نوع العمل الذي أقوم به. تواصل معي.

المصادر

• IETF WIMSE WG، المسألة #139 في draft-ietf-wimse-arch، "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (قُدمت 2026-08-04، تم الاطلاع 2026-08-29)

• Cockroach Labs، "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (نُشر 2026-07-17، تم الاطلاع 2026-08-29)

• Token Security، "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (نُشر 2026-05-20، تم الاطلاع 2026-08-29)

• Descope، "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (نُشر 2026-06-22، تم الاطلاع 2026-08-29)

• miniOrange، "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (نُشر 2026-05-20، تم الاطلاع 2026-08-29)

• Reco، "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (نُشر 2026-07-20، تم الاطلاع 2026-08-29)

• Waxell، "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (نُشر 2026-07-17، تم الاطلاع 2026-08-29)

• Studio Global، "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (نُشر 2026-08-17، تم الاطلاع 2026-08-29)