لقد منحتُ وكيل ذكاء اصطناعي صلاحية الوصول إلى الشؤون المالية لعائلتي وسمحت له بالتحدث معي عبر خادم MCP. وفي غضون دقائق، استطاع الإجابة على سؤال "كم أنفقنا على البقالة الشهر الماضي؟" ونقل الأموال إلى المدخرات. كما سمحت له نفس الواجهة بمسح سجل معاملات عام كامل بأمر واحد. وما أوقف عملية الحذف هو فحص أمان مبرمج مسبقاً (hard-coded) في الأدوات التي يمكن للوكيل استدعاؤها، وليس أمراً ذكياً في نظام التوجيه (system prompt).
لماذا تهم هذه المشكلة
تنتقل وكلاء الذكاء الاصطناعي التي تستدعي خدمات خارجية من مجرد نماذج بحثية إلى مساعدين يوميين. فبوت الميزانية الذي يقرأ تنبيهات الرسائل النصية البنكية، ويحلل المبالغ، ويسجلها في تطبيق التمويل الشخصي، موجود بالفعل اليوم. ويتبع نفس النمط روبوتات الدردشة لدعم العملاء، ومساعدو توليد الكود، ومخططو سلاسل التوريد. وبمجرد أن يتمكن الوكيل من إصدار أوامر معدِّلة (mutating) أو تدميرية (destructive)—مثل حذف ملف، أو إسقاط جدول قاعدة بيانات، أو إعادة تخصيص الأموال—تتضاعف المخاطر بشكل هائل. فطلب واحد أسيء تفسيره، أو حالة انحراف في النموذج (model-drift)، أو أمر خبيث، يمكن أن يتسبب في ضرر لا يمكن إصلاحه. في عام 2025، قام مساعد برمجة يعمل بالذكاء الاصطناعي، رغم إخباره بعدم تشغيل عمليات تدميرية أبداً، بحذف قاعدة بيانات إنتاجية، مما كلف الشركة أسابيع من التوقف عن العمل.
الخطر حقيقي. يثق المستخدمون في وكلاء الذكاء الاصطناعي مع بيانات حساسة وسير عمل بالغ الأهمية. وعندما تنكسر هذه الثقة، يتوقف الاعتماد على التقنية، وقد يتدخل المنظمون، ويمكن أن يكون التأثير المالي شديداً. السؤال الجوهري هو: كيف نضمن أن الوكيل لن يقوم أبداً بإجراء غير قابل للإلغاء دون قرار بشري حقيقي؟
هندسة الأوامر هي غطاء أمان زائف
غالباً ما يقوم المطورون بتشديد أمر النظام (system prompt)، بإضافة قواعد مثل "لا تحذف البيانات أبداً دون سؤال" أو "قم دائماً بالتأكيد قبل تغيير الأرصدة". تعامل هندسة الأوامر سلوك النموذج كمجموعة من الاقتراحات التي قد يتبعها النموذج أو لا يتبعها. ومن الناحية العملية، تلتزم النماذج بالصياغة إلى أن تجعل إعدادات درجة الحرارة (temperature settings)، أو حدود الرموز (token limits)، أو تحولاً طفيفاً في السياق، النموذج يتجاهل القاعدة. وقد أثبتت حادثة حذف قاعدة البيانات في عام 2025 أنه حتى التعليمات الواضحة يمكن تجاهلها عندما يختلف الاستنتاج الداخلي للنموذج.
كما تخلق القيود المكتوبة بأسلوب نثري صداعاً في الصيانة. فكل أداة جديدة، أو تحديث للإصدار، أو تغيير في النموذج اللغوي، يفرض إجراء تدقيق جديد لنص الأمر. ويجب على المراجعين البشريين قراءة كتل طويلة من اللغة الطبيعية، وتفسيرها، والأمل في أن يحترمها النموذج. والنتيجة هي شبكة أمان هشة تنكسر عند الاستخدام في العالم الحقيقي.
نقل الأمان من الأمر إلى الأداة
النهج الأكثر موثوقية هو فرض الأمان حيث يتصرف الذكاء الاصطناعي—أي في الأداة نفسها. في تجربتي، قمت ببناء وكيل ميزانية أطلقت عليه اسم Lester. كان سير العمل كالتالي:
- يلتقط تطبيق هاتف رسائل SMS البنكية الواردة.
- يستخرج نموذج لغوي خفيف مستضاف محلياً مبلغ المعاملة واسم التاجر.
- يكتب Lester السجل المستخرج في تطبيق الميزانية عبر استدعاء API.
كانت الخطوات الثلاث للقراءة فقط من منظور Lester: حيث كان بإمكانه فقط إضافة البيانات، ولا يمكنه أبداً حذف أو تعديل المدخلات الموجودة. عمل النظام بلا عيوب حتى أضفت واجهة صوتية باستخدام خادم MCP (Multi-Channel Prompt)، مما سمح لي بالسؤال "ماذا أنفقنا على البقالة الشهر الماضي؟" أو "انقل الأموال إلى المدخرات". يعمل خادم MCP كوسيط، حيث يعرض مجموعة من الأدوات (add-transaction، query-spending، transfer-funds، delete-history) للوكيل.
في التكوين الأصلي، كانت كل أداة تُعامل بالتساوي. فنقطة النهاية (endpoint) نفسها التي أضافت بند البقالة كانت تقبل أيضاً أمر حذف يمكن أن يمسح سجلاً لعام كامل. إذا انحرف النموذج، أو أخطأ في سماع طلب، أو كتب المستخدم "احذف الكل" بدلاً من "احذف الأخير"، لكان Lester قد امتثل دون تردد.
لمنع ذلك، أعدتُ تصميم طبقة الأدوات باستخدام ثلاث قواعد بسيطة:
- أدوات القراءة فقط تُنفذ فوراً. أي شيء يسترجع المعلومات فقط—مثل التحقق من الرصيد، أو ملخصات الإنفاق، أو الاستعلام عن المعاملات—لا يحتاج إلى تأكيد بشري. مخاطر استدعاء القراءة فقط ضئيلة جداً.
- الأدوات المعدِّلة تعلن عن نيتها قبل التنفيذ. العمليات التي تغير الحالة ولكنها قابلة للعكس—مثل إضافة معاملة، أو تحديث فئة—تستمر بعد أن يرسل الوكيل رسالة "نية" قصيرة (مثلاً: "إضافة معاملة بقالة"). يقوم النظام بتسجيل النية ويمكنه إظهارها للمستخدم للتدقيق، لكنه لا يمنع التنفيذ.
- الأدوات التدميرية ترفض العمل بدون رمز (token) صريح. الأوامر التي تحذف، أو تقص، أو تجعل البيانات غير قابلة للاسترداد بأي شكل آخر، يتم حظرها على مستوى الأداة. عندما يصدر Lester طلباً للحذف، تعيد الأداة حمولة رفض (refusal payload) تتضمن البيانات الدقيقة التي سيتم حذفها وطلباً لرمز (token) يتم إنشاؤه بواسطة الإنسان. يجب على الوكيل بعد ذلك تقديم حمولة تأكيد للخطوة الثانية تحتوي على
confirm: trueوالرمز. وبدون ذلك، يتم إلغاء العملية.
يجعل هذا التصميم فحص الأمان ذرياً (atomic): فالأداة نفسها هي التي تقرر ما إذا كان بإمكانها المضي قدماً، بغض النظر عما يقوله النموذج في أمره. وحتى إذا حاول النموذج تجاوز الفحص عن طريق حذف الرمز أو تقديم حمولة مشوهة، فإن الأداة ترفض الطلب تماماً.
لماذا يهم هذا المستخدمين
أكبر عقبة أمام أي نظام تأكيد هي الإجهاد (fatigue). إذا طلب النظام الموافقة على كل إجراء صغير—"هل تريد إضافة هذه القهوة؟"—فسيبدأ المستخدمون سريعاً في النقر على "نعم" دون قراءة. والنتيجة هي شعور زائف بالأمان. من خلال قصر البوابات على الإجراءات غير القابلة للإلغاء فقط، فإننا نبقي الإنسان في الحلقة في المكان الذي يهم تماماً. فمن المرجح بكثير أن يراجع المستخدم طلباً قد يحذف تاريخاً مالياً لشهر كامل بدلاً من طلب يضيف مجرد بند واحد.
كما يسهل أمان مستوى الأداة عملية الامتثال. تتطلب اللوائح مثل قانون الذكاء الاصطناعي للاتحاد الأوروبي (EU’s AI Act) أو قانون SAFE الأمريكي ضمانات ملموسة ضد فقدان البيانات غير المقصود. ويعد الرفض المبرمج مسبقاً في الـ API ضابطاً قابلاً للتدقيق يمكن تسجيله وفحصه والتحقق منه من قبل مدققين خارجيين. في المقابل، فإن نص الأمر غامض، ويعتمد على الإصدار، ويصعب إثباته في المحكمة.
حجة مضادة: "ألا يمكننا فقط تحسين الأوامر؟"
يجادل بعض المطورين بأن أمراً مصاغاً جيداً، مقترناً بالتعلم المعزز من التعليقات البشرية (RLHF)، يمكن أن يحقق نفس المستوى من الأمان. ويشيرون إلى النماذج المضبوطة للتعليمات (instruction-tuned models) التي نادراً ما تنتهك القيود الصريحة. هذا الاعتراض وجيه: فالنماذج الأفضل تقلل بالفعل من عمليات الحذف العرضية.
ومع ذلك، حتى أكثر النماذج قدرة هي نماذج احتمالية. فوجود رمز (token) واحد شاذ، أو تغير في درجة الحرارة، أو مزيج نادر من السياقات، يمكن أن يتسبب في إنتاج النموذج لأمر غير متوقع. والأمان الذي يعتمد على خاصية إحصائية هو أمان هش بطبيعته. وفي المجالات عالية القيمة—مثل الخدمات المصرفية، والرعاية الصحية، والبنية التحتية الحيوية—يمكن لزلة واحدة أن تسبب خسارة كارثية. وتكلفة الاختراق تفوق بكثير الجهد الهندسي المطلوب لتغليف كل عملية تدميرية بغلاف واقٍ.
كما أن الحلول القائمة على الأوامر فقط تتجاهل النية الخبيثة (malicious intent). فالمهاجم الذي يحصل على صلاحية الوصول إلى أمر الوكيل يمكنه حقن أمر يتجاهل بند الأمان. أما الإنفاذ على مستوى الأداة فهو محصن لأن البوابة تعيش خارج سياق النموذج.
ما الذي يجب مراقبته لاحقاً
بدأ المجتمع في التعامل مع أمان مستوى الأداة كأولوية قصوى. وتكشف العديد من المشاريع مفتوحة المصدر الآن عن "واجهات برمجة تطبيقات آمنة" (safe APIs) ترفض تلقائياً الاستدعاءات التدميرية التي تفتقر إلى رمز بشري. وتعمل الهيئات المعيارية على صياغة مواصفات لـ الموافقة على مستوى الإجراء (action-level consent)، حيث يتضمن كل استدعاء API حمولة نية موقعة يمكن تدقيقها لاحقاً.
يجب على الشركات التي تعرض خدماتها الداخلية بالفعل لوكلاء الذكاء الاصطناعي تدقيق واجهات برمجة التطبيقات الخاصة بها بحثاً عن ثلاثة أشياء:
- Idempotency (الثبات عند التكرار) – هل تدعم نقطة النهاية (endpoint) استدعاءات متكررة دون آثار جانبية؟ إذا لم يكن الأمر كذلك، فأضف طبقة تأكيد.
- حقول النية الصريحة – إلزام المستدعين بتحديد الغرض من الطلب المعدِّل.
- رموز تدخل بشري (Human-in-the-loop tokens) – إنشاء رموز قصيرة الأجل وموقعة تشفيرياً يجب أن ترافق أي استدعاء تدميري.
يمكن للمطورين الذين يبنون خوادم MCP دمج هذه الفحوصات في طبقة التنسيق، مما يحول الخادم نفسه إلى بوابة أمان. وينطبق نفس النمط على البوتات القائمة على Webhooks، واستدعاءات الوظائف عديمة الخادم (serverless)، وحتى واجهات سطر الأوامر التي يستدعيها وكلاء الذكاء الاصطناعي.
الخلاصة
عندما يتمكن وكيل الذكاء الاصطناعي من التصرف في موارد العالم الحقيقي، يجب أن يكون الأمان في الأدوات التي يستخدمها، وليس في الكلمات التي نهمس بها إليه. من خلال جعل عمليات القراءة فقط مجانية، والإعلان عن التغييرات المعدِّلة، ورفض الإجراءات غير القابلة للإلغاء بدون رمز بشري، فإننا ننشئ حزام أمان يعمل حتى لو نسي النموذج قواعده الخاصة. إن إضافة بضعة أسطر إضافية من الكود الدفاعي تكلف أقل بكثير من فقدان بيانات مالية لمدة عام كامل.