وكيل الذكاء الاصطناعي يحتاج إلى هوية لا إلى مفتاح مشترك

يتغير معنى «هوية النظام» عندما ينتقل الذكاء الاصطناعي من تقديم إجابة إلى تنفيذ إجراء. فالوكيل الذي يقرأ عقداً، أو يعدّل تذكرة دعم، أو يوافق على استرداد مبلغ، لا يحتاج فقط إلى نموذج جيد؛ بل يحتاج إلى تفويض واضح يجيب عن سؤالين: من كلّفه؟ وما الحد الذي لا يجوز له تجاوزه؟

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

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

لكل وكيل بطاقة عمل رقمية

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

توضح وثائق Microsoft Learn بالعربية، المحدثة في 30 يوليو 2026 أن إدارة هوية الوكيل يجب أن تشمل دورة حياته وملكيته وصلاحياته، مع تطبيق مبادئ الثقة الصفرية والوصول الأقل امتيازاً. المعنى العملي: لا تبقى صلاحية الوكيل أطول من الحاجة، ولا يحصل على مورد لمجرد أنه متصل بالشبكة نفسها.

هوية المستخدم يجب ألا تضيع في الطريق

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

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

وتبين صفحة AWS العربية المنشورة في 24 أبريل 2026 كيف يمكن لهوية AgentCore التحقق من رموز الوصول الواردة وجلب رموز للمصادقة على الطلبات الصادرة، بما في ذلك الاتصال بمزوّدي هوية داخل شبكة خاصة. الفكرة أوسع من منتج بعينه: مرّر تفويضاً محدوداً، ولا تمرّر سراً دائماً.

من صلاحية الأداة إلى صلاحية الإجراء

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

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

لا تجعل النموذج جهة إصدار القرار الأمني

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

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

سجل يربط الإنسان بالوكيل والنتيجة

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

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

خطة تنفيذية للفرق في الإمارات والخليج

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

رؤية قمرة تك

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

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