أمن وكلاء الذكاء الاصطناعي: قائمة مراجعة عملية للتحكم

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

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

البحث والإفصاح: تستند قائمة التحقق إلى NIST إطار عمل إدارة مخاطر الذكاء الاصطناعي. وOWASP أفضل 10 مخاطر لتطبيقات LLM وAnthropic إرشادات السلامة الخاصة بالوكيل، التي تمت مراجعتها في 3 سبتمبر 2026.

الحدود الأمنية الخمسة

الأمان موزع على سير العمل. لا يُعد التنبيه الأخير الذي يطلب من الوكيل "توخي الحذر" إجراءً أمنيًا.

نموذج التهديد قبل تصميم الميزة

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

عزل الهوية والمستأجر.

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

سلامة الاسترجاع

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

عزل الأدوات ووقت التشغيل.

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

تصميم يتطلب موافقة بشرية

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

حالات اختبار الفريق الأحمر

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

قائمة مراجعة عمليات الأمان

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

ربط عناصر التحكم بمراحل الوكيل

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

مخاطر سلسلة التوريد والموصلات

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

ما الذي تتضمنه مراجعة أمنية مفيدة؟

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

تطبيق مبدأ أقل الامتيازات عمليًا

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

عقد استدعاء الأداة

{
  "tool": "create_draft_task",
  "arguments": {"title": "...", "owner": "...", "due_date": "..."},
  "requires_approval": true,
  "idempotency_key": "project-123:brief-v2"
}

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

استرجاع وحقن فوري

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

التقييم والاستجابة للحوادث

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

الأسئلة الشائعة

هل يمكن لوكيل الذكاء الاصطناعي أن يكون مستقلاً تماماً؟

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

هل يُعالج النموذج الخاص أمن الوكيل؟

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

ما الذي يجب على الفرق تأمينه أولًا؟

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

للاطلاع على بنية النظام، انظر بنية وكيل الذكاء الاصطناعي؛ وللحصول على تفاصيل التنفيذ، قارن مع دليل Claude Agent SDK.