هوية وكيل الذكاء الاصطناعي: الأذونات وسجل التدقيق والموافقة لكل أداة

لماذا يحتاج وكيل الذكاء الاصطناعي إلى هوية قبل استخدام الأدوات؟

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

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

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

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

حوّل الهوية إلى أذونات محدودة وقابلة للسحب

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

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

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

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

ما الذي نقرره ونسجله عند حدود استدعاء الأداة؟

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

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

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

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

ضوابط المؤسسة وضوابط هاتف Android طبقتان مختلفتان

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

الجدول التالي يوضح الفارق بدون مساواة زائفة:

إرشادات NVIDIA حول الوصول، sandboxing، تقييد egress، وإدارة الأسرار مفيدة كإطار عام. لكنها لا تعني أن تطبيق هاتف ينفذ تلقائيا بنية مؤسسة كاملة. في المقابل، أذونات Android ليست بديلا عن سياسة أعمال أو إدارة أسرار مؤسسية. لذلك نضع كل طبقة في مكانها: المؤسسة تدير بيئات وأسرارا وشبكات، والهاتف يدير أدوات وأذونات وتجربة موافقة قريبة من المستخدم.

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

كيف يطبق FoneClaw الضوابط العامة وضوابط كل أداة؟

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

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

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

ضبط الموافقة يبدأ من ثلاثة أوضاع عامة. Auto approve يسمح بتدفق أسرع عندما تكون السياسة والإعدادات مناسبة للمهام المنخفضة المخاطر. Follow tool policy يجعل قرار الموافقة يتبع سياسة كل أداة، وهو الوضع الأقرب لمعظم المستخدمين الذين يريدون توازنا بين السرعة والتحكم. Deny all يوقف استدعاءات الأدوات عندما يريد المستخدم تجميد التنفيذ أو الاختبار أو تقليل السطح إلى الحد الأدنى. لا يوجد وضع واحد مناسب لكل شخص وكل مهمة؛ الاختيار يعتمد على نوع الإجراءات التي تسمح بها.

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

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

جدول موافقة عملي لإجراءات وكيل الهاتف الشائعة

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

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

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

التدقيق والإلغاء والاسترداد عند الفشل أو تغير النطاق

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

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

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

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