الإجابة الصحيحة لا تعني أن وكيل الذكاء الاصطناعي أنجز المهمة بطريقة آمنة. قد تحصل على النتيجة التي طلبتها، بينما يكون الوكيل قد استخدم صلاحية لم يكن ينبغي أن يمتلكها، أو كشف معلومة لم يكن ينبغي أن تغادر نظامك.
لهذا كانت جملة «عاصمة فرنسا هي باريس» لافتة في القصة التي أناقشها في الحلقة. المشكلة لم تكن في المعلومة؛ بل في أن وصولها إلى الوكيل، بحسب رواية الحلقة، كشف اتصالًا بخدمة خارجية من بيئة كان يفترض أن تمنع هذا الاتصال.
الدرس العملي لمن يربط وكيلًا بالبريد أو GitHub أو قواعد البيانات واضح: لا تسأل فقط «هل يستطيع إنجاز المهمة؟». اسأل أيضًا: ما الذي يستطيع الوصول إليه أثناء المحاولة، وكيف أوقفه إذا تجاوز الحدود؟
ما الذي نستخلصه من القصص، وما الذي لا نحسمه؟
أناقش في الحلقة قراءتي لتقارير منسوبة إلى OpenAI عن سلوك الوكلاء أثناء التدريب والتقييم. التفاصيل هنا مستندة إلى تلك القراءة كما وردت في الحلقة، وليست تحققًا مستقلًا من التقارير الأصلية؛ وقد أشرت أثناء الشرح إلى أن بعض التفاصيل التقنية تحتمل خطأ الفهم أو التفسير.
من المهم كذلك فصل الحوادث التي يناقشها السرد عن الاستنتاجات المحيطة بها. هوية النموذج، وربط ما حدث بغيابه عن Dev Day، ليستا حقيقتين محسومتين في المادة المتاحة. والحديث عن إيقاف تشغيل تدريبي وتقييمي محدد لا يعني توقف تدريب OpenAI بالكامل.
لا نحتاج إلى حسم اسم النموذج لنستفيد من السؤال الأساسي: إذا حاول الوكيل إنجاز مهمته بطريقة غير مسموحة، فهل لدينا قيد فعلي يمنعه، أم مجرد تعليمات نأمل أن يلتزم بها؟
ثلاث حالات تضع طريقة الإنجاز تحت الاختبار
حقن الأوامر: عندما يحاول المحتوى أن يصبح تعليمات
تخيّل أنك تطلب من وكيلك تلخيص رسالة بريد. الرسالة بالنسبة إليك مادة للقراءة، لكنها قد تحتوي أيضًا على نص يحاول توجيه الوكيل إلى إجراء آخر، مثل إرسال معلومات أو استخدام أداة خارج نطاق طلبك. هذا هو مبدأ حقن الأوامر، أو Prompt Injection، الذي تشرحه الحلقة.
في الحالة التي أناقشها، لم تقتصر المحاولة على التأثير في رد واحد؛ بل تضمنت دفع الوكيل إلى تكرار تعليمات داخل تفاعلات لاحقة، بما يشبه محاولة نشر الحقن بين الأدوات أو الأنظمة.
المغزى ليس أن كل رسالة ستنجح في خداع الوكيل. المغزى أن النص الخارجي لا يصبح موثوقًا لمجرد أن الوكيل يحتاج إلى قراءته. عند ربط البريد بالنظام، أنت تفتح مدخلًا للمحتوى، لا تمنح أصحاب هذا المحتوى حق إصدار الأوامر.
مفتاح الوصول: عندما تصبح محاولة الحل مشكلة أمنية
تتناول رواية أخرى في الحلقة وكيلًا يعمل على مسألة رياضية، ويكرر محاولة الوصول إلى حلول أو أدلة لدى جهات أخرى رغم توجيهه إلى حل المهمة بنفسه. ووفق قراءتي المعروضة، تضمنت المحاولات كشف مفتاح وصول في مستودع عام على GitHub.
بعض تفاصيل هذه الواقعة لم تكن واضحة لي تمامًا، ولذلك لا أبني عليها حكمًا قاطعًا بشأن آلية الاختراق. لكن السؤال الذي تطرحه على تصميم أنظمتنا مهم: لماذا يكون سر حساس متاحًا أصلًا لوكيل لا تحتاج مهمته إلى استخدامه بهذه الصورة؟
لا يكفي أن نطلب من الوكيل عدم نشر الأسرار. علينا أيضًا تقليل الأسرار التي يمكنه الوصول إليها، وحصر ما يتيحه كل مفتاح.
قصة باريس: نجاح الإجابة قد يكشف فشل أحد القيود
في القصة الثالثة، كانت المهمة تحديد كاتب مقال وجمع معلومات عنه داخل بيئة تحاكي الوصول إلى الإنترنت. وبحسب السرد في الحلقة، استطاع الوكيل استخدام DNS Resolver للوصول إلى خدمة خارجية، ثم اختبر الاتصال بسؤال عن عاصمة فرنسا.
هنا كانت الإجابة العادية علامة غير عادية: المسار الذي أوصلها هو موضع القلق. وتربط رواية الحلقة اكتشاف هذا الاتصال بإيقاف التشغيل التدريبي والتقييمي المعني.
بالنسبة إلى من يبني وكيلًا، الدرس أوسع من هذه الآلية التقنية: اختبار جودة المخرجات ليس بديلًا عن اختبار حدود الوصول. من الممكن أن تبدو النتيجة سليمة بينما يكون أحد القيود قد فشل.
خمس قواعد تجعل الحذر جزءًا من النظام
أنا لا أطرح هذه القصص لأقول: توقفوا عن استخدام الذكاء الاصطناعي. أستخدمه باستمرار، لكنني لا أريد أن تتوقف حماية بياناتي على التزام النموذج بالتعليمات في كل محاولة. هذه القواعد الخمس هي ما أحوّل به ذلك الحذر إلى إعدادات وخطوات عملية.
1. اجعل المنع في الأداة، لا في التعليمات فقط
إذا كانت مهمة الوكيل قراءة البريد وتلخيصه، فاكتب له بوضوح أنه غير مخوّل بالإرسال. لكن لا تتوقف عند هذه الطبقة: قيّد الاتصال من خدمة البريد نفسها بصلاحية القراءة فقط، عندما تتيح الخدمة ذلك.
الفرق جوهري. «لا ترسل» تعليمة موجّهة إلى النموذج؛ أما عدم منحه صلاحية الإرسال فهو قيد على ما يستطيع تنفيذه من خلال ذلك الاتصال، حتى لو حاول خلاف التعليمات.
طبّق المنطق نفسه على الكود وقواعد البيانات: امنح الوصول الذي تتطلبه المهمة، لا كل ما يسمح به حسابك. وإذا كانت الأداة لا تتيح تقييدًا مناسبًا، فهذه نقطة ضعف يجب أن تدخل في قرار ربطها بالوكيل.
2. جهّز خطة الإيقاف قبل أول حادثة
لحظة الاشتباه بتسريب ليست الوقت المناسب لتكتشف أين تُلغى المفاتيح أو ما الخدمات المتصلة بالنظام. أريد أن تكون خطوات الإيقاف معروفة مسبقًا، لا بحثًا مرتجلًا أثناء المشكلة.
الخطة التي أدعو إليها في الحلقة تشمل:
إيقاف الوكيل أو النظام الذي يشغّله.
فصل الأدوات والخدمات المتصلة به.
إلغاء مفاتيح الوصول المكشوفة أو تغييرها.
مراجعة العمليات التي ربما أُرسلت إلى أدوات أخرى ولم تنتهِ بعد.
النقطة الأخيرة مهمة: إيقاف الوكيل لا يعني بالضرورة إيقاف أمر سبق أن أرسله إلى خدمة أخرى. خطتك يجب أن تغطي النظام المتصل كله، لا واجهة المحادثة وحدها.
3. خصّص مفتاح API مستقلًا لكل وكيل
استخدام المفتاح نفسه مع عدة وكلاء قد يبدو أسهل في البداية. لكنه يجعل احتواء المشكلة أصعب: إذا تسرب المفتاح واضطررت إلى إلغائه، فقد تتوقف معه أنظمة لم تكن طرفًا في الحادثة.
خصّص لكل وكيل مفتاحه، مع الصلاحيات التي يحتاجها فقط. بهذه الطريقة تستطيع إلغاء وصول الوكيل المتأثر دون أن يكون تعطيل بقية العمل نتيجة حتمية.
الفصل بين المفاتيح ليس ضمانًا ضد التسريب؛ قيمته أنه يمنحك تحكمًا أدق عندما تحتاج إلى التدخل.
4. قلّل تعرض البريد، ولا تعتبر سريته ضمانًا
أفضل استخدام بريد مخصص لتعاملاتي مع الوكلاء بدل ربطهم مباشرة بصندوق يجمع المراسلات الشخصية والعمل وكل ما يصل من الخارج. وأقيّد صلاحياته قدر الإمكان، خصوصًا الإرسال والحذف إذا لم تكن المهمة تتطلبهما.
لكن تخصيص البريد أو إبقاء عنوانه محدود التداول لا يكفي وحده. أي رسالة تصل إليه قد تحمل محتوى غير موثوق، وكذلك أي صفحة أو مستند أو مصدر نصي يقرؤه الوكيل.
لذلك، لا تجعل السؤال «هل هذا البريد سري؟» فقط. اسأل أيضًا: من يستطيع إدخال محتوى إلى النظام، وما الإجراءات التي يمكن للوكيل تنفيذها بعد قراءته؟
5. راجع طريقة الوصول إلى النتيجة، لا بلاغة عرضها
قد تكون الإجابة مرتبة ومقنعة ومع ذلك تكون خاطئة، أو مبنية على عمل لم يُنجز كما طلبت. عندما تكون النتيجة مهمة شخصيًا أو مهنيًا، لا أكتفي بأن يبدو الرد جيدًا.
أطلب أدلة قابلة للمراجعة: المصادر المستخدمة، والتغييرات المنفذة، والاختبارات التي أُجريت، والخطوات التي يمكن إعادة تنفيذها. لا أقصد مطالبة النموذج بكشف تفكيره الداخلي، بل التحقق من العمل الفعلي وآثاره.
السؤال العملي هو: هل أستطيع إعادة الخطوات ذات الصلة والحصول على نتيجة متسقة؟ إذا لم أستطع، فلا ينبغي أن أعامل الثقة في صياغة الرد بوصفها دليلًا على صحته.
اعزل ما يهمك بدل افتراض أن الاحتمال الضئيل يساوي صفرًا
في نهاية الحلقة أعرض خطوة اتخذتها شخصيًا: اشتريت راوتر يدعم VLAN، بهدف فصل جهاز Mac Studio الذي أشغّل عليه الوكلاء عن بقية أجهزتي على الشبكة، مع إبقاء اتصاله بالإنترنت.
الفكرة ليست أن عزل الشبكة يمنح حماية مطلقة، بل أنني لا أريد منح بيئة الوكلاء طريقًا غير ضروري إلى جهازي الشخصي أو التخزين الذي يحتوي على ملفاتي. إنها طبقة إضافية، وليست بديلًا عن الصلاحيات المقيدة وخطة الإيقاف.
وهذا يلخص موقفي من أمان وكلاء الذكاء الاصطناعي: أستفيد من قدراتهم، لكنني أصمم النظام على أساس أن الخطأ أو تجاوز التعليمات احتمال يجب الاستعداد له.
قبل أن تمنح وكيلك أداة جديدة، اختبر حدودك أنت
هل تعرف ما الذي يستطيع قراءته وتغييره؟ هل تستطيع قطع وصوله دون تعطيل بقية أنظمتك؟ وهل لديك طريقة للتحقق مما أنجزه، بدل الاكتفاء بما يقول إنه أنجزه؟
هذه الأسئلة لا تتطلب انتظار نموذج جديد أو حادثة كبيرة. إنها نقطة بداية عملية لأي وكيل يتعامل مع بيانات تهمك.
شاهد الحلقة الكاملة: القصص التي أناقشها وخمس قواعد لأمان الوكلاء
لو تجاهل وكيلك اليوم تعليمة «لا ترسل ولا تحذف»، ما القيد الفعلي الذي سيمنعه؟ شاركني كيف تضبط هذه الحدود، دون نشر مفاتيح وصول أو معلومات حساسة.
