وكلاء يقترضون هوية البشر: لماذا يكذب سجلّ التدقيق حين يعمل الوكيل باسمك؟
وكلاء الذكاء الاصطناعي يعملون بهوية البشر فتفقد سجلات التدقيق معناها. كيف يحلّ التفويض بدل الانتحال المشكلة، وما الخطوات العملية التي يبدأ بها فريقك؟
تخيّل أن سجلّ التدقيق في شركتك يقول: «أحمد نفّذ هذا الاستعلام الساعة الثالثة فجراً». لكن أحمد كان نائماً، والذي نفّذ الاستعلام فعلاً هو وكيل ذكاء اصطناعي يعمل بمفتاح الدخول الخاص به. هذه ليست قصة خيالية، بل هي المشكلة التي يتحدث عنها خبراء الأمن في 2026 تحت عنوان «الوكلاء الذين يقترضون بيانات اعتماد البشر». ومع انتشار الوكلاء داخل المؤسسات، صار السؤال عن «من فعل ماذا» أصعب مما يبدو.
ما المقصود بالاقتراض؟
في أغلب فرق الهندسة اليوم، يحصل الوكيل على صلاحياته بأسهل طريق: يستعير رمز OAuth الخاص بمستخدم، أو يعمل داخل جلسة المستخدم المفتوحة، أو يستخدم حساب خدمة مشتركاً. يعمل الأمر بسرعة ولا يحتاج إعداداً، لكنه يخفي حقيقة مهمة: الأنظمة التي تستقبل الطلب لا ترى وكيلاً، بل ترى إنساناً.
مثالان شائعان
- الاستعارة المباشرة: الوكيل يستخدم رمز المستخدم، فتنسب السجلات كل فعل إليه، ولا يمكن لاحقاً التمييز بين ما كتبه بيده وما نفّذه وكيله وهو غائب.
- الحساب المشترك: عدة وكلاء ومستخدمين يعملون بهوية فنية واحدة، فيظهر في السجل أن «الحساب» تحرّك، دون معرفة أي وكيل بدأ السلسلة ولصالح أي إنسان.
المشكلة ليست أن الوكيل قوي أكثر من اللازم، بل أن السجل لا يستطيع أن يقول الحقيقة عمّن فعل ماذا.
لماذا تُعدّ هذه مشكلة حقيقية؟
أولاً: التحقيق بعد الحوادث
حين تقع حادثة أمنية عبر دخول مشترك، يصعب تحديد نطاق الضرر بدقة. وعندما يتعذر الحصر، تضطر المؤسسة إلى افتراض أسوأ احتمال للتعرض، وتنطبق عليها التزامات الإبلاغ بموجب أنظمة مثل HIPAA وGDPR على الحد الأقصى المحتمل من البيانات.
ثانياً: الامتثال
كثير من ضوابط التدقيق تقوم على فكرة تمييز الفاعلين. حين يعمل وكيل بهوية إنسان، يرى بعض الكتّاب أن الضابط لا يتحقق «بروحه» حتى لو تحقق شكلياً. وهذا رأي نقاشي وليس قراراً من جهة تنظيمية، لكنه يوضح اتجاه القلق.
ثالثاً: إنكار المسؤولية
عندما تتآكل القدرة على إثبات أن شخصاً بعينه أجرى معاملة، يضعف مبدأ عدم الإنكار (non-repudiation). فيستطيع أي طرف أن يقول: «لم أكن أنا، كان الوكيل»، ولا يوجد سجل يحسم الأمر.
ماذا تقول الأرقام؟
أشار استطلاع نُسب إلى CSA وStrata في 2026 إلى أن 28% فقط من المؤسسات قادرة على تتبّع أفعال الوكلاء إلى راعٍ بشري عبر جميع بيئاتها. أي أن الغالبية لا تملك إجابة واضحة عن سؤال بسيط: من الإنسان الذي أذن بهذا الفعل؟ وفي سلاسل الوكلاء المتعددة تزداد الصورة تعقيداً، إذ قد تحمل كل حلقة هوية صالحة، لكن الرابط بين الفعل الأخير والمهمة التي أذن بها الإنسان لا يُحفظ من البداية إلى النهاية.
الحل: التفويض بدل الانتحال
الفكرة المحورية في الحلول المقترحة هي الانتقال من الانتحال (impersonation) إلى التفويض (delegation). في الانتحال يتصرف الوكيل «بصفته» المستخدم. في التفويض يتصرف «نيابةً عن» المستخدم، وتبقى هويتان منفصلتان في السجل: هوية الوكيل وهوية الإنسان المفوِّض.
| الجانب | الاستعارة | التفويض |
|---|---|---|
| ما يظهر في السجل | اسم المستخدم فقط | الوكيل والمفوِّض كحقلين منفصلين |
| مدة الصلاحية | غالباً طويلة | قصيرة ومرتبطة بالمهمة |
| نطاق الصلاحية | كل ما يملكه المستخدم | ما تحتاجه المهمة فقط |
| سهولة التحقيق | ضعيفة | عالية |
بوابة وسيطة للاعتمادات
نمط عملي آخر هو بوابة تتوسط بين الوكيل والأنظمة. تتحقق البوابة من هوية الوكيل ومن الإنسان الذي يعمل لصالحه، وتفحص الإجراء المطلوب مقابل السياسة قبل أن تصدر أي اعتماد، ثم تمنح اعتماداً قصير العمر محصوراً بالمهمة. وبهذا ينتج كل إجراء سجلاً واحداً مرتبطاً بالطلب الذي تسبب فيه.
فكرة جاهزة في المعايير
مفهوم التفويض ليس جديداً. يتضمن OAuth 2.0 تدفق «نيابةً عن» (on-behalf-of)، وهناك مسودة لدى IETF تحاول صياغته لحالة وكلاء الذكاء الاصطناعي. أي أنك لست بحاجة إلى اختراع بروتوكول جديد، بل إلى تطبيق ما هو موجود بانضباط.
خطوات عملية لفريقك
- اجرِ جرداً للوكلاء: اعرف أي وكلاء يعملون عندك وبأي اعتمادات.
- امنع إعادة استخدام رموز البشر: امنح كل وكيل هوية خاصة به.
- سجّل الحقلين معاً: معرّف الوكيل ومعرّف الإنسان المفوِّض في كل سجل تدقيق.
- قصّر عمر الاعتمادات: رموز قصيرة وبنطاق محدد للمهمة.
- ابدأ التسجيل الآن: لا يمكنك تحويل سجل قديم من انتحال إلى تفويض لاحقاً، لأن البيانات لم تُجمع أصلاً.
النقطة الأخيرة أهم ما في القائمة: الخسارة هنا لا تُعوَّض بأثر رجعي. كل يوم يعمل فيه وكيلك بهوية مستعارة هو يوم من الأدلة الناقصة.
كيف يبدو الفرق في سجل حقيقي؟
لنقارن بين سجلين لنفس الحادثة. في السجل الأول، المبني على الاستعارة، يظهر سطر واحد: المستخدم «س» قرأ ملف العملاء ثم صدّر جدول الفواتير. لا يوجد ما يدل على أن الوكيل هو من نفّذ، ولا ما يشير إلى المهمة التي طُلب منه إنجازها. أما في السجل الثاني، المبني على التفويض، فيحمل كل سطر ثلاثة عناصر: هوية الوكيل، وهوية الإنسان الذي فوّضه، ومعرّف المهمة الأصلية. حينها يستطيع فريق الأمن أن يسأل: هل كان تصدير الفواتير جزءاً من المهمة المفوَّضة أصلاً؟ فإن لم يكن، فهذا مؤشر مباشر على انحراف الوكيل أو على حقن أوامر خبيثة في مدخلاته.
هذا الفرق هو ما يحوّل السجل من أثر شكلي إلى أداة كشف فعّالة. فالتحليل الآلي يمكنه أن يقارن بين ما فُوِّض وما نُفِّذ، ويرفع تنبيهاً تلقائياً عند أي اختلاف، بدلاً من الاعتماد على حدس محقق يتصفح آلاف الأسطر بعد وقوع الضرر.
أخطاء شائعة تجنّبها
- الاكتفاء بحساب خدمة واحد لكل الوكلاء: يوفر وقت الإعداد لكنه يمحو التمييز بينهم تماماً.
- منح الوكيل صلاحيات المستخدم كاملة: الوكيل يحتاج عادةً جزءاً صغيراً منها، والباقي مخاطرة بلا فائدة.
- ترك الرموز بلا انتهاء: رمز طويل العمر مسروق يمنح المهاجم وقتاً طويلاً للعمل متنكراً.
- إهمال الوكلاء الفرعيين: حين يستدعي وكيل وكيلاً آخر، يجب أن تنتقل هوية المفوِّض الأصلي عبر السلسلة كاملة.
أسئلة شائعة
هل يعني هذا أن الوكلاء غير آمنين؟
لا. المشكلة في طريقة منحهم الصلاحيات وتسجيل أفعالهم، وليست في الوكلاء أنفسهم. التصميم الجيد للهوية يجعل استخدامهم أكثر أماناً.
هل أحتاج إلى منتج تجاري لحل المشكلة؟
ليس بالضرورة. يمكن البدء بخطوات بسيطة: هوية مستقلة لكل وكيل، وحقل إضافي في السجل للمفوِّض، وعمر قصير للرموز. المنتجات تفيد عند الحجم الكبير.
هل يكفي أن أسجّل اسم الوكيل في الرسائل؟
لا. الاسم النصي سهل التزوير أو الإهمال. المطلوب أن تكون الهوية جزءاً من الاعتماد نفسه الذي تتحقق منه الأنظمة، لا ملاحظة جانبية.
الخلاصة
حين يعمل الوكيل بهوية إنسان، يصبح سجل التدقيق قصة ناقصة. الحل العملي هو التفويض: هوية للوكيل، وهوية للإنسان، واعتماد قصير العمر محدد بالمهمة، وسجل واحد لكل فعل. ابدأ بتسجيل الحقلين اليوم، فهذا أرخص استثمار يحميك من ليلة تحقيق لا تجد فيها من تسأل.
المصادر: Kiteworks، CIO، TianPan.co، iProov
