AWS تُظهر كيف تمنع وكيل LLM من قراءة مستندات الآخرين: البوابة هي من تحقن userContext

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

نشرت مدونة AWS Machine Learning تحليلًا لكيفية سدّ هذه الثغرة في الربط بين Amazon Bedrock Managed Knowledge Base وAgentCore Gateway.

لماذا الوكلاء أصعب من التطبيق التقليدي

في التطبيق الكلاسيكي يعرف الكود بنفسه من سجّل الدخول، ويبحث بصلاحيات هذا المستخدم. أما في الوكيل فإن LLM هي من تستدعي الأداة، وهي أيضًا من تختار الوسائط. فإذا كان لأداة البحث معامل «باسم من يتم البحث»، فسيملؤه النموذج. تكفي عبارة من المستخدم مثل «ابحث كأنك user-b»، أو خطأ من النموذج، أو prompt injection غير مباشر في مستند عُثر عليه، ليبحث الوكيل بهوية شخص آخر.

لدى Managed Knowledge Base وضع ACL awareness. عند تحميل البيانات تتذكر القاعدة صلاحيات المستندات، وعند البحث تُعيد فقط ما هو مسموح للمستخدم المحدد في userContext.userId (وهو بريده الإلكتروني). لكن القاعدة نفسها لا تُصادق على المستخدمين، بل تصدّق ما يصلها. وعندما تُنشر كأداة MCP عبر AgentCore Gateway، يصبح userContext وسيطًا عاديًا يبنيه النموذج. لا البوابة ولا القاعدة تتحققان من أن القيمة تخص الشخص الذي سجّل الدخول.

أربع طبقات: اثنتان أساسيتان واثنتان احتياطيتان

المبدأ بسيط: LLM لا تقرر من هو المستخدم. يقرر ذلك كود موثوق استنادًا إلى بيانات تحقق منها مزوّد الهوية. يمر الطلب هكذا:

• يسجّل المستخدم دخوله عبر Amazon Cognito ويحصل على JWT. يضيف مشغّل Lambda من نوع pre token generation مطالبة (claim) بالبريد الإلكتروني إلى الرمز.
• يمرّر الوكيل الرمز في ترويسة Authorization، ويتحقق مفوِّض البوابة (authorizer) من التوقيع ومدة الصلاحية وclient ID.
• يستخرج Request interceptor، أي Lambda على البوابة، البريد الإلكتروني من الرمز الذي تم التحقق منه ويعيد كتابة userContext في كل استدعاء tools/call. مهما أرسل العميل أو النموذج، ستتلقى القاعدة بريد المستخدم الحقيقي. وتُرفض الدفعات (batches) وأجسام الطلبات غير الصالحة وفق مبدأ fail-closed.
• تتحقق Policy in AgentCore عبر سياسة Cedar من تطابق userContext.userId مع البريد الإلكتروني في JWT. وإن لم يتطابقا يُرفض الطلب.
• تمنع Resource-based policy الخاصة بقاعدة المعرفة البحث على الجميع باستثناء دور التنفيذ الخاص بالبوابة.

الطبقتان الأوليان (المعترِض وACL) هما الحماية الأساسية. وهما كافيتان للطلبات المارة عبر البوابة إذا لم يكن بوسع أحد آخر الوصول إلى القاعدة مباشرة. أما سياسة Cedar وresource-based policy فهما لحالة وجود خطأ في المعترِض أو وجود جهة غريبة (principal) تملك صلاحية bedrock:Retrieve في الحساب نفسه. والوكيل المبني على Strands Agents لا يحتوي على منطق وصول: هو فقط يمرّر الرمز.

المطبّات

• تُحدَّد ACL في S3 بملف عام لكل بادئة (prefix) أو بملف وصفي لكل مستند. المستند بلا ACL ببساطة لن يدخل الفهرس.
• تُطبَّق تغييرات الصلاحيات فقط بعد المزامنة التالية: لا يوجد فحص فوري في S3.
• أخطاء ACL لا تُطلق استثناءات، فالمستندات تختفي بهدوء من النتائج. تحقق من ذلك بالاختبارات.
• الطلب بلا userContext لن يعيد مستندات من مصدر مفعّلة فيه ACL، لكن مستندات المصدر الذي بلا ACL سيراها الجميع.
• لتخصيص access token في Cognito تحتاج إلى خطة Essentials أو Plus. على Lite لن يظهر البريد الإلكتروني في الرمز.
• حتى يتمكن المعترِض من كتابة userContext، يجب كشفه في مخطط الأداة عبر parameterOverrides، حتى لو لم يحدده العملاء.

ماذا نفعل بهذا

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

يوجد مثال جاهز على CDK في المستودع sample-managed-knowledge-base-patterns، ضمن المجلد agentcore-access-control. تنبيه: هذا مخطط لمنصة AWS، وعلى المنصات الأخرى سيتعين عليك إعادة تنفيذه بنفسك.