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