عرضت AWS كيفية تقييد وصول وكلاء AI في AgentCore إلى النطاقات المعتمدة فقط

أصدرت AWS دليلاً عملياً حول كيفية تقييد الوصول إلى الإنترنت لوكلاء الذكاء الاصطناعي على مستوى المجال. هذا ليس نموذجاً جديداً، بل إجراء أمان أساسي: يمكن تكوين موارد AgentCore للوصول فقط إلى المواقع المعتمدة مسبقاً.

لماذا هذا ضروري

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

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

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

كيف يعمل المرشح

في مركز المخطط يوجد SNI، Server Name Indication. يتم إرسال هذا المعامل في بداية اتصال TLS ويوضح المجال الذي يريد العميل الاتصال به. يمكن لـ Network Firewall تحليل هذا الحقل ومقارنته بقائمة المجالات المسموحة. إذا كان المجال في قائمة البيض، فإن الاتصال ينجح؛ وإلا، فسيتم حظر الطلب قبل أن يبدأ الوكيل حتى بالتفاعل مع المورد الخارجي.

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

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

لماذا هذا غير كافٍ

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

"تصفية المجال من خلال فحص SNI هي الطبقة الأولى من الدفاع متعدد الطبقات."

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

الخلاصة العملية من هذا هي: يجب دمج قائمة البيض للشبكة مع تدابير أخرى. يتضمن ذلك عادةً عزل البيئة والحقوق الدنيا لـ IAM والتحقق من إجراءات مخرجات الوكيل والتسجيل وحدود الأدوات والسياسات الإضافية على مستوى التطبيق. بمعنى آخر، يجيب Network Firewall على سؤال "أين يمكن للوكيل الذهاب" لكنه لا يحل محل التحكم في "ما يفعله الوكيل" و"ما يعيده".

ما يعني هذا

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