أمان مهارات وكلاء الذكاء الاصطناعي: لماذا يحتاج وكيل الهاتف إلى فحص الأذونات أثناء التشغيل؟

الفحص قبل التثبيت ليس شهادة ثقة

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

في 6 يوليو 2026، نشر The Hacker News تقريرا عن SkillCloak، وهي تقنية عرضها باحثون بوصفها طريقة يمكن أن تساعد مهارات وكلاء ذكاء اصطناعي خبيثة على الالتفاف على فحوصات ثابتة. الفكرة العامة ليست أن كل مهارة خطيرة، ولا أن كل فاحص عديم الفائدة، بل أن الفحص الذي ينظر إلى الملفات أو النصوص قبل التشغيل لا يرى دائما ما سيحدث عند استخدام المهارة في سياق حقيقي.

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

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

السلوك أثناء التشغيل هو الاختبار الأهم

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

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

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

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

لماذا يصبح الخطر أكبر على الهاتف؟

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

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

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

تضيف إرشادات OWASP GenAI Security Project لغة مفيدة لفهم الفئات العامة للمخاطر: حقن التعليمات، مشكلات سلسلة الثقة في الإضافات، التصميم غير الآمن للأدوات، منح صلاحيات زائدة، وكشف المعلومات الحساسة. هذه ليست قائمة لإثارة الخوف، بل خريطة أسئلة. هل تستطيع المهارة قراءة أكثر مما تحتاج؟ هل تستطيع تنفيذ أكثر مما وعدت؟ هل يستطيع المستخدم رؤية ذلك قبل وقوعه؟

نموذج أذونات عملي لوكلاء الهاتف

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

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

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

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

قائمة تقييم دون تهويل

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

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

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

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

ما الذي يعنيه ذلك لFoneClaw؟

FoneClaw مستقل عن The Hacker News، ومؤلفي أبحاث arXiv، وOWASP، وAndroid، وGoogle، وClaude Code، وOpenAI Codex، وOpenClaw، وأي بائع أمان. ولا توجد هنا أي مطالبة بأن FoneClaw تأثر بSkillCloak أو أنه يفحص مهارات طرف ثالث أو يضمن الأمان الكامل. الدرس المنتج أضيق وأهم: وكيل الهاتف يجب أن يجعل الأفعال المدعومة مرئية، مرتبطة بالأذونات، ومشروطة بتأكيد المستخدم.

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

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

المصادر: استندت إشارة SkillCloak إلى تقرير The Hacker News الصادر في 6 يوليو 2026، واستخدمت دراسة Cloak and Detonate بوصفها ورقة أولية لا ضمانا نهائيا. واستندت فئات المخاطر العامة إلى OWASP GenAI Security Project، وحدود أذونات الهاتف إلى Android Developers.

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