النقاط الرئيسية
- بُنيت إدارة الهوية والوصول لإنسان أمام متصفح يُتم التحقق بخطوتين وتسجيل الدخول الموحد — أما الوكيل المستقل الذي يحمل بيانات اعتماد دائمة ويعمل بسرعة الآلة فيكسر هذا الافتراض بشكل بنيوي، لا كحالة استثنائية.
- يشمل نموذج التهديد حسابات خدمة ذات صلاحيات مفرطة، ومفاتيح API طويلة الأجل مضمّنة في إعدادات الوكيل، وحقن تعليمات يتصاعد إلى إجراء متميز الصلاحية، وسلاسل تفويض بين الوكلاء لا يمكن عند القفزة الثالثة تتبع الشخص الذي أذن بالطلب الأصلي.
- الهويات غير البشرية (الوكلاء، حسابات الخدمة، هويات حِمل العمل) تفوق بالفعل عدد الهويات البشرية بفارق كبير في معظم بيئات المؤسسات — وهذا نمط ملاحظ على نطاق واسع في الصناعة، وليس رقمًا إحصائيًا محددًا يستشهد به هذا المقال.
- الضوابط التي تصمد: بيانات اعتماد قصيرة الأجل ودوّارة، وهوية واحدة لكل وكيل مع سجل تدقيق كامل، وموافقة بشرية مقتصرة على الإجراءات غير القابلة للتراجع، وضبط حركة البيانات الصادرة، وقوائم أدوات صريحة معتمدة.
- النموذج المستضاف ذاتيًا يزيل مخاطر التسريب إلى طرف ثالث ويُبقي البيانات داخليًا — لكنه لا يعالج حقن التعليمات، أو بيانات الاعتماد ذات الصلاحيات المفرطة، أو غياب سجل التدقيق، وهي المخاطر الأكبر.
- لا يوجد حتى الآن أي نطاق قضائي لديه قانون مخصص لهوية الذكاء الاصطناعي الوكيل — هذه حاليًا مسألة هندسية ومعمارية بالدرجة الأولى وليست مسألة امتثال، رغم أن عمليات النشر في القطاع المالي والبنية التحتية الحيوية داخل الاتحاد الأوروبي تواجه ضغطًا عمليًا حقيقيًا بسبب تداخل الأنظمة التنظيمية (انظر الملاحظات القضائية).
التحوّل من ذكاء اصطناعي يجيب إلى ذكاء اصطناعي يتصرف
صُممت إدارة الهوية والوصول حول تسلسل محدد: يجلس إنسان أمام متصفح، ويثبت هويته عبر التحقق بخطوتين أو تسجيل الدخول الموحد، وتحصل الجلسة على نطاق صلاحيات مرتبط بذلك الإثبات. يكسر وكيل الذكاء الاصطناعي (LLM) كل جزء من هذا التسلسل في آنٍ واحد — لا يوجد إنسان أمام لوحة المفاتيح لكل إجراء، ويمكن أن تعمل "الجلسة" دون إشراف لساعات أو أيام، وغالبًا ما تُحدَّد بيانات الاعتماد التي يحملها مرة واحدة عند الإعداد ولا تُراجَع بعد ذلك أبدًا.
هذه ليست نسخة أصغر من المشكلة نفسها. روبوت الدردشة الذي يجيب على الأسئلة لا يملك أي صلاحية دائمة لتغيير أي شيء. أما الوكيل الذي يقرأ تذكرة، ويكتب سجلاً في قاعدة بيانات، ويستدعي ثلاث واجهات برمجة تطبيقات داخلية، وينشر تغييرًا في الإعدادات، فهو يتخذ قرار تفويض في كل خطوة من هذه الخطوات — وأدوات إدارة الهوية المصممة للجلسات البشرية لا تملك أصلاً أي مفهوم لفكرة "هذا القرار اتخذه نموذج يستجيب لتعليمة عمرها خمس دقائق، لا شخص".
النتيجة العملية: إيقاع مراجعة الصلاحيات، وتصعيد التحقق بخطوتين عند الإجراءات الحساسة، وسجل التدقيق الذي يحدد "من فعل هذا" — والذي أمضت برامج إدارة الهوية عقدًا كاملاً في بنائه للبشر — لا يزال معظمه غير موجود للوكلاء الذين يقوم فريق المنصة بنشرهم هذا الربع.
📍 في جملة واحدة
تفترض إدارة الهوية والوصول أن إنسانًا يثبت هويته أمام متصفح قبل كل جلسة؛ والوكيل المستقل الذي يحمل بيانات اعتماد دائمة ويعمل بسرعة الآلة يكسر هذا الافتراض بشكل بنيوي، لا كحالة استثنائية.
💬 بعبارات بسيطة
صُممت إدارة الهوية للإجابة عن سؤال "هل الشخص الصحيح هو من سجّل الدخول للتو؟". وكيل الذكاء الاصطناعي لا يسجّل الدخول أبدًا كما يفعل الإنسان — بل يحمل بيانات اعتماد باستمرار ويتصرف بناءً عليها دون أن يعيد أحد التحقق، وهذا سؤال مختلف لم تُصمَّم أدوات إدارة الهوية للإجابة عنه.
نموذج التهديد بشكل ملموس
خمسة أنماط فشل تفسّر معظم التعرّض الفعلي بمجرد حصول الوكيل على صلاحية الكتابة. وهي تتراكم — فبيانات اعتماد مفرطة الصلاحيات مع سجل تدقيق غائب تحوّل حادثة قابلة للاحتواء إلى حادثة لا يمكن تتبعها.
💬 بعبارات بسيطة
معظم حوادث أمن الوكلاء ليست فشلاً واحدًا مثيرًا — بل نتيجة اجتماع بيانات اعتماد مفرطة الصلاحيات، ومفتاح ثابت، وسجل تدقيق غائب في آنٍ واحد، مما يترك مساحة لتعليمة واحدة مُحقَنة كي تتحول إلى إجراء متميز الصلاحية لا يمكن تتبعه.
- 1حسابات خدمة ذات صلاحيات مفرطة.
Why it matters: غالبًا ما يُمنح الوكيل المُعَد لتحديث حقل واحد فقط في نظام تذاكر نفس بيانات اعتماد حساب الخدمة الواسعة المستخدمة بالفعل في مكان آخر، لأن تزويده بحساب أضيق يتطلب جهدًا إضافيًا. وبذلك يحصل الوكيل على صلاحيات أوسع بكثير مما تتطلبه مهمته، ويرث كل إجراء ينفّذه نطاق التأثير الكامل لذلك الحساب. - 2مفاتيح API طويلة الأجل مضمّنة في إعدادات الوكيل.
Why it matters: المفتاح الثابت المحفوظ في ملف إعدادات أو متغير بيئة لا تنتهي صلاحيته ولا يتم تدويره — وإذا كان إطار عمل الوكيل يسجّل تعليماته الخاصة أو تسرّب المفتاح عبر نقطة تصحيح أخطاء، فلا يوجد آلية مدمجة تحدّ من نافذة الضرر كما يفعل رمز قصير الأجل. - 3حقن تعليمات يتصاعد إلى إجراء متميز الصلاحية.
Why it matters: الوكيل الذي يقرأ محتوى خارجيًا — صفحة ويب، بريدًا إلكترونيًا، تذكرة دعم، مستندًا من محرك أقراص مشترك — كجزء من مهمته قد يصادف تعليمات ضمّنها مهاجم داخل ذلك المحتوى. وإذا لم يستطع الوكيل التمييز بموثوقية بين "تعليمة من المشغّل" و"نص طُلب مني قراءته"، فقد تدفعه تعليمة مخفية في المحتوى المسترجَع إلى تنفيذ إجراء خارج النطاق المقصود — وهذه هي الآلية التي يجب على مهندس الأمن التصميم ضدها، لا حمولة يُعاد إنتاجها. - 4سلاسل تفويض بين الوكلاء دون أصل قابل للتتبع.
Why it matters: يستدعي الوكيل أ الوكيل ب، الذي يستدعي بدوره الوكيل ج لإنجاز مهمة فرعية. عند القفزة الثالثة، غالبًا ما لا تُنقل معًا بيانات الاعتماد المستخدمة، والمهمة الأصلية، والشخص الذي أذن بالطلب الأعلى مستوى — فيُظهر سجل التدقيق عند القفزة الثالثة إجراءً لا يمكن إعادة بناء سلسلته وصولاً إلى من وافق عليه. - 5سطح استدعاء الأدوات وبروتوكول MCP كسطح هجوم.
Why it matters: يوسّع بروتوكول سياق النموذج (MCP) والواجهات المشابهة لاستدعاء الأدوات، مع كل أداة جديدة تُربط، ما يمكن للوكيل الوصول إليه. كل أداة إضافية هي قدرة جديدة تغطيها الآن بيانات اعتماد الوكيل، ومكان جديد يمكن فيه لخادم أداة خبيث أو مخترق أن يعيد محتوى يعامله الوكيل كتعليمة موثوقة بدلاً من بيانات غير موثوقة.
لماذا لا تغطي إدارة الهوية الحالية هذا
صُمم تسجيل الدخول الموحد والتحقق بخطوتين لإثبات وجود إنسان لحظة الوصول — والوكيل المستقل لا يكون "موجودًا" بهذا المعنى أبدًا، لذا فإن نموذج التحقق بأكمله لا ينطبق عليه. الوكيل هو هوية غير بشرية (NHI): حساب خدمة، أو هوية حِمل عمل، أو بيانات اعتماد API تعمل باستمرار بدلاً من المصادقة مرة واحدة لكل جلسة.
تفوق الهويات غير البشرية بالفعل عدد الهويات البشرية بفارق كبير في معظم بيئات المؤسسات — وهذا نمط مُبلَّغ عنه على نطاق واسع عبر مزوّدي الأمن واستطلاعات الممارسين، وليس رقمًا واحدًا يستشهد به هذا المقال، وتتفاوت النسبة حسب المؤسسة. الثابت في هذه التقارير هو الاتجاه: نما عدد الهويات غير البشرية أسرع من عدد الموظفين البشريين لسنوات، مدفوعًا بشكل رئيسي بحسابات الخدمة والأتمتة، ويُعد الذكاء الاصطناعي الوكيل الآن الفئة الأسرع نموًا ضمن هذا الاتجاه.
لا تزال معظم برامج إدارة الهوية في المؤسسات توجّه تزويد الهويات غير البشرية عبر عملية أخف وأقل مراجعة من عملية إلحاق الموظفين البشريين — فالموظف الجديد يحصل على مراجعة صلاحيات، وموافقة من المدير، وإعادة اعتماد مجدولة؛ أما حساب الخدمة الجديد أو بيانات اعتماد الوكيل فغالبًا ما لا يحصلان على أي من هذه الخطوات الثلاث. كانت هذه الفجوة مقبولة عندما كانت الهويات غير البشرية في الغالب نصوصًا برمجية ثابتة ضيقة النطاق. لم تعد مقبولة عندما تكون الهوية غير البشرية وكيلاً قادرًا على تسلسل استدعاءات الأدوات، وتفسير تعليمات غامضة، وتنفيذ إجراءات لم يُعدِّدها مَن زوّده بها صراحة مسبقًا.
📍 في جملة واحدة
يتحقق تسجيل الدخول الموحد والتحقق بخطوتين من وجود إنسان لحظة الوصول؛ والوكيل المستقل الذي يحمل بيانات اعتماد دائمة لا يكون موجودًا بهذا المعنى أبدًا — لهذا فإن حوكمة الهوية غير البشرية، لا مصادقة بشرية أقوى، هي الفجوة الحقيقية.
حاسبة نطاق تأثير الوكيل
قيّم عملية نشر وكيل محددة عبر خمسة أبعاد للحصول على مستوى نطاق تأثير وتوصية مطابقة بأقل الامتيازات. يعمل هذا بالكامل داخل متصفحك — لا يُرسَل أي شيء.
Agent Blast-Radius Calculator
Answer 5 questions about one agent deployment to get a blast-radius risk tier and a matched least-privilege recommendation. Nothing is sent anywhere — scoring runs entirely in your browser.
1. What is the agent's capability scope?
2. What is the credential lifetime the agent uses?
3. How reversible are the agent's actions?
4. Does a human-in-the-loop approval gate exist for high-impact actions?
5. Is there an audit trail with attribution to an authorizing human?
الضوابط الفعّالة
تفسّر ستة ضوابط معظم الانخفاض الفعلي في نطاق تأثير الوكيل. لا يكفي أي منها بمفرده — بل تتراكم تمامًا كما تتراكم أنماط الفشل في نموذج التهديد.
بيانات اعتماد قصيرة الأجل ودوّارة
- ما يفعله:
- يستبدل مفاتيح API الثابتة بهوية حِمل عمل أو رموز تنتهي صلاحيتها وتتدوّر تلقائيًا.
- لماذا يصمد:
- تصبح نافذة فائدة بيانات الاعتماد المسرَّبة أو المُساء استخدامها محدودة بدلاً من غير محدودة.
هوية واحدة لكل وكيل
- ما يفعله:
- يمنح كل وكيل بيانات اعتماد خاصة به بدلاً من مشاركة حساب خدمة بين عدة وكلاء أو مع البشر.
- لماذا يصمد:
- يمكن تتبع الحادثة إلى إجراءات وكيل واحد بدلاً من مجموعة غير متمايزة، ويمكن ضبط النطاق لكل وكيل بدلاً من أدنى قاسم مشترك.
موافقة بشرية على الإجراءات غير القابلة للتراجع فقط
- ما يفعله:
- يشترط فحصًا بشريًا تحديدًا للإجراءات التي لا يمكن التراجع عنها بنظافة، لا لكل إجراء يتخذه الوكيل.
- لماذا يصمد:
- الموافقة على كل شيء تُبطل الغرض من الأتمتة وتدرّب المراجعين على النقر دون تدقيق؛ أما الاقتصار على الإجراءات غير القابلة للتراجع فيبقي الفحص ذا معنى.
ضبط حركة البيانات الصادرة
- ما يفعله:
- يحدّ على مستوى الشبكة من نقاط النهاية الخارجية التي يمكن لعملية الوكيل الوصول إليها، بغض النظر عمّا يعتقد الوكيل أن مهمته تتطلبه.
- لماذا يصمد:
- لا يمكن لوكيل مخترق أو مُتلاعَب به تسريب بيانات أو استدعاء خدمة خارجية عشوائية إذا كانت الشبكة نفسها لا تسمح بالاتصال.
قوائم الأدوات المسموح بها
- ما يفعله:
- يقيّد الوكيل بمجموعة صريحة ومُعدَّدة من الأدوات القابلة للاستدعاء بدلاً من اكتشاف أدوات مفتوح.
- لماذا يصمد:
- لا يمكن استدعاء أداة جديدة أو غير مراجَعة — حتى تلك التي تُصل إليها عبر MCP من خادم مخترق — إذا لم تكن ضمن القائمة، بغض النظر عمّا تطلبه تعليمة مُحقَنة.
التنفيذ في بيئة معزولة
- ما يفعله:
- ينفّذ إجراءات الوكيل داخل بيئة معزولة ذات حدود موارد وصلاحيات خاصة بها، منفصلة عن النظام المضيف.
- لماذا يصمد:
- يحتوي ضرر إجراء يُنفَّذ فعلاً — والهروب من البيئة المعزولة مشكلة منفصلة وأصعب من نجاح إجراء داخل بيئة مشتركة.
تسري نسبة سجل التدقيق الكاملة إلى شخص مخوّل عبر جميع الضوابط الستة أعلاه بدلاً من أن تكون بندًا منفصلاً — فبدونها، لا ينتج أي من هذه الضوابط سجلاً قابلاً للتتبع لاحقًا.
ما تحله النماذج المحلية والمستضافة ذاتيًا وما لا تحله
تشغيل نموذج الوكيل على بنية تحتية مستضافة ذاتيًا يزيل مخاطر التسريب إلى طرف ثالث ويُبقي التعليمات والمخرجات داخل شبكة المؤسسة نفسها — لكنه لا يحل مشكلة الهوية والوصول التي هي موضوع هذا المقال. سيُقلّل القارئ المُلمّ بالأمن من قيمة بقية هذا الدليل إذا تم التعتيم على هذا الفارق، لذا من المفيد ذكره بوضوح.
النشر المحلي لا يحل مشكلة حقن التعليمات. الحقن مشكلة على مستوى طبقة التطبيق والمعمارية — كيف يميّز الوكيل بين التعليمات الموثوقة والمحتوى المسترجَع غير الموثوق — وهي متطابقة سواء عمل النموذج الأساسي على واجهة برمجة تطبيقات تابعة لمزوّد أو على أجهزة تملكها المؤسسة. نقل النموذج إلى الداخل لا يغيّر شيئًا في طريقة معالجة الوكيل لصفحة ويب أو مستند طُلب منه قراءته.
النشر المحلي لا يحل مشكلة بيانات الاعتماد ذات الصلاحيات المفرطة. النموذج المستضاف ذاتيًا الذي يستدعي حساب خدمة مفرط الصلاحيات خطير تمامًا كخطورة نموذج مستضاف لدى مزوّد يستدعي الحساب نفسه — نطاق بيانات الاعتماد خاصية في تصميم وصول الوكيل، لا في مكان تشغيل أوزان النموذج.
النشر المحلي لا يحل مشكلة غياب سجل التدقيق. سواء جرى الاستدلال على واجهة برمجة تطبيقات مؤجَّرة أو على وحدة معالجة رسومات مملوكة، فذلك لا يؤثر على ما إذا كان الإجراء يُسجَّل مع نسبته إلى الشخص الذي أذن به. هذا قرار منفصل يتعلق بالتسجيل ومعمارية الهوية.
ما يفيد فيه النشر المحلي فعلاً في هذا السياق: إبقاء محتوى التعليمات ومخرجات الأدوات خارج بنية تحتية تابعة لطرف ثالث، وهو أمر مهم لإقامة البيانات ومخاطر الطرف الثالث. إنه عنصر واحد ضمن وضعية أمن الوكيل، لا بديل عن ضوابط الهوية والوصول المذكورة أعلاه.
💬 بعبارات بسيطة
تشغيل نموذجك الخاص داخليًا يحل مشكلة "تعليماتنا وبياناتنا تغادر بنيتنا التحتية". لكنه لا يحل حقن التعليمات، أو بيانات الاعتماد ذات الصلاحيات المفرطة، أو غياب سجل التدقيق — فهذه مشكلات هوية ومعمارية قائمة بالتساوي سواء عمل النموذج على واجهة برمجة تطبيقات تابعة لمزوّد أو على أجهزتك الخاصة.
ملاحظات قضائية
في المملكة العربية السعودية، لا يوجد حتى الآن قانون مخصص لهوية الوكلاء المستقلين، لكن الهيئة السعودية للبيانات والذكاء الاصطناعي (SDAIA) تشرف على تنظيم البيانات والذكاء الاصطناعي على المستوى الوطني بما في ذلك إنفاذ نظام حماية البيانات الشخصية (PDPL)، وتُصدر إرشادات أخلاقية للذكاء الاصطناعي التوليدي — وهذه الأطر تنطبق على معالجة البيانات التي يقوم بها وكيل، لكنها لا تتناول تحديدًا الهويات غير البشرية أو نطاق صلاحيات الوكيل.
في دولة الإمارات العربية المتحدة، لا يوجد حتى 2026 قانون اتحادي واحد مخصص للذكاء الاصطناعي، لكن حسب الأطر التنظيمية الخاصة بمناطق حرة معينة — وتحديدًا لائحة حماية البيانات رقم 10 لعام 2023 الصادرة عن مركز دبي المالي العالمي (DIFC) — تتناول صراحةً الأنظمة المستقلة وشبه المستقلة، وتشترط تقييمات مخاطر وآليات إشراف بشري. هذا هو التطور القضائي الأقرب لموضوع هذا المقال في المنطقة حتى الآن، لكنه يسري داخل نطاق تلك المنطقة الحرة تحديدًا وليس على مستوى الدولة اتحاديًا.
هذا القسم توجيه عام وليس استشارة قانونية — تأكد من إمكانية التطبيق على نشاطك ونوع الوكيل الذي تنشره مع مستشار قانوني مختص قبل إنهاء أي معمارية وصول.
الأسئلة الشائعة
ما هو أمن الذكاء الاصطناعي الوكيل؟
أمن الذكاء الاصطناعي الوكيل هو مجموعة ضوابط الهوية والوصول والمراقبة التي تحكم وكيل ذكاء اصطناعي مستقل يحمل بيانات اعتماد دائمة وقادر على تنفيذ إجراءات — على عكس روبوت الدردشة الذي يجيب على الأسئلة فقط. يتمحور حول معاملة كل وكيل كهوية غير بشرية لها بيانات اعتماد محدودة النطاق، وسجل تدقيق، وبوابات موافقة خاصة بها، لا كامتداد للشخص الذي أعدّه.
كيف يختلف أمن الذكاء الاصطناعي الوكيل عن إدارة الهوية والوصول التقليدية؟
تفترض إدارة الهوية التقليدية أن إنسانًا يثبت هويته عبر التحقق بخطوتين أو تسجيل الدخول الموحد قبل كل جلسة. أما الوكيل فيحمل بيانات اعتماد دائمة ويتصرف باستمرار بسرعة الآلة دون إعادة مصادقة لكل إجراء، لذا فإن افتراض وجود الإنسان الذي يقوم عليه تسجيل الدخول الموحد والتحقق بخطوتين لا ينطبق عليه — ويجب سد هذه الفجوة عبر حوكمة الهوية غير البشرية بدلاً من ذلك.
ما أكبر مخاطرة أمنية في منح وكيل ذكاء اصطناعي صلاحية الكتابة؟
اجتماع بيانات اعتماد مفرطة الصلاحيات مع غياب سجل التدقيق هو أكبر مخاطرة، لأنه يحوّل أي حادثة منفردة — حقن تعليمات، أو استدعاء أداة سيئ الإعداد، أو سلسلة تفويض — من حدث محدود وقابل للتتبع إلى حدث بنطاق تأثير غير محدود ودون أي طريقة لإعادة بناء من أذن بماذا.
كيف يؤدي حقن التعليمات إلى إجراء متميز الصلاحية؟
الوكيل الذي يقرأ محتوى خارجيًا — صفحة ويب، مستندًا، تذكرة دعم — كجزء من مهمته قد يصادف تعليمات ضمّنها مهاجم داخل ذلك المحتوى. وإذا لم يميّز بموثوقية بين "تعليمة من المشغّل" و"نص طُلب منه معالجته"، فقد تدفعه تعليمة مخفية إلى تنفيذ إجراء خارج النطاق المقصود. الحل معماري — قوائم أدوات مسموح بها، وبيانات اعتماد محدودة النطاق، وموافقة بشرية على الإجراءات غير القابلة للتراجع — وليس مجرد تحسين الصياغة.
ما هي الهوية غير البشرية (NHI) ولماذا تهم وكلاء الذكاء الاصطناعي؟
الهوية غير البشرية هي أي جهة تحمل بيانات اعتماد وليست شخصًا — حساب خدمة، أو هوية حِمل عمل، أو مفتاح API، أو وكيل ذكاء اصطناعي. تفوق الهويات غير البشرية بالفعل عدد الهويات البشرية بفارق كبير في معظم بيئات المؤسسات، وهذا نمط ملاحَظ على نطاق واسع في الصناعة، وتوجّه معظم برامج إدارة الهوية تزويد الهويات غير البشرية عبر عملية أخف من إلحاق البشر — وهي فجوة تزداد أهمية عندما تكون الهوية غير البشرية وكيلاً قادرًا على تسلسل إجراءات بمفرده.
هل يجب أن يتطلب كل إجراء للوكيل موافقة بشرية؟
لا. اشتراط الموافقة على كل إجراء يُبطل الغرض من الأتمتة ويدرّب المراجعين على النقر دون قراءة. الضابط الذي يصمد يقتصر على اشتراط الموافقة على الإجراءات غير القابلة للتراجع تحديدًا — تلك التي لا يمكن التراجع عنها بنظافة — بينما تستمر الإجراءات القابلة للتراجع منخفضة التأثير دون إشراف بشري.
هل يحل تشغيل نموذج محلي أو مستضاف ذاتيًا مخاطر أمن الذكاء الاصطناعي الوكيل؟
لا، ليس بمفرده. النموذج المستضاف ذاتيًا يزيل مخاطر التسريب إلى طرف ثالث ويُبقي البيانات داخليًا، لكنه لا يحل حقن التعليمات، أو بيانات الاعتماد ذات الصلاحيات المفرطة، أو غياب سجل التدقيق — فهذه مشكلات هوية ومعمارية قائمة بالتساوي بغض النظر عن مكان تشغيل النموذج.
ما مدة صلاحية بيانات الاعتماد التي ينبغي أن يستخدمها وكيل الذكاء الاصطناعي؟
بيانات اعتماد قصيرة الأجل تُدوَّر تلقائيًا، أو هوية حِمل عمل — لا مفتاح API ثابت طويل الأجل. المفتاح الثابت المضمّن في إعدادات الوكيل لا يملك آلية مدمجة تحدّ من نافذة الضرر عند تسريبه؛ أما بيانات الاعتماد قصيرة الأجل فتحدّ من هذه النافذة بحكم تصميمها.
كيف تخلق سلاسل التفويض بين الوكلاء مخاطرة؟
عندما يستدعي الوكيل أ الوكيل ب، الذي يستدعي بدوره الوكيل ج لإنجاز مهمة فرعية، غالبًا ما لا تُنقل معًا عبر كل قفزة بيانات الاعتماد المستخدمة، والمهمة الأصلية، والشخص الذي أذن بالطلب الأعلى مستوى. عند القفزة الثالثة، قد يُظهر سجل التدقيق إجراءً لا يمكن إعادة بناء سلسلته وصولاً إلى من وافق عليه — والحل هو تصميم سلاسل التفويض لنقل سياق التفويض صراحةً بدلاً من افتراض أنه ينتقل تلقائيًا.