ربط وكيل ذكاء اصطناعي بأودو دون كسر صلاحيات المستخدمين

أغلب تكاملات أودو تعمل بحساب واحد يرى كل شيء. هذا يتجاوز صلاحيات أودو بالكامل. إليك البديل.

· 8 دقائق قراءة

المشكلة في التكامل المعتاد

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

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

الهوية تأتي من أودو، لا من المتصفح

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

الصواب أن يوقّع خادم أودو تأكيداً قصير العمر يقول «هذا هو المستخدم الحالي»، مأخوذاً من `request.env.user` داخل أودو. المتصفح يحمل الظرف المختوم فقط ولا يستطيع تعديل محتواه.

  • وقّع التأكيد بمفتاح مشترك، واجعل عمره قصيراً: دقيقتان تكفيان.
  • اجعل لكل تأكيد رقماً فريداً يُستهلك مرة واحدة، وإلا أمكن إعادة استخدام تأكيد مسروق.
  • ارفض المستخدم الجذر (`uid <= 1`) صراحةً في كل طبقة.

الكتابة تحتاج بوابة بشرية

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

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

أسئلة شائعة

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

اقرأ أيضاً