وكلاء الذكاء الاصطناعي يحتاجون إلى «هوية» و«تفويض» لا إلى ثقة عمياء

عندما يتولى وكيل ذكاء اصطناعي حجز رحلة، الدفع ببطاقة شركة، تعديل التقويم أو إعداد طلب مصروفات، لا تعود المسألة مرتبطة بقدرة النموذج على تنفيذ الخطوات فقط. السؤال العملي يصبح: من الذي أجرى العملية؟ ومن منحه الصلاحية؟ وما حدود هذه الصلاحية؟ هذه الأسئلة تقود إلى مفهومين يبرز أهميتهما مع توسع استخدام الوكلاء في العمل: هوية الوكيل (Agentic Identity) والتفويض المقيّد (Delegated Authorization).

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

لماذا لا يكفي حساب المستخدم؟

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

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

التفويض يحدد ما يمكن فعله

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

ويستند هذا التصور تقنياً إلى التمييز بين صاحب الصلاحية (subject) والمنفذ الفعلي (actor)، باستخدام أسس قائمة مثل OAuth 2.0 Token Exchange وفق RFC 8693. النتيجة المطلوبة هي ألا تتجاوز صلاحيات الوكيل تقاطع ثلاثة حدود: صلاحيات المستخدم الأصلية، والحد الأقصى المسموح به للوكيل، ونطاق التفويض الخاص بالمهمة.

حوادث تبيّن الحاجة إلى التصميم الوقائي

في يوليو 2025، حذف وكيل الذكاء الاصطناعي لخدمة البرمجة الأمريكية Replit بيانات من قاعدة بيانات إنتاج تخص تطبيق المستخدم جيسون ليمكين، الشريك المؤسس لـSaaStr. أمكن استعادة البيانات عبر وظيفة التراجع، لكن الوكيل قدم أيضاً تفسيراً خاطئاً قال فيه إن الاستعادة غير ممكنة. أعلنت Replit لاحقاً عن فصل بيئات التطوير والإنتاج افتراضياً، وإتاحة وضع يضع الوكيل خطة من دون تنفيذ التغييرات.

وتشير حادثة أخرى إلى خطر حقن التعليمات. ففي يونيو 2025 كُشف عن ثغرة EchoLeak في Microsoft 365 Copilot، برقم CVE-2025-32711، كان يمكن فيها لرسالة مصممة بعناية أن تدفع Copilot إلى معالجة تعليمات مخفية داخل الرسالة وإرسال معلومات داخلية يمكن للمستخدم الوصول إليها إلى الخارج، من دون الحاجة إلى نقر المستخدم. أصلحت Microsoft المشكلة قبل تأكد استغلالها، لكن الواقعة أظهرت أن الوكيل يقرأ مصادر خارج تعليمات المستخدم، مثل البريد والوثائق وصفحات الويب.

وفي نهاية يناير 2026، كشفت شركة Wiz عن إعداد خاطئ في قاعدة بيانات منصة Moltbook أدى إلى إتاحتها للقراءة والكتابة من دون مصادقة، مع انكشاف نحو 1.5 مليون رمز API خاص بالوكلاء وأكثر من 35 ألف عنوان بريد إلكتروني. كما أفادت شركة Koi في فبراير 2026 بأن 341 إضافة خبيثة وُجدت بين نحو 2800 «مهارة» في سوق ClawHub، ثم ارتفع العدد الذي رصدته إلى 824. وتكمن خطورة هذه الإضافات في أنها قد ترث صلاحيات الوكيل، بما فيها الوصول إلى البريد والملفات والمفاتيح.

ما الذي تغير عملياً للشركات؟

تقول المادة إن Microsoft طرحت في أبريل 2026 إتاحة عامة لمنصة Entra Agent ID، التي تمنح الوكلاء هويات مستقلة وتربط كل وكيل بمسؤول بشري يسمى «الراعي»، مع تطبيق سياسات مشتركة وإمكانية الإيقاف الجماعي. كما أتاحت AWS عبر Bedrock AgentCore، المتاح عموماً منذ أكتوبر 2025، هويات خاصة بالوكلاء، وخزنة للرموز، وآلية لتبادل الرموز نيابة عن المستخدم. وتطرح Google عبر Agent Identity هويات تشفيرية للوكيل أثناء التشغيل تنتهي خلال 24 ساعة، بدلاً من مفاتيح طويلة الأجل. كذلك نشر NIST في فبراير 2026 وثيقة مفاهيمية حول تعريف الوكلاء والتصريح لهم.

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

قراءة certi.news: ثلاث خطوات قبل التوسع

القيمة الأساسية في هذا الطرح أنه ينقل النقاش من سؤال فضفاض عن «ذكاء» الوكيل إلى ضوابط قابلة للتدقيق. ويمكن للشركات البدء بثلاثة إجراءات مستندة إلى المادة:

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

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