الهوية الرقمية للوكلاء الأذكياء: كيف نمنح AI Agents صلاحيات آمنة دون تسليمهم مفاتيح حساباتنا؟

 الهوية الرقمية للوكلاء الأذكياء: كيف نمنح AI Agents صلاحيات آمنة دون تسليمهم مفاتيح حساباتنا؟

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

لكن هذه القدرة تفتح سؤالًا أمنيًا مهمًا: عندما ينفذ وكيل ذكاء اصطناعي مهمة بالنيابة عنك، كيف يعرف النظام من هو هذا الوكيل، وما الذي يُسمح له بفعله؟

هذه المشكلة أصبحت مهمة لدرجة أن المعهد الوطني الأمريكي للمعايير والتقنية NIST بدأ في 2026 عملًا مخصصًا لدراسة هوية وكلاء البرمجيات والذكاء الاصطناعي وآليات منحهم الصلاحيات. 

ما المقصود بالهوية الرقمية لوكيل الذكاء الاصطناعي؟

عندما تدخل أنت إلى حساب إلكتروني، يمتلك النظام وسائل للتأكد من هويتك وتحديد صلاحياتك.

أما وكيل الذكاء الاصطناعي فالوضع أكثر تعقيدًا؛ لأنه برنامج يمكن أن يعمل نيابة عن مستخدم أو مؤسسة ويتفاعل مع أنظمة أخرى.

ولهذا تتجه الفكرة إلى التعامل مع الوكيل باعتباره هوية رقمية مستقلة غير بشرية، بحيث يمكن معرفة:

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

وتشير NIST إلى أن الوكلاء يحتاجون إلى معرفات وبيانات اعتماد وصلاحيات خاصة بهم، بدل الاعتماد ببساطة على بيانات دخول المستخدم نفسه. 

لماذا لا نعطي الوكيل كلمة المرور ببساطة؟

تخيّل أنك تريد من وكيل ذكي تنظيم ملفاتك الموجودة في خدمة سحابية.

أسهل طريقة قد تبدو كالتالي: تعطيه حسابك، فيدخل وكأنه أنت.

لكن هنا تظهر المشكلة.

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

وتحذر NIST تحديدًا من مشاركة بيانات الاعتماد بين المستخدمين والوكلاء؛ لأنها تضعف القدرة على معرفة المسؤول عن العمليات التي تم تنفيذها. 

الحل: لكل وكيل هوية خاصة

بدلًا من إعطاء الوكيل مفاتيح حسابك بالكامل، يمكن تصميم الأنظمة بحيث يمتلك الوكيل هوية مستقلة.

لنفترض أنك طلبت من وكيل AI ترتيب ملفات مشروع معين.

بدل أن يحصل على إمكانية الوصول إلى كل ملفاتك، يمكن إعطاؤه تصريحًا محدودًا مثل:

اقرأ وعدّل ملفات المجلد X لمدة ساعتين فقط.

وبعد انتهاء المهمة تنتهي الصلاحية.

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

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

ماذا لو احتاج الوكيل إلى خدمة أخرى؟

هنا تصبح المسألة أكثر إثارة.

قد يبدأ الوكيل بمهمة بسيطة، ثم يكتشف أنه يحتاج إلى استخدام أداة أو خدمة أخرى لإنجازها.

على سبيل المثال:

المستخدم → الوكيل → خدمة الملفات → تطبيق آخر → قاعدة بيانات

كل انتقال يحتاج إلى إثبات أن الوكيل مخول فعلًا بالوصول إلى المورد التالي.

وهذا ما يسمى تفويض الصلاحيات Delegation.

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

ماذا يحدث إذا تعرض الوكيل للاختراق؟

هذه واحدة من أهم أسباب الحاجة إلى هوية مستقلة للوكيل.

إذا تمكن مهاجم من التأثير في وكيل يمتلك صلاحيات واسعة، فقد يحاول الوكيل تنفيذ إجراءات لم يقصدها المستخدم.

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

لذلك لا تعتمد الحماية على أن يكون نموذج الذكاء الاصطناعي “ذكيًا بما يكفي لعدم الخطأ”، وإنما على وجود ضوابط أمنية خارج النموذج نفسه.

وقد خلص تحليل نشرته NIST في 2026 إلى وجود اتفاق واسع بين المشاركين في مشاوراتها على أن وكلاء AI يخلقون تحديات أمنية جديدة، وأن مبادئ الأمن السيبراني الحالية ستحتاج إلى التكيف مع هذه الأنظمة. 

سجل لكل شيء يفعله الوكيل

وجود هوية مستقلة يجعل ميزة أخرى ممكنة: التدقيق Auditing.

يمكن للنظام الاحتفاظ بسجل يوضح مثلًا أن:

الوكيل A طلب الوصول إلى الملف B، باستخدام الصلاحية C، نيابة عن المستخدم D، ثم نفذ الإجراء E.

وهكذا تستطيع المؤسسة التحقيق في الأخطاء أو العمليات غير المتوقعة بدل رؤية نشاط مسجل بالكامل باسم المستخدم فقط.

ولهذا تضع NIST التدقيق وإمكانية ربط أفعال الوكيل بالتفويض البشري ضمن القضايا الأساسية لهوية الوكلاء. 

وهل يحتاج الوكيل إلى موافقتنا في كل مرة؟

ليس بالضرورة.

طلب الموافقة البشرية على كل خطوة قد يبدو أكثر أمانًا، لكنه يمكن أن يتحول إلى عشرات رسائل:

السماح؟

السماح؟

السماح؟

وبمرور الوقت قد يضغط المستخدم زر الموافقة دون قراءة الطلب أصلًا.

وتشير NIST إلى هذه المشكلة باسم إرهاق الموافقة Consent Fatigue، وتقارنها بمشكلة إرهاق إشعارات المصادقة متعددة العوامل. 

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

هل سنمتلك مستقبلًا “بطاقة هوية” لكل AI Agent؟

من المبكر القول كيف سيكون الشكل النهائي، لكن الاتجاه واضح بالفعل.

تعمل جهات المعايير وشركات التقنية على طرق تجعل الوكلاء كيانات يمكن التعرف عليها، والمصادقة عليها، وتحديد صلاحياتها ومراقبتها. وقد أطلقت NIST في فبراير 2026 مبادرة خاصة بمعايير وكلاء الذكاء الاصطناعي بهدف دعم عملهم بشكل آمن وقابل للتشغيل بين الأنظمة المختلفة. 

وقد نصل إلى مرحلة لا يكفي فيها أن يقول النظام:

“هذا الطلب جاء من ذكاء اصطناعي.”

بل يحتاج إلى معرفة:

أي وكيل؟ ومن سمح له؟ وما الصلاحية التي يمتلكها؟ وهل ما زالت هذه الصلاحية سارية؟

الخلاصة

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

المستقبل لن يحتاج فقط إلى حماية حسابات البشر، بل إلى إدارة ملايين الهويات غير البشرية التي تعمل نيابة عنهم.

وقد يكون أحد أهم مبادئ عصر الوكلاء الأذكياء بسيطًا جدًا:

لا تعطِ الوكيل هويتك الكاملة؛ أعطه هويته وصلاحياته وحدوده الخاصة.