أمان وكلاء الذكاء الاصطناعي للمؤسسات: الهوية والصلاحيات وسجل الإجراء

ابدأ بسجل إجراء يمكن مراجعته

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

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

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

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

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

حدّد هوية الوكيل ونطاقها في المؤسسة

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

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

أدوار موارد Azure وأدوار الدليل وأذونات Microsoft Graph تحكم موارد مختلفة. لذلك اكتب اسم المورد والفعل المطلوب قبل اختيار الصلاحية. وجود دور في مورد Azure لا يعني تلقائيًا إمكان قراءة بيانات دليل أو استخدام عملية في Graph. وتفرض هويات الوكلاء في Entra قيودًا على الأدوار والأذونات عالية الامتياز؛ راجع حدود المسار المحدد بدل افتراض أن أي صلاحية متاحة للتطبيقات متاحة للوكيل.

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

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

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

اجمع أدلة الهوية والفعل من مصدرين

تساعد إرشادات Microsoft Entra لسجلات الوكلاء وتسجيل الدخول في تتبع الهوية والوصول. يمكن لمن يملك على الأقل دور Reports Reader فتح Microsoft Entra ID، ثم «المراقبة والصحة»، ثم سجلات تسجيل الدخول واستخدام مرشحات الوكلاء. لا تمنح صلاحية إدارية أوسع لمجرد تمكين قراءة هذه التقارير.

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

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

1. اعثر على حدث الهوية المناسب وحدد الفاعل والمورد وحالة الوصول.
2. ابحث عن العملية المقابلة في الخدمة المستهدفة بحسب المراجع المتاحة.
3. راجع نوع العملية: قراءة أو إنشاء أو تعديل أو إرسال.
4. تحقق من النتيجة في الوجهة، وسجل أي جزء لا يمكن إثباته.

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

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

ميّز النجاح والرفض والانتظار والفشل الجزئي

الحالات التالية أمثلة مقترحة للسجل اليدوي، وليست نتائج اختبار أجريناه. في كل حالة، افصل ما سمحت به الصلاحية عن قرار الموافقة والمحاولة والنتيجة. لا تجعل خانة «مصرح» بديلًا عن خانة «نُفذ».

نجاح قراءة محدودة

طالب المهمة موظفة الفريق، والمنفذ هوية الوكيل المفوضة، والاعتماد مرجع اتصال المستندات، والنطاق قراءة مستند محدد. سجل وقت الإجازة وحدودها، ثم معرّف محاولة القراءة ودليل استجابة المورد. إذا ظهرت المسودة المطلوبة، اربط مرجعها بالطلب واكتب «المسودة متاحة للمراجعة؛ لم يُطلب إرسال». معيار الاكتمال هو دليل القراءة والمسودة، لا مجرد تسجيل دخول صحيح.

كتابة تنتظر الموافقة

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

إجراء مرفوض والهدف دون تغيير

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

كتابة جزئية أو نتيجة غير مؤكدة

افترض أن خطوة الإنشاء بدأت ثم انقطع الاتصال قبل وصول نتيجة حاسمة. سجل آخر مرحلة معروفة ومعرّف المحاولة والمرجع المتاح، وصنف الحالة «غير مؤكدة». لا تعد الكتابة مباشرة؛ افحص المورد بحثًا عن الأثر المقصود. قد تكون العملية اكتملت بينما ضاعت الاستجابة، أو نجح جزء من سلسلة وفشل الجزء التالي.

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

طبّق الأسئلة نفسها على الهاتف

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

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

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

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

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

اسحب الوصول وتحقق مما بقي في الوجهة

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

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

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

1. أوقف المهام الجديدة المرتبطة بالوصول المراد سحبه.
2. ألغِ الاتصال أو الإذن الزائد من الجهة التي تملكه، وراجع نطاق الإلغاء.
3. دوّر الاعتماد إذا انكشف، دون وضع السر الجديد في سجل المراجعة.
4. تحقق من منع الوصول المستقبلي بفحص محدود مناسب.
5. راجع آثار الكتابة السابقة في وجهتها قبل أي إعادة محاولة أو تصحيح.

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

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