الخلاصة

  • ستستخدم NIST مشروع DevSecOps ليكون أول تطبيق عملي يوضح كيفية تعريف وكلاء الذكاء الاصطناعي والتحقق من هويتهم ومنحهم الصلاحيات خلال دورة تطوير البرمجيات.
  • أفادت المؤسسة بتلقي أكثر من 600 تعليق، وكشفت أن Gemini ساعد في مراجعتها وتلخيصها؛ أما الوكلاء الذين يتحكم فيهم المستهلكون فمؤجلون إلى مرحلة تالية.

حددت NIST موقع التجربة الأولى، لكنها لم تنشر بعد التصميم النهائي للمشروع. ففي إعلان 29 سبتمبر، قالت إن أول حالة تطبيق ستعتمد على مشروعها لتطوير البرمجيات الآمن (DevSecOps). والهدف هو إظهار كيفية تعريف الوكيل والتحقق من هويته وتحديد ما يُسمح له به عبر مراحل تطوير البرمجيات.

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

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

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

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

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

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

أما المحطة العامة التالية فهي مسودة وصف المشروع، التي ستعرض النطاق والحالات والهندسة والمعايير المقترحة. وأعلنت NIST أيضاً عن ندوة عبر الإنترنت في 28 أكتوبر حول هوية الوكلاء وDevSecOps. وإلى أن تظهر المسودة، لا يوجد ما يبرر وصف التجربة بأنها إطار شامل لهوية الوكلاء أو نظام اعتماد أو قاعدة تقنية معتمدة.