عزل وكيل الذكاء الاصطناعي وأذونات Android: ثلاث طبقات لا طبقة واحدة

ثلاث طبقات حماية تجيب عن أسئلة مختلفة

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

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

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

صندوق العزل ما زال يحتاج حدود ملفات وشبكة

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

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

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

وصول Android وموافقة الإجراء منفصلان

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

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

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

حوّل التحليل إلى مسودة هاتف قابلة للمراجعة

لنفترض أن لديك تحليلاً غير حساس من وكيل بعيد: “العميل يسأل هل يمكن اعتماد موعد الخميس بين 10:00 و10:30”. قبل صياغة نص يلتزم بهذا الموعد، تحقق أنت بشكل مستقل من التوفر في التقويم أو نظام العمل. بعد التحقق، لا يحتاج سير العمل المناسب إلى ربط آلي بين صندوق عزل بعيد والهاتف. أنت تنقل الخلاصة التي تريد استخدامها، تختار المستلم، ثم تطلب من FoneClaw إعداد مسودة في تطبيق Android مدعوم.

الصياغة العملية بعد التحقق قد تكون: “افتح محادثة أحمد في تطبيق الرسائل إذا كانت واضحة، وضع هذه المسودة فقط: مرحباً أحمد، راجعت التوفر ويمكننا اعتماد الموعد الخميس بين 10:00 و10:30. توقف قبل الإرسال”. هنا توجد ثلاث نقاط مراجعة: هل المحادثة تخص أحمد الصحيح؟ هل النص يطابق التحليل الذي وافقت عليه؟ وهل بقي الإرسال قراراً منفصلاً؟

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

قد يستخدم FoneClaw نموذجاً متصلاً حسب إعدادك، وقد يعالج هذا النموذج السياق الذي تقدمه. لذلك اجعل النص المنقول مختصراً، واحذف ما لا يحتاجه المستلم. لمعرفة قدرات Android الحالية التي نوفرها، راجع ميزات FoneClaw.

استعد دون تكرار إجراء غير مؤكد

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

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

اطلب دليلاً في كل طبقة

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

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

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