AWS Bedrock AgentCore: سياسات أمان واعتراضات Lambda لوكلاء الذكاء الاصطناعي

نشرت مدونة AWS Machine Learning مادة توضح كيف يساعد Amazon Bedrock AgentCore، وهو منصة AWS لنشر وكلاء الذكاء الاصطناعي وتشغيلهم، على دمج التحكم في الوصول مباشرة في البنية التحتية للأنظمة المستقلة. ويستخدم المؤلفون مثالًا لما يسمّونه وكيل lakehouse، أي وكيل ذكاء اصطناعي يعمل مع البيانات في بحيرة البيانات (data lakehouse)، لإظهار كيفية الجمع بين آليتي حماية مختلفتين: Policy للتحكم الحتمي في الوصول، واعتراضات Lambda (Lambda interceptors) للتحقق الديناميكي من الطلبات في الوقت الفعلي.

كيف يعمل مستويا التحكم في الوصول

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

لماذا الجمع بين التحكم الحتمي والديناميكي؟

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

ماذا يعني ذلك لمطوري الوكلاء على Bedrock

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

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

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