OWASP SAMM يحصل على امتداد Agentic SAMM للتطوير الآمن مع وكلاء AI

حول OWASP SAMM، ظهر مشروع مسودة جديد يدعى Agentic SAMM، أو ASAMM — وهو امتداد للفرق التي تبني المنتجات مع وكلاء الذكاء الاصطناعي وتستخدم النماذج في التطوير. الهدف منه هو إغلاق المخاطر التي لا يراها SDLC الآمن الكلاسيكي بشكل جيد: السياق الضار واستدعاءات الأدوات الخطيرة ونوافذ الاستقلالية الطويلة جداً.

لماذا SAMM القديم غير كافٍ

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

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

ما يقدمه ASAMM

لم يتم تصميم ASAMM كبديل عن OWASP SAMM، بل كامتداد للفرق التي تنشر وكلاء الذكاء الاصطناعي وخوادم MCP والأتمتة مع الأذونات المفوضة. يضيف الإطار طبقة منفصلة من الضمانات حيث تنتهي مراجعة الكود التقليدية: عند حدود استدعاءات الأدوات وفي تدفق السياق وعند نقاط التحقق من الموافقة وفي سلوك النظام أثناء التنفيذ. إنه لا يلغي الممارسات الأساسية لـ SAMM بل يمددها إلى سلوك وقت التشغيل والإجراءات المفوضة.

• تصنيف التهديدات للأنظمة الوكيلة حيث يُعتبر السياق أمراً محتملاً
• نموذج ثقة ثنائي المحاور للوكلاء والأدوات وخوادم MCP ومصادر السياق
• مجموعة من الضوابط على الوظائف الخمس لـ SAMM مع مستويات النضج وسيناريوهات التنفيذ
• مسارا نشر: الهجرة من برنامج أمان موجود أو النشر من البداية
• الربط برافعة NIST AI RMF والتوصيات الصادرة عن NCSC للفرق التي تحتاج إلى التوافق مع الأطر المألوفة بالفعل

يتم التركيز بشكل خاص على بيئة التطوير. تعمل إضافات IDE وخطاطيف pre-commit ووكلاء CI والموصلات الخارجية MCP بامتيازات المطورين، لكنها غالباً تعيش خارج نموذج تهديد كامل. بالنسبة لـ ASAMM، هذا ليس عنصراً ثانوياً بل هدف تحليل كامل: إذا كان بإمكان الوكيل قراءة واستدعاء وتعديل أكثر مما تتابعه الفريق فعلياً، فإن الحالات الخضراء على لوحات المعلومات تتوقف عن تقديم أي ضمانات. في الواقع، تصبح بيئة التطوير إنتاجية للوكيل نفسه.

حيث تخطئ الفرق بالفعل

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

"لا توجد خطة تنجو من الاتصال الأول." يستخدم المؤلف هذه الفكرة كمبدأ

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

ماذا يعني هذا

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