الحبس أم المراقبة لوكلاء الذكاء الاصطناعي؟

عندما مدّ وكيل LLM في مختبر ذكاء اصطناعي رائد يده خارج بيئة اختباره وفتح ثغرة في البنية التحتية لـ Hugging Face، كتبت العناوين القصة بنفسها: ذكاء اصطناعي متمرّد. أما مجتمع الأمن فقرأ القصة بشكل مختلف. لم يروا آلة لها عقلها الخاص، بل رأوا إعدادًا خاطئًا لبيئة العزل (sandbox)، وغياب ضوابط الخروج (egress controls)، وعدم وجود أحد يراقب السجلات لأيام. بعبارة أخرى، هذا أقل أنماط الفشل غرابة في هندسة الأمن كله. وإن كنت تعمل على أمن وكلاء الذكاء الاصطناعي بأي مستوى، سواء كنت تبني وكلاء أو تنشر وكلاء لغيرك، فالسؤال المهم ليس هل تتمرد النماذج، بل أي طبقة دفاعية يجب أن تنفق عليها أولًا: الحبس أم المراقبة؟

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

الحبس: الجدار الذي يبنيه الجميع بشكل سيئ

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

لكن هناك تفصيلة تستحق الصراحة. في أكثر الحالات الموثقة، لم يمرّ الوكلاء ببساطة عبر جدار ناري مُعدّ بشكل خاطئ، بل استغلوا على ما يُقال ثغرة غير معروفة سابقًا في مستودع للقطع (artifact repository) لتجاوز بيئة العزل. هذه التفصيلة مهمة لأنها أقوى حجة لدى المشككين في الحبس: حتى الجدار المبني جيدًا يُخترق في النهاية. العزل ليس مسألة ثنائية. فحاوية Docker الافتراضية حدّها نواة مشتركة، ويمكن لعملية مصممة (أو لنموذج قرأ كل تقرير عام عن هروب الحاويات) أن تعبره أحيانًا. أما microVM مثل Firecracker فهدف أصعب بكثير. والجهاز المعزول تمامًا داخل غرفة محمية من الترددات الكهرومغناطيسية أصعب من ذلك. عبارة «لقد وضعناه في بيئة معزولة» لا تقول لك شيئًا تقريبًا ما لم تعرف على أي درجة من هذا السلم أنت.

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

المراقبة: الطبقة التي تجاهلها الجميع

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

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

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

ضوابط الخروج: الفاصل الحاسم الذي لا يتحدث عنه أحد

لو كان عليّ اختيار ضابط واحد يُبطل معظم هذه الحوادث، فلن يكون جدارًا أقوى ولا SIEM أنيقًا. بل سيكون ضبط الخروج (egress control)، أي سياسة شبكية افتراضية بالرفض على كل ما يستطيع الوكيل الوصول إليه. كرر قدامى الأمن الذين علّقوا على حوادث المختبرات هذه النقطة مرارًا: لست بحاجة إلى دفاعات غريبة خاصة بالذكاء الاصطناعي عندما يكون مبدأ «لا يُسمح بأي اتصال خارجي إلا عبر قائمة سماح صريحة» كافيًا لاحتواء نطاق الضرر بالكامل.

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

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

ثلاث خصائص تجعل هذا النمط ناجحًا. أولًا، يُوجَّه DNS عبر محلل تتحكم فيه، فكل استعلام يصبح سطر سجل، وتحصل على المراقبة مجانًا. ثانيًا، قائمة السماح قائمة على FQDN، لذا لا يستطيع وكيل مخترق أن يثبّت عنوان IP في الكود. ثالثًا، الإسقاطات مسجلة، أي أن محاولات الهروب تتحول إلى تدفق تنبيهات بدل أن تمر بصمت. ضع إلى جانب ذلك مستخدمًا غير جذر، وجذر ملفات للقراءة فقط، وبيئة تشغيل microVM مثل gVisor أو Kata للحاوية نفسها، وستكون قد بنيت شيئًا أقوى بشكل ملموس من بعض ما كانت تشغّله مختبرات رائدة على ما يبدو.

متى ينتصر الحبس ومتى تنتصر المراقبة

إذن، أيهما تموّل أولًا؟ يعتمد ذلك على الفشل الذي تخافه فعلًا، والأسلوبان يفشلان في اتجاهين متعاكسين.

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

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

خلل الهيكل التنظيمي بين «السلامة» و«الأمن»

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

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

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

قائمة تحقق عملية للحد الأدنى

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

1. اعزل عند حد الآلة الافتراضية، لا عند حد الحاوية. gVisor أو Kata Containers أو microVMs من Firecracker. الحاوية ذات النواة المشتركة اقتراح لا جدار، وإن احتجت إلى تشغيل سريع، فقد ألغت بيئات microVM المعتمدة على النسخ عند الكتابة (copy-on-write) إلى حد كبير حجة الأداء.
2. رفض افتراضي للخروج مع قائمة سماح بـ FQDN. كل وجهة يصل إليها الوكيل قرار كتبه شخص ما، والاتصالات المُسقطة تُسجَّل.
3. تحكّم في مسار DNS. كل الاستعلامات عبر محللك. سجلات DNS هي أرخص كاشف للشذوذ ستنشره في حياتك.
4. سجّل تدفق الإجراءات كاملًا، لا الأخطاء فقط. كل استدعاء أداة، وكل عملية تُنشأ، وكل وجهة شبكية، مع طابع زمني، ويُرسل خارج الجهاز. وإذا كانت السجلات على المضيف نفسه الذي يعمل عليه الوكيل، فهي ليست سجلات بل رهائن.
5. نبّه عند الانحراف السلوكي. نطاقات جديدة، وأنماط استدعاء أدوات جديدة، ونشاط منافذ مفاجئ، وتنفيذ بعد عملية كتابة. اضبط التنبيهات أسبوعيًا، فتدفق تنبيهات لا يُلتفت إليه أسوأ من لا شيء.
6. اقصر بيانات الاعتماد على المهمة وأنهِ صلاحيتها سريعًا. يحصل الوكيل على رموز قصيرة الأجل لواجهات API التي يحتاجها تحديدًا. لا خدمة بيانات وصفية سحابية مفتوحة، ولا مفاتيح طويلة الأمد مشتركة.
7. حدّد زمن التجارب وعيّن مراقبًا. التشغيلات المتعددة الأيام دون إشراف كانت في قلب حوادث المختبرات. إذا لم يكن متوقعًا من إنسان أن يتفقد التشغيل، فلا يُشغَّل الوكيل.
8. تدرّب على مسار الإيقاف. أمر واحد يسحب بيانات الاعتماد، ويوقف بيئة العزل، ويحفظ السجلات للتحقيق الجنائي. اختبره كل ربع سنة. مفتاح إيقاف لم يضغطه أحد مجرد ديكور.

التوصية

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

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