كيف تؤمّن وكيل ذكاء اصطناعي يستخدم أدوات حقيقية؟
دليل عملي لتقييد هوية الوكيل وصلاحياته ومدخلات أدواته، مع موافقة بشرية قبل الإجراءات المكلفة أو غير القابلة للعكس.
النموذج لا يملك صلاحية العمل لمجرد أنه اقترح إجراءً
عندما يقرأ الوكيل بريداً أو يعدّل سجل عميل أو يرسل دفعة، يصبح جزءاً من نظام الصلاحيات. وتعرض مبادرة OWASP لأمن الأنظمة الوكيلة المخاطر الخاصة بالوكلاء ومسارات العمل متعددة الخطوات. لا يجوز للخادم أن يثق في طلب الأداة لأنه صادر عن نموذج داخلي. يجب ربط كل استدعاء بمستخدم موثّق، ومورد محدد، وسبب مسموح، ثم إعادة التحقق لحظة التنفيذ.
أنشئ هوية مستقلة لكل تكامل بدلاً من مشاركة حساب مدير. امنحها أقل scopes ممكنة، وحدد المؤسسات أو المجلدات أو المشاريع التي تستطيع الوصول إليها. الرمز الدائم واسع الصلاحية يحوّل خطأ prompt واحداً إلى حادث كبير.
صمّم أدوات ضيقة بدلاً من أمر عام
الأداة run_command(text) أو send_request(url, body) تمنح النموذج مساحة لا يمكن مراجعتها جيداً. الأفضل أدوات تعبّر عن العمل المسموح مثل create_support_draft(ticket_id) أو schedule_approved_report(report_id, date).
استخدم أنواعاً واضحة، enums، حدوداً لطول النص ومعرّفات مستقرة. ابحث عن بيانات العميل على الخادم ولا تطلب من النموذج تمرير عنوان أو صلاحية حساسة من ذاكرته. تحقق من الوجهة أيضاً؛ صحة JSON لا تعني أن التحويل المالي أو البريد ذاهب إلى الطرف الصحيح.
افصل الاقتراح عن التنفيذ
للإجراءات المؤثرة، اجعل المرحلة الأولى preview يعرض ما سيتغير، وعلى أي مورد، ولماذا، وما التكلفة المتوقعة. يوافق الإنسان على هذه النسخة المحددة، لا على عبارة عامة مثل “اسمح للوكيل بإكمال المهمة”. إذا تغيرت المدخلات بعد الموافقة فاطلب موافقة جديدة.
يمكن تنفيذ القراءة والتصنيف منخفضي المخاطر دون توقف، لكن الحذف، الدفع، النشر، تعديل الحقوق والتواصل الخارجي تحتاج حدوداً أوضح. الاستقلالية ليست مفتاح تشغيل واحداً؛ إنها درجات مختلفة لكل أداة.
تعامل مع prompt injection كمدخل غير موثوق
قد تحتوي صفحة ويب أو وثيقة أو رسالة عميل على تعليمات تطلب من الوكيل تجاهل السياسة أو كشف سر. المحتوى المسترجع بيانات، وليس أوامر ذات أولوية. افصل تعليمات النظام عن النص الخارجي، وقيّد الأدوات في الخادم، ولا تضع الأسرار في السياق إذا لم يحتجها النموذج.
اختبر مستندات خبيثة تطلب تغيير الوجهة، قراءة ملفات أخرى، أو استدعاء أداة غير مرتبطة بالمهمة. النجاح يعني أن السياسة تمنع الإجراء حتى لو حاول النموذج تنفيذه.
اجعل إعادة المحاولة آمنة
بعد timeout قد يكون النظام الخارجي قد نفذ العملية رغم عدم وصول الرد. إعادة الطلب مباشرة قد تكرر دفعة أو رسالة. أنشئ سجل إجراء ومفتاح idempotency قبل الاتصال، ثم طابق النتيجة مع النظام الخارجي عندما تكون الحالة مجهولة.
سجّل هوية الفاعل، اسم الأداة، القرار الأمني، التوقيت، النتيجة ومعرّف الارتباط. لا تسجل كلمات المرور أو الرموز أو كامل البيانات الحساسة. يجب أن يستطيع فريق الحوادث إعادة بناء التسلسل دون إنشاء نسخة جديدة من أسرار العملاء في السجلات.
الوكيل الآمن ليس وكيلاً لا يخطئ؛ بل نظام يحد أثر الخطأ، يطلب تدخلاً عند القرار الصعب، ويترك دليلاً واضحاً يتيح الإيقاف والتصحيح والاستعادة.
الأسئلة الشائعة
هل يكفي إخفاء مفتاح الأداة عن نموذج الذكاء الاصطناعي؟
لا. يجب أن ينفذ الخادم التفويض والتحقق من المدخلات والوجهة عند كل استدعاء، حتى لو بقي المفتاح مخفياً.
متى نطلب موافقة بشرية؟
قبل الدفع أو الإرسال العام أو الحذف أو تغيير الحقوق أو أي إجراء يصعب عكسه أو قد يؤثر في شخص آخر.
كيف نمنع تكرار الإجراء بعد انتهاء المهلة؟
استخدم مفتاح idempotency وسجل حالة الإجراء، ثم استعلم عن النتيجة غير المعروفة قبل السماح بإعادة المحاولة.