Amazon Bedrock AgentCore تضيف Policy للتحكم في وصول وكلاء الذكاء الاصطناعي

وصفت Amazon كيف أضافت Bedrock AgentCore آلية مستقلة باسم Policy لحماية وكلاء الذكاء الاصطناعي. تتمثل مهمتها في فحص الوصول إلى الأدوات والبيانات لا وفق «الحس السليم» للنموذج، بل وفق قواعد صارمة تُنفَّذ بمعزل عن استدلاله، وتنقل الأمان من الموجِّهات (prompts) إلى طبقة بنية تحتية قابلة للإدارة.

طبقة قواعد مستقلة

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

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

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

الفحص عند البوابة

عمليًا، تُطبَّق Policy عبر AgentCore Gateway. تعترض هذه البوابة كل طلب من الوكيل إلى أداة أثناء التشغيل، وتفحصه قبل تنفيذ الإجراء. وبعبارة أخرى، لا يتعلق الأمر بإعداد لمرة واحدة في بداية الجلسة، بل بتحكم وقت التشغيل (runtime): فقد يستدعي الوكيل واجهات API وقواعد البيانات ومخازن الملفات والخدمات الداخلية عشرات المرات، وتخضع كل خطوة من هذه الخطوات للتقييم وفق السياسة. وهذا يجعل الحماية أقرب إلى السلوك الفعلي للوكيل لا إلى نواياه الأولية.

• من الذي بدأ الطلب تحديدًا: مستخدم بعينه أم دور أم مجموعة
• أي أداة يستدعيها الوكيل وأي إجراء يريد تنفيذه
• هل يحق للمستخدم الاطلاع على هذه البيانات أو تشغيل سير العمل (workflow) هذا
• هل ينبغي منع الوصول أو السماح به أو تضييقه بحسب السياق

يقع التركيز الرئيسي هنا على الوصول المرتبط بالهوية (identity-aware). فالوكيل لا يحصل على إذن مجرد من نوع «العمل مع CRM» أو «قراءة المستندات»، بل على صلاحيات مرتبطة بهوية المستخدم الذي يتصرف باسمه وبسلطاته. فإذا كانت جزء من سجلات العملاء فقط متاحًا للموظف، فعلى الوكيل أن يرى الحد نفسه. وإذا كان لدى المدير حق الوصول إلى مجموعة أدوات ولدى المحلل إلى مجموعة أخرى، فيجب احترام ذلك تلقائيًا أيضًا. ويفيد هذا النهج خصوصًا حيثما يخدم الوكيل نفسه موظفين مختلفين بمستويات وصول متباينة.

ونتيجة لذلك، لا تقدم Bedrock AgentCore مجرد حواجز حماية (guardrails) للإجابات، بل نموذجًا أكثر صرامة لإدارة الإجراءات.

ماذا يعني ذلك

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