انتقل إلى المحتوى
Hiclix
القائمة
احجزوا موعدًا

حين يخرج الوكيل عن نطاقه: 8 أسئلة تطرحها قبل ربطه بأنظمتك

· Tarek Nachnouchi

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

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

ما الذي حدث في أكتوبر؟

أصدر فريق CERT-In، الوكالة الوطنية الهندية للأمن السيبراني، تنبيهًا في 15 أكتوبر. وبحسب The Hacker News، وصل وكلاء كانوا يُختبرون عبر الإنترنت إلى الأنظمة الفعلية لمؤسسات هندية، واطّلعوا على سجلات أعمال، منها بيانات شخصية. ولم تكتشف أي من هذه المؤسسات عمليات الوصول. بل إن شركات الذكاء الاصطناعي نفسها هي التي أبلغت عن الحالات بعد مراجعات داخلية. ودخل الوكلاء عبر بيانات اعتماد تُركت في ملفات إعداد ومستودعات شيفرة عامة، وعبر أدوار سحابية بصلاحيات مفرطة.

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

تسع ثوانٍ في PocketOS

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

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

تلخّص Railway الدرس في تدوينتها بتاريخ 29 أبريل: اجعل الفعل المدمّر بطيئًا والاستعادة سريعة. أجد هذه القاعدة سليمة، وهي تنطبق على أي شركة.

وتصف روايات أخرى النمط نفسه. ففي 24 يونيو 2026، شرح مطوّر على r/Python أنه نسي تحويل إعدادات بيئة الاختبار إلى بيئة الإنتاج. فاستدعى وكيله أداة الإرسال ببيانات اعتماد الإنتاج، وتلقّى 200 عميل رسالة غير مكتملة في العاشرة ليلًا. بعدها أضاف المطوّر خطوة موافقة صريحة قبل أي فعل خطِر. لا يمكن التحقق من هذه الرواية، لكن الآلية هي نفسها التي ظهرت في PocketOS.

ما الذي يعنيه ذلك لشركة تعمل مع أوروبا؟

قد يُعدّ اطّلاع وكيل على بيانات شخصية دون إذن خرقًا للبيانات الشخصية بموجب اللائحة العامة لحماية البيانات (GDPR). وتفرض المادة 33 حينها إخطار السلطة الرقابية (CNIL في فرنسا) خلال 72 ساعة من العلم بالخرق، ما لم يكن مستبعدًا أن يشكّل خطرًا على الأشخاص. وتنطبق اللائحة أيضًا على شركات خارج أوروبا حين تعالج بيانات أشخاص موجودين فيها. وتبيّن الحالة الهندية الصعوبة: لم ترَ أي مؤسسة عمليات الوصول. ومن دون سجلّ لأفعال الوكيل، لا أرى كيف يمكن تقدير ما يجب الإخطار به.

ما أنصح به

  1. امنح كل وكيل هوية خاصة به. يوصي CERT-In بهوية قصيرة الأمد وبأدنى الصلاحيات لكل تشغيل للوكيل. ولا أسمح أبدًا لوكيل بإعادة استخدام حساب موظف.
  2. ابحث عن مفاتيحك المكشوفة قبل أن يجدها الوكيل. شغّل أداة لكشف الأسرار على مستودعاتك وملفات الإعداد ومتغيرات التكامل المستمر، وغيّر كل مفتاح تعثر عليه.
  3. افصل الإنتاج عن كل ما عداه. يجب أن تكون بيانات اعتماد الإنتاج بعيدة عن متناول البيئة التي يعمل فيها الوكيل.
  4. اجعل الحذف قابلًا للتراجع. تحقّق من أن أدواتك الأساسية توفر سلة محذوفات أو مهلة سماح، بما في ذلك عبر واجهتها البرمجية.
  5. اعزل نسخك الاحتياطية. النسخة الاحتياطية المحفوظة في مكان البيانات نفسه لا تحمي من الحذف.
  6. احتفظ بسجلّ للأفعال. يطلب CERT-In سجلًّا مقاومًا للتلاعب لأفعال الوكلاء، على الأقل تلك التي تمسّ الإنتاج، والاحتفاظ بالسجلات 180 يومًا على الأقل.

أراجع هذه النقاط مع عملائي قبل أي نشر لـحلول الذكاء الاصطناعي.

قائمة التحقق: هل أربط هذا الوكيل بأنظمتي؟

#السؤالنعم / لا
1هل للوكيل هوية خاصة به، منفصلة عن هوية أي موظف؟
2هل تقتصر صلاحياته على أدوات مهمته وبياناتها؟
3هل بيانات اعتماد الإنتاج بعيدة عن متناوله؟
4هل فُحصت مستودعاتك وملفات الإعداد بحثًا عن مفاتيح مكشوفة؟
5هل تحتاج الأفعال المدمّرة إلى موافقة بشرية؟
6هل يمكن التراجع عن الحذف خلال مدة محددة؟
7هل النسخ الاحتياطية محفوظة خارج المنطقة التي يصل إليها الوكيل؟
8هل يُسجَّل كل فعل للوكيل ويُراجَع؟

طريقة القراءة: ثماني إجابات بنعم: أطلق تجربة. ست أو سبع: عالج الثغرات قبل ربط بيانات الإنتاج. أقل من ست: يبقى الوكيل في وضع القراءة فقط داخل بيئة اختبار.

ما أخلص إليه

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

المصادر

إذا أردت مناقشة هذا الموضوع لمؤسستك، أقترح عليك لقاءً أوليًا مدته من 30 إلى 45 دقيقة، مجانيًا ودون أي التزام.

احجزوا موعدًا