يحافظ AgentCore على صلاحيات المستخدم عند استدعاء ServiceNow من دون تبادل رموز مخصص

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

أضافت AWS إلى Amazon Bedrock AgentCore Gateway تبادلا أصليا للرموز وفق آلية On-Behalf-Of، أو OBO. تستقبل البوابة رمز المستخدم، وتتصل بـ Microsoft Entra ID، ثم تحصل على رمز آخر مخصص هذه المرة لواجهة API الخاصة بـ ServiceNow، مع بقائه مرتبطا بالمستخدم الأصلي. وبذلك لم يعد هناك داع إلى وسيط مخصص لتنفيذ هذا التبادل.

كيف تعمل الآلية في مثال بسيط

لنفترض أن موظفا طلب من الوكيل عرض الحوادث النشطة. يحصل المستخدم أولا على JWT مخصص لتطبيق الوكيل. يحتوي حقل audience في هذا الرمز على معرّف الوكيل، ولذلك لن يقبله ServiceNow، لأن النظام المؤسسي يتوقع رمزا صادرا لموصل API الخاص به.

يمرر الوكيل رمز JWT إلى AgentCore Gateway. وترسله البوابة إلى Entra ID مع بيانات اعتماد التطبيق، والـ scope المستهدف، والمعامل requested_token_use بالقيمة on_behalf_of. يتحقق Entra من السماح بالتفويض، ثم يصدر رمزا جديدا يحمل audience الخاص بموصل ServiceNow، مع الاحتفاظ ببيانات المستخدم.

بعد ذلك تستدعي Gateway واجهة REST API في ServiceNow. تطابق المنصة claim المسمى preferred_username، مثل بريد العمل الإلكتروني، مع حساب موظف موجود، ثم تطبق أدواره. فإذا كان الشخص لا يستطيع سوى قراءة الحوادث، فلن يتمكن الوكيل أيضا من تعديلها. ويظل في السجل أثر واضح: يرتبط الإجراء بالمستخدم الذي أصدر الأمر.

ما الذي يجب إعداده

يتطلب Microsoft Entra ID تسجيل تطبيقين: أحدهما يمثل وكيل الذكاء الاصطناعي، والآخر يمثل موصل API الخاص بـ ServiceNow. ينشر الموصل الـ scope المفوض user_impersonation، ويُمنح تطبيق الوكيل إذنا لطلب هذا الـ scope.

يجب إنشاء تكامل OAuth وارد في ServiceNow باستخدام Entra بوصفه مزود OIDC. ومن المهم مطابقة claim المستخدم بصورة صحيحة، وقصر auth scope على واجهات API التي يحتاج إليها الوكيل فعليا. فعلى سبيل المثال، لا توجد حاجة إلى منح بوابة مخصصة لعرض الحوادث حق الوصول إلى جميع جداول المنصة.

تُنشأ في AgentCore تهيئة OAuth صادرة باستخدام JWT authorization grant. ثم تُشغّل Gateway بإصدار MCP 2025-11-25، لأن الإصدارات الأقدم لا تدعم OBO الأصلي. وبالنسبة إلى وجهة REST، يُحدد scope الخاص بالموصل والمعامل requested_token_use:on_behalf_of. بعد ذلك يجري التبادل تلقائيا مع كل طلب.

مواضع الخطأ المحتملة

لا يلغي التبادل الأصلي للرموز ضرورة ضبط الوصول بعناية. يجب أن يكون المستخدم الوارد في preferred_username موجودا في ServiceNow، وأن يمتلك تطبيق الوكيل الإذن المفوض، وأن يسمح auth scope باستدعاء الـ endpoint المطلوب. وسيؤدي أي خطأ في أحد هذه المواضع إلى رفض التفويض.

تستحق الحماية من إعادة استخدام الرمز اهتماما خاصا. يرسل Entra claim داخليا باسم uti بدلا من claim القياسي jti. وتقترح AWS النظر في مطابقته مع jti كي يتمكن ServiceNow من تطبيق تحقق إضافي وحظر الرموز. كما أن Guardrails لا تحل محل التفويض: فهي ترشح المحتوى، بينما تحدد OBO ما إذا كان المستخدم يملك حق تنفيذ الإجراء.

الخلاصة العملية بسيطة: إذا كان الوكيل يتعامل مع أنظمة مؤسسية، فلا تُخفِ جميع المستخدمين خلف حساب خدمة واحد. مرر الهوية عبر السلسلة كاملة، وضيّق الـ scope ليقتصر على العمليات الضرورية، واختبر بصورة منفصلة سيناريوهات الموظفين ذوي الأدوار المختلفة. فعند الحد الفاصل بين الوكيل ونظام الأعمال يتقرر ما إذا كانت الأتمتة ستظل خاضعة للتحكم أم ستتحول إلى ثغرة جديدة ذات امتيازات مرتفعة.